EffectiveJava1.ppt (760.5 KB) - Interoperability Happens
Upcoming SlideShare
Loading in...5

EffectiveJava1.ppt (760.5 KB) - Interoperability Happens






Total Views
Slideshare-icon Views on SlideShare
Embed Views



1 Embed 1

http://www.slideshare.net 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    EffectiveJava1.ppt (760.5 KB) - Interoperability Happens EffectiveJava1.ppt (760.5 KB) - Interoperability Happens Presentation Transcript

    • 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!
    • “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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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!
    • 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
    • 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)
    • 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
    • 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
    • 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