The vast majority of Java enterprise applications are architected along the lines of Sun's original PetStore showcase application. Rather than seeing this as a market stall displaying all the J2EE goods on offer, developers took it as a blueprint for enterprise applications. It certainly created a lot of work for Java application developers (as well as systems administrators and systems integrators), but whether most of the applications needed most of the possible layers - including bean-managed persistence and the ubiquitous DAO - is open for question at the very least. This article briefly describes some of the testability shortcomings of the traditional J2EE model and presents some alternatives.

The J2EE Model
With J2EE we are tied to a single logical server in a client/server architecture, and any component such as a servlet or EJB has to be deployed to the server (potentially a time-consuming process) before we know whether it works. This makes it difficult to use test-driven techniques to develop these components. To make a small change to such a component requires a code change, a recompile, and a redeploy. On many commercial application servers this sequence of events takes too long to be repeated as frequently as TDD requires. The developer is encouraged to deploy bigger changes less often, and therefore has a higher risk of introducing errors.

A few patterns alleviate some of this, most notably the Front Controller/Dispatcher pattern. This has a single component (a servlet in the Web container or a stateless session bean in the EJB tier) that dispatches requests to a POJO (Plain Old Java Object). A POJO is much better suited for unit testing - we can simply instantiate it in a known state and then exercise its behavior. From a TDD perspective, this is what makes a framework like WebWork more "agile" than Struts; for instance, the actual components are testable outside of a container.

Service-Oriented Architectures
J2EE encourages us to model a system in terms of components interacting with one another. Instead we can model in terms of services that an application provides or "things that it does." These services can exist on different machines or in different virtual machines on the same host. As long as we have a means of locating a service, we can use it. In terms of testability, this makes life a lot easier for us. A service is simply a class that implements an interface, so we can test its behavior in isolation or in conjunction with other services just by instantiating a service object and calling methods on it.

Service-oriented mechanisms such as SOAP, XML-RPC, or JINI are cleanly separated from the actual services they advertise. Compare this to a session bean, which is tightly coupled to its container: it requires a number of container-specific classes just to function (such as a javax.ejb. SessionContext), and has a whole complex life cycle associated with it. Both of these make testing a session bean a lot more complex - and add greatly to the time it takes to make a change and test it.

Event-Driven Architectures
So far we have focused on synchronous behavior. The concept of modeling a system in terms of messages or events being produced and consumed asynchronously from queues is very powerful and yet still largely overlooked. Event-driven systems are renowned for their resilience, but they also lend themselves very nicely to a test-driven approach. As with services, an event consumer or listener is typically a Java class that implements an interface. As long as the consumer class is decoupled from the delivery mechanism, we can easily test its behavior. We can model synchronous behavior asynchronously to gain both scalability and testability. A Staged, Event-Driven Architecture (SEDA) simulates synchronous processing by means of a series of stages, each represented by a queue. Thus each stage can be unit-tested and developed separately.

Summary
When you're writing an enterprise application in Java, you shouldn't feel constrained to the classic J2EE model. Investigate some of the alternatives; ask lots of questions; and evaluate the costs, benefits, and risks of using a different approach. But most important, as a developer try to find an architecture that enables you to write testable code. Remember, PetStore is a showcase of technologies, not a blueprint.