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


Published on

Published in: Technology, Education

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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
        • Weblog at /ted/weblog