J2EE applications of late have become weight conscious. The combined burden of EJBs and coarse-grained component design has given the term test driven design a new meaning: technology driven design! Fortunately a host of lightweight solutions are emerging, such as PicoContainer, Spring Framework, Hivemind, Hibernate, Castor, and Webwork. In this article I'll discuss my experience with the Spring Framework and how it can be used to make a J2EE application more maintainable, testable, and better performing.

Although there are many areas that Spring 1.2.4 covers, I will be covering only Spring IoC (Inversion of Control) and Spring AOP (Aspect-Oriented Programming). These two along with the (non-Spring) concept of coding to interfaces form the cornerstone on which other Spring technologies are based.

Using Spring AOP and IoC we will see how you can replace container-provided infrastructure services for the following services, a la carte:

• Logging
• Transactions
• Profiling
• Auditing
• Exception monitoring

• Switching XA data sources for nonXA ones for certain methods
• Accessing stateless session beans (SLSB) via a Spring application context
• Accessing Spring application Contexts from a webapp
• Integration tests using IoC and JUnit
• Unit testing using EasyMock and JUnit

made2order Application
The made2order application showcases the above infrastructure services using the Spring Framework. Figure 1 shows the architecture of the application components.

The application consists of an OrderService interface implemented by the OrderServiceImpl concrete class. The OrderDAO interface is implemented by the JdbcOrderDAO concrete class. Finally the domain objects are represented by the Order and the LineItem classes. These six classes represent the POJO-based core business application (in magenta); the other classes are Spring classes (used for infrastructure functionality). JSP are used for presentation, packaged in the Web app, and there are two classes for testing

Database Design and Business Interface
made2order has a very simple database design shown in Figure 2.

The business interface for the made2order application is shown in Listing 1. The OrderServiceImpl class implements the above business methods. Note that the getDao() and setDao(...) methods are needed for "injecting" a dependent DAO (Data Access Object Pattern) into the service (we will see more about this later) http://java.sun.com/blueprints/corej2eepatterns/ Patterns/DataAccessObject.html.

The implementation of these methods deals only with the business logic (and DAO interaction). It does not have knowledge of infrastructure services such as:

• Transactions
• Logging of enter/exiting from methods
• Auditing
• Profiling long-running methods
• Reporting when exceptions occur
• Data source switching

Using made2order
The accompanying application is meant to serve as an example for the Spring technologies discussed in this article. The downloadable bundle at Listing 1 is a zip file that can be imported into the Eclipse IDE as an Eclipse project.

You can do either one of the following actions (or both) as you read through this article:

• Go through the source code using your favorite IDE and run JUnit tests to understand the examples. The JUnit test suite file (com.order.acme.OrderServiceIntegrationTest.java) in the test folder contains several methods to test the above services.
• Install the Web app in a J2EE application server (does not need EJB support) and navigate through the Web pages with the examples.

Spring Bean Factory and IoC
The Spring BeanFactory represents a class that manages the life cycle of singleton services (among other things). These services are injected with dependencies using Inversion of Control (www.martinfowler.com/articles/injection.html). Services that depend on external resources are "told" what those dependencies are instead of "getting" them using the Service Locator pattern (http://java.sun.com/blueprints/corej2eepatterns/ Patterns/ServiceLocator.html).

The injection of dependents is achieved either via a constructor or setter injection. The JavaBean that represents the service has a "set" method that accepts the dependant (setter injection) or it has a constructor that accepts the dependent object (constructor injection). Using an XML configuration file, the service object is configured with its dependent objects using either of these two mechanisms. (The XML file is just one of many formats the configuration can be specified in, others being properties files or just plain Java code.)

There can be one or more bean factories in an application. Bean factories can be overlaid, such that there is one for production but it's overlaid by the one for development.

The bean factory is accessed by the presentation layer to access services offered by the application. In made2order, the OrderService service is needed as a singleton. The OrderService implementation is dependent on an implementation of OrderDAO. The OrderDAO implementation in turn is dependent on JdbcTemplate object, (a Spring-supplied helper class that helps with JDBC operations). The JdbcTemplate requires an implementation of a data source. In this case, myDataSource is a data source implementation that is specified in the BeanFactory and injected into the JdbcTemplate.

The BeanFactory returns a singleton of OrderService after "injecting" required dependencies in it as shown in the Figure 3.

Note that an implementation is injected into an interface at each level.

Figure 3 is represented in the XML file orderContext.xml shown in Listing 2. In this listing we see that the BeanFactory defines two data sources. During configuration, either of the data sources is injected into the JdbcTemplate instance.

Spring Proxies
In the general sense of the word, a proxy is a class that sits between the business class and the client. In the context of Spring, however, a proxy is either a JSE dynamic proxy or a static proxy that implements infrastructure services and is "injected" with a dependency that is the target business class. Then, instead of the client being given a reference to the target service, it's given a reference to the proxy. In this manner the behavior implemented in the proxy is interjected into the service seen in Figure 4.

With the current release, Spring proxies allow interception at the method level only, whereas some full-blown AOP environments allow field-level interception also. Proxies can be dynamic (JSE dynamic proxies), in which case Java interfaces are proxied; or they can be static, in which case bytecode modification occurs. Understandably, static proxies outperform dynamic ones but only marginally.

Interception is implemented using concepts from AOP: pointcuts and advice.

Pointcuts and Advice
Advice classes specify the actual work to do upon interception whereas pointcuts tell Spring where to apply advice.

The combination of a pointcut and an advice is bundled in what Spring calls an Advisor (see Figure 5).

We will see Advice, Advisors, and Pointcut classes in action in a made2order application when we apply infrastructure services to the business classes.

The following sections explain how each infrastructure service has been implemented.

Transaction Service
The OrderService's placeOrder(...), modifyOrder(...), and dropOrder() methods need to be transaction-bound. For this we modify the orderContext.xml file by configuring a Spring-supplied transactional proxy called TransactionProxyFactoryBean. As shown in the Listing 3, an instance of this proxy is called myProxiedServiceWithSeveralInterceptors.

The TransactionAttributes section is supplied with regular expressions that represent the methods that need to be transaction bound (PROPAGATION_REQUIRED) and those that are not (PROPAGATION_SUPPORTS).

Also, the target of this proxy is specified as orderService, which is the instance of the OrderServiceImpl.

Note that a transactionManager is injected into the proxy. An instance of transactionManager is set up elsewhere in the configuration file.

The preInterceptors are a list of Advices and/or Advisors that are also tacked onto this proxy in what is called a chain of interceptors. We will see each of these in turn later. For now, note that preInterceptors are invoked before the target is invoked in the order specified.

Seeing Transactions in Action Using JUnit
For testing transactions there are two test methods in the test suite: testNonProxiedServiceForModifyingAnOrder() and testProxiedServiceForModifyingAnOrder(). Both these methods call the modifyOrder(...) method on the non-proxied service in one case and proxied service in the other. The modifyOrder(...) method updates the ORDER_TABLE table first and then each lineItem in the ITEM_TABLE. The test method updates an order with two line items. The second lineItem has a description whose length is greater than the column width in the database. This forces an error upon update of the line item description in the database. Both the test methods update the ORDER_TABLE first and then the first lineItem in the LINE_ITEM table before throwing an exception while trying to update the long description in the second line item. The proxied method issues a rollback whereas the non-proxied method commits the update to the ORDER_TABLE and the first lineItem in the ITEM_TABLE.