Your SlideShare is downloading. ×
EffectiveJava1.ppt (760.5 KB) - Interoperability Happens
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

EffectiveJava1.ppt (760.5 KB) - Interoperability Happens

245
views

Published on

Published in: Technology, Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
245
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1.  
  • 2. Introduction
    • Building enterprise applications is hard
      • state management
      • communications
      • lookup
      • resource management
      • security
      • and all this before we even get to the real problem domain!
  • 3. “Enterprise”
    • An enterprise system is one which …
      • … shares some or all resources used
      • … is intended for internal (or mostly internal) use
      • … must work within existing architecture
      • … will be deployed and maintained by internal IT staff
      • … requires greater robustness
      • … must fail gracefully (if it does fail)
      • … must gracefully handle evolution over time
  • 4. Topics
    • Architecture
      • “ Big Picture” topics
    • Communication
      • Schlepping data from program A to program B
    • Processing
      • The “real work” of the system
    • State Management
      • Maintaining data across requests and reboots
    • Presentation
      • What the user sees, and when
    • Security
      • What the user doesn’t see, and shouldn’t
    • System
      • The platform beneath the platform
  • 5. Architecture
    • Enterprise architecture: a vision for the design and implementation of your enterprise components
      • Guides and influences design
      • Dictates component interoperability approaches
    • Architecture lays down groundwork for success
      • Hard to achieve success if architecture blows
      • Architecture defines how J2EE components interact:
        • Topology
        • Coarse component design
        • Interaction policies
        • … and so on
      • Architecture, unlike code, is hard to refactor effectively
      • So think critically about how your J2EE system is architected
  • 6. Item 1
    • Prefer components as the key element of development, deployment and reuse
      • Objects were supposed to enable “tinkertoy programming”
      • Objects failed—effective reuse never really happened to a large scale (beyond a single framework)
        • Reuse-via-inheritance doesn’t work (Fragile Base Class)
        • Classes sometimes tightly couple (Iterators)
      • Components: binary unit of independent development, deployment and production, defined by contract
        • Enables composition , which provides better reuse
        • Examples: Servlet tag libraries, Servlet web apps, etc.
      • Several Java practices already lead you towards components
        • Effective Java : Items 1, 14, 15, 16, 34
  • 7. Item 2
    • Prefer loose coupling across component boundaries
      • Coupling is the degree of interconnectedness of any two “things” in the system
        • if changing one means changing the other: tight coupling
        • not to be confused with “late bound” or “loosely typed” code
      • Loose coupling protects against change/evolution
        • for example, RPC/interface-based designs reduce coupling, but they don’t eliminate it entirely
        • refactoring isn’t an answer here: refactoring assumes you own both ends
        • seek approaches that will keep assumptions to a minimum
      • Tight coupling is not bad, so long as the tightly-coupled parts aren’t expected to evolve independently
        • such as within a component (e.g., collection class + Iterator)
        • across components, however, it can be death to the system
  • 8. Item 3
    • Differentiate layers from tiers
      • " N -tier systems are better than 2-tier systems"; why?
        • Network access hurts performance
          • yet n -tier systems double the number of network traversals
        • So why do this?
          • Connection pooling
          • Centralization of logic
          • Easier deployment
        • Question: can I get the best of both worlds?
      • Tiers are physical nodes in the network; layers are logical separations of related functionality
        • Don't assume business logic ( layer ) must be on middle tier
        • Not all business logic can rest in the middle (ex: input validation)
        • Browser-servlet-database arrangement is 3 tiers, by the way
  • 9. Item 4
    • Keep data and processors close together
      • Reason: Obtaining data is often not a free action
        • Network access significantly slower (see Item 17)
      • Keep data close to processors
        • Avoid flagrantly fetching or storing data remotely
        • Cache data to avoid having to re-fetch it
        • Store data locally (in-proc or local file) to avoid network access
        • Be wary of cache-concurrency problems
        • Be wary of cache-identity concerns
      • Keep processors close to data
        • If we can't bring the data to the code, bring the code to the data
        • Use stored procs to execute code in the same process as data
        • Run Java code in JVM inside RDBMS (Oracle, DB/2, etc.)
        • Avoids the cache-identity and cache-concurrency problems
  • 10. Item 5
    • Remember that identity breeds contention
      • Remember the equals() vs. == discussion?
        • that was a demonstration of object identity vs. equivalence
        • in single-VM systems, identity is implicit ( this )
        • this creates potential complications in enterprise systems, as the identity requirement creates bottlenecks
        • identity shows up in other scenarios, e.g., databases
        • identity also becomes crucial in distributed objects
      • In order to protect data against corruption, we need to restrict access by multiple users to a given thing
        • thing == object, row, whatever
        • identity requires synchronization
        • synchronization breeds contention
        • contention is the enemy of scalability
      • Avoid identity at all costs—often equivalence is sufficient
  • 11. Item 6
    • Use “hook points” to inject optimization, customization, or new functionality
      • Hookpoints are places in the system designed to bypass/augment normal processing
        • Performance optimizations
        • Security enhancement
        • Out-of-band information (extensions)
      • Most J2EE specs offer standardized hook points (except EJB)
        • J2SE Dynamic Proxies
        • Servlet filters
        • CORBA Interceptors
        • JMS Filters
      • Interception adds services to opaque components
        • "hijacks" the caller’s thread prior to component invocation
        • provides service on way in and/or back out
        • allows call to continue (or not) as appropriate
      • Requires you build strong encapsulation boundary (components!)
        • clients only interact with interfaces
        • clients use factory to obtain instances of interfaced objects
  • 12. Item 7
    • Be robust in the face of failure
      • "Stuff happens": Code must deal gracefully with exceptions
        • Don't just "catch-and-log"
        • Deal with exceptions as they were intended:
          • SQLExceptions: database failure
          • RemoteExceptions: network failure
          • EJBExceptions: container failure (never catch!)
          • Application exceptions: user did something wrong (always catch!)
        • JSP, servlets, JMS, all need to handle exceptions gracefully
      • Plan on dealing with failure:
        • How will you patch production code?
        • How will you recover from database or network failure?
        • How will you deal with OutOfMemoryErrors?
        • How will you deal with users bookmarking web pages?
      • Thinking about failure up front yields better robustness
        • In other words, have a unified "problem strategy"
      • Not all failures can be solved in code; solve what you can
  • 13. Item 8
    • Define performance and scalability goals
      • Every project has performance and scalability goals
        • usually defined in terms like “Make it run fast”
        • … which is not exactly a quantifiable goal!
      • Definitions
        • Performance: time for single client to complete
        • Scalability: add more user capacity by adding hardware
      • Most “performance” problems are scalability problems, due to excessive contention for locked resources
        • look for ways to improve scalability (to desired levels)
        • … reducing performance if necessary!
        • recognize that user perception is more important than reality
  • 14. Item 9
    • Restrict EJB to transactional processing
      • Contrary to popular belief, it is legal to do J2EE without EJB
        • In fact, it's desirable in places ("Fast Lane Pattern")
      • Problem: EJB was oversold
        • Part of EJB was to make distributed systems simpler
        • 4 .java files + deployment descriptor + EJBQL != “simpler”!
        • Requires tremendous intellectual investment to use
      • Main benefit of EJB: transactional processing
        • In particular, distributed transactions are easy with EJB
        • Auto-enlistment of resource managers
        • Auto-commit or –rollback, based on component voting
      • Don’t rely on EJB to provide scalability or performance
        • EJB can’t solve those problems: that’s what YOU do
  • 15. Item 10
    • Never optimize without profiling first
      • Remember the 80/20 rule
      • You don’t know what the 20% of the code is
        • you may think you know...
        • ... but the fact is most developers’ intuition sucks
        • Add in the fact that the JIT can silently add optimizations
      • Use the profiler to find the bottlenecks, not source code
      • Once you find bottlenecks, use hook points (Item 4) to fix
      • Remember that profiling carries its own cost, too
        • Heisenburg's Uncertainty Principle plays into all of this
        • so take a broad sample of profiled data before optimizing
  • 16. Item 11
    • Recognize the cost of vendor-neutrality
      • Much of Java’s marketing based on “vendor neutrality”
      • Critical question: Do you care? Do you need it?
      • Vendors offer numerous positive enhancements
        • Using them forces code changes when platforms change
        • Using them improves performance, scalability, etc.
      • Writing “vendor-neutral” code means sticking to spec:
        • No file I/O access from inside EJBs
        • No exclusivity assumption for entity beans
        • No vendor value-added extensions of any kind
      • Make your choice deliberately: portability, or performance
        • In many cases, this will be a hybrid answer
        • There is no right-or-wrong answer here!
  • 17. Item 12
    • Build in monitoring support
      • How do we know the application is still running?
        • Need some way of knowing when the application is failing
        • Unless you want your clients to be your signal, of course…
      • Quick diagnostic tool necessary to know if system is working
        • "the Happy Page": a single round-trip test of the system
        • ping the database server, query the database instance, get the version #
        • ping the middleware server, call a component, get the version #, etc
      • Diagnostic logging gives window on what's happening
        • Log to someplace fast for diagnostics, log to files for archival purposes
        • Make sure to log at different levels: logging isn't free
        • Make sure to make log levels component-centric and hot-configurable
      • Performance counters track how the system is performing
        • Java Management Extensions (JMX) were designed for this
        • O/S-specific tools can also provide some good insights
      • Diagnostics make everybody happy: managers & coders both
  • 18. Item 13
    • Build in administration support
      • Enterprise apps often need administration
        • Configuration, control, problem resolution, etc.
        • Could use tools specific to each technology (SQL console, etc)
        • But this creates complex configuration that admins must learn
      • Create an administrative console for config & control
      • Configuration
        • Existing solutions: Properties, database, LDAP, all have issues
        • Deployment descriptors try to solve some of this, but…
        • Preferences (java.util.prefs) try provide unifying solution
        • Requires a user interface for admin use, which you build
        • You'll need a UI for control operations anyway, so unify them
      • Control
        • Fixing "lost in the system" errors
        • User management (adding, removing, etc)
  • 19. Item 14
    • Make deployment as simple as possible
      • Shipping is a feature, too!
      • Many developers are not allowed access to production servers
        • This means sysadmins are doing deployments
        • Sysadmins typically aren't Java developers, and don't know J2EE
        • Deployment is usually vendor-specific
      • Think about all that's needed to deploy your application
        • .jar/.war files
        • JRE installation
        • Database schema changes/updates
        • Database data (lookup tables, etc)
        • Network configurations
      • Ant can go a long way towards helping here: a single script can do both builds and deployment
        • or give admins their own deployment-only script
  • 20. Conclusion
    • Not everything is cut-and-dried answers
      • Many of these items contradict one another in places
        • Certain items will apply in certain situations
        • Everything is context-dependent
        • That’s what makes it fun! 
      • In all things, be a little cynical
        • If your experience seems to contradict the book, experiment!
        • Just because it’s written in a book doesn’t make it right
      • Keep an eye on future developments
        • Much of what’s here applies to Spring, Hibernate, .NET, …
        • J2EE continues to evolve as well
  • 21. Credentials
    • Who is this guy?
      • Independent consultant and mentor
      • Speaker
        • TechEd, No Fluff Just Stuff, VSLive!, JavaOne, and others
      • Java Community Process EG member (JSR 175, 250, …)
      • Author
        • Effective Enterprise Java (Addison-Wesley, 2004)
        • Server-Based Java Programming (Manning, 2000)
        • C# in a Nutshell (with Drayton, Albahari; OReilly, 2001)
        • SSCLI Essentials (with Stutz, Shilling; OReilly, 2003)
        • Papers at www.neward.net/ted/Papers
        • Weblog at www.neward.net /ted/weblog