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

CommunicationSchlepping data from program A to program B

ProcessingThe “real work” of the system

State ManagementMaintaining data across requests and reboots

PresentationWhat the user sees, and when

SecurityWhat the user doesn’t see, and shouldn’t

SystemThe 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