Introduction

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