To further drive this point home, let's assume a physical architecture of a J2EE application that uses the EJB approach. (This by no means is the only possible architecture, but it helps make some important points.) Figure 6 shows Web apps and some EJBs collocated on the same physical machine.

Just because Web apps and EJBs are collocated, three of these runtime services are not needed:

• The remoting of EJBs is not necessary as Web apps will call EJBs locally.
• Clustering of EJBs is achieved via replica-aware home and remote stubs. Again, since the caller (Web app) and the called object (EJB) are on the same machine, there is not much sense in using cluster-aware stubs. Note that HttpSession replication for making Web apps cluster-aware is still desirable though.
• Typically, if EJBs are not remoted, then you wouldn't want to impose security restrictions at the EJB tier.

• Caching of entity EJBs in the container, on the other hand, is a valuable benefit that may be considered depending on the use case at hand.
• Transactions are the most commonly used service provided declaratively by the EJB container. Many developers prefer the declarative use of Container Managed Transactions (CMT) over programmatic transaction management.
• Persistence is now a separate specification from the EJB specification (JSR-220) and therefore, in future, will not be a direct service of the EJB container. However, it is a valuable service that can save development time, and, in some cases perform better.

Therefore applications designed using EJBs will have to interject a container every time a service is invoked, even if it doesn't need 90% of the services it offers. In addition, it will be designed coarsely with the EJB's remote interface and bandwidth considerations. Compare this with a Spring-based design where the business classes are first designed, unencumbered by EJB technology, using all the power of OO design like inheritance and coding to interfaces. Once the business design is complete, then infrastructure services are applied to them on an as-needed basis.

However, many times collocation is not a good fit. Sometimes, depending on the use case, EJBs become a desired feature. For example, middle-tier bean caching necessitates the use of entity EJBs and clustering at an EJB level necessitates the use of session EJBs. For these and other reasons, let's look at how to access SLSBs from Spring.

Defining StatelessSessionBeans in the BeanFactory
SLSBs are widely used to provide the service façade in business applications. Sometimes it's not advisable to remove all SLSBs in favor of proxied objects. In fact, the non-invasive nature of Spring makes it a good candidate for phasing in its use. For that reason or other legitimate uses of SLSBs (like third-party SLSBs), it's easy to make Spring managed beans and SLSBs coexist in the same application.

In Listing 17 we will see how an SLSB can be wrapped in a Spring-managed bean that can be retrieved from the BeanFactory. In the listing the orderContext.xml file shows how a Spring-supplied class (SimpleRemoteStatelessSessionProxyFactoryBean) is injected with a jndiName and a JNDI location for telling it where a certain EJB lives.

The second point is the businessInterface property into which OrderService interface is injected. This is different from the EJBRemote interface and is just a Java interface that is also implemented by the POJO manager OrderServiceImpl.

Beyond that, it is business as usual. The SLSB can now be accessed just like any other bean managed by the Spring bean factory by using the handle orderServiceEJBProxy.

At this point, we have demonstrated that Spring can easily straddle an application that uses SLSBs at the service layer and service objects built from scratch using Spring.

Accessing the Bean Factory from a Web App
Now that we have defined services in the bean factory, how do we actually access the instance of those services? Spring provides several generic classes to make this task easier.

The ApplicationContext interface is at the root of the hierarchy of several interfaces whose implementers read the BeanFactory (or factories) into objects accessible by clients. The WebApplicationContext is one such interface for accessing the BeanFactory from a Web app, as shown in Listing 18.

First the web.xml of the Web app has the following lines supplied that tell the ServletContext about Spring's bean factory. The ContextLoaderListener loads up the Bean Factory configuration at Web app startup time. Next, the Order.jsp (that lives in the bundled Web app made2order.war) loads up the context from the ServletContext as shown in Listing 19. orderService and myProxiedServiceWithSeveralInterceptors are instances of singleton services that are defined in the BeanFactory.

Similarly, ClassPathXmlApplicationContext(paths) is another helper class that gets services from the BeanFactory as is used in the JUnit test suite's setup() method (see Listing 20). Note that a new BeanFactory can be swapped in at runtime by placing it in the classpath and destroying the current context.

Testing
Encouraging good testing practices is one of the value propositions of Spring. IoC is a good mechanism to encourage integration testing, whereas coding to interfaces is really what facilitates Unit testing.

In our example, jdbcOrderDAO can be easily replaced by a hibernateOrderDAO for conducting JUnit integration tests from within Eclipse, for example.

Similarly, instead of using a POJO manager implementation of OrderService, you can just as easily replace the implementation with the OrderEJB (which also implements the OrderService interface).

For unit testing on the other hand, EasyMock has been used. The class OrderServiceUnitTest only tests the service implementation by injecting a mock dao into the service layer. Since OrderDAO is an interface, this is easily achieved by casting the MockControl.getMock() method to return an OrderDAO instance. Then, by injecting the mockDAO to the service (setter injection), we can only test the code in the service. EasyMock uses the concept of recording and playback. The exact calls to the mockDAO are recorded first and then the test case is run. EasyMock asserts whether or not the playback is exactly the same as the one recorded.

For more detailed examples, look at the class OrderServiceUnitTest.java.

Because of the simple nature of this application, it certainly doesn't make it a good candidate for an example of test driven design. However, all else being equal, easily testable code will more be more likely to drive design than code that is hard to test.

Where Do We Go from Here
Spring provides an IoC and AOP-based framework to build infrastructure services. Even though we identified some EJB container-based services that are not needed; sometimes, depending on the use case, those services provide value. In those cases, remoting, security, and persistence can be applied to Spring proxy using the same mechanism that was used by transactions or auditing. This allows for open-ended growth where services are applied on an as-needed basis to certain Spring-managed service beans. The sample application does not show these additional features, however, the interested reader can explore Spring supplied support classes for:

• Remoting using Caucho's Hessian and Burlap protocols
• Security using Acegi
• Persistence using Hibernate

Summary
We have implemented the separation-of-concerns pattern by isolating business code from infrastructure code via method interception and Spring proxies. In addition, using IoC and the convenience of a BeanFactory, we are able to inject different implementations into different service contracts.

By moving to a POJO-based business tier, our design is not encumbered by bandwidth considerations as with EJB design. The design of the applica-tion can be as object-oriented and fine-grained as needed because we are not dealing with issues of multiple inheritance or layering.

We looked at the scalability issues and concluded that we can apply several enterprise-level services on an as-needed basis while still remaining cluster-able at a Web app level.

We looked at testing strategies and showed that coding to interfaces allows for the easy use of third-party testing tools like EasyMock. IoC via interfaces allows for integration testing using a configurable bean factory.

In the end, made2order is easier to maintain because we have removed infrastructure code from our business code. It is easier to test because of ease of configuration using a bean factory approach and coding to interfaces. Last, it performs better compared to an EJB-based solution because we are not interjecting a one-size-fits-all container in our business operations.

References

• www.springframework.org
• www.easymock.org
• www.juint.org
• maven.apache.org
• www.caucho.com/
• acegisecurity.sourceforge.net/
• www.hibernate.org/
• http://sourceforge.net/projects/aopalliance
• www.martinfowler.com/