In the past few years there has been a proliferation of frameworks that allow for lighter, faster, and loosely coupled Java projects. These frameworks not only let you decouple your Java project from the application server for unit testing, they also allow for more agile refactoring, testing, and design techniques. This article will focus on telling the story of a large-scale refactoring effort implementing Spring and Hibernate as the underlying infrastructure tools. For those living under an abacus Spring is a J2EE framework built to handle many of the plumbing issues on a typical J2EE application. Hibernate is a popular Open Source Java object/relational persistence framework.

Bad EJB, No Donut
The last few years has produced a legion of J2EE applications tightly coupled to everyone's two favorite saviors, the Enterprise Java Bean (EJB) and the application container. Developers have tied their proverbial hands by coupling their code directly to these two Java mainstays. Many J2EE applications have been over-engineered and deemed overly complex by relying on these mainstays with few architectural best-practice guidelines to follow. Articles have been written and battle lines drawn around why and how this unfortunate series of events came to fruition.

Fortunately, there are now tools that provide ways to enable loose coupling and promote "simpler" architectures. Loose coupling encourages things like unit testing, test-driven development (TDD), and dependency injection. TDD is an approach to development that combines test-first development and constant refactoring. Dependency injection lets you inject dependent objects into your wired Java classes at runtime.

The First Step Is Admitting You Have A Problem
Everyone has probably experienced one or more applications built using the paradigm "'the more J2EE components the better." One of these applications was delivered to my doorstep for an extreme architecture makeover. The application owner's loose requirements were as follows:

• Scalable and reliable
• Flexible while resilient enough to support product changes
• Easy to integrate and test
• Loosely coupled so that disparate groups can work on separate components while simultaneously working on the application as a whole
• Enabling high developer productivity

Now, I understand that these requirements are ubiquitous requests for most applications and are almost assumed out of the gate. They can almost be seen as "infrastructure" requirements. Still, they're requirements and the right tools need to be used to satisfy them. Putting on my architect hat we came up with five problem areas that were symptoms of why these requirements aren't being met. From these symptoms we derived their root causes and solutions. Table 1 is a matrix showing our findings.

As you can see all of these issues had nothing to do with how the application dealt with business logic. They were solely infrastructure problems that had to be resolved for the application to reach a higher level of software maturity. Follow along as we see what an extreme makeover entails.

Patient Diagnosis - Condition Serious
The application needing the makeover wasn't small and continued to grow every day. A high-calorie diet of EJBs, deployment descriptors and other various J2EE infrastructure files was the norm. It had over 1,600 Java files, 50 entity beans, and over 20 stateless beans (that served mainly as entry points into the application for transactional boundaries). The application's main functions were order provisioning and workflow. It played an integral part in a service-oriented architecture (SOA) that encompassed over 25 Web Services. The software build and deployment cycle to the application server took over 15 minutes. I guess you could call it obese.

There were zero out-of-container unit tests. The only existing tests were written using Cactus, which is a unit-testing framework for executing server-side code. Loosely translated that means that by choosing tools like Cactus your code has to be deployed to the application server to be tested. I personally feel that tools like Cactus enable or even promote bad habits like not having tests that can be run straight from your integrated development environment (IDE).

After reviewing all of the symptoms, a diet of Spring and Hibernate was prescribed. These technologies were primarily chosen for their ability to solve given symptoms. The following is a diary of the patient's miraculous transformation from emergency room to recovery room. Each symptom was typically remedied in one software iteration. The refactoring project took about five iterations over a period of five months, with between 2-4 infrastructure developers working on it at any given time. As the refactoring took place, the business logic developers went full steam ahead sprinkling functionality goodness across the application. The refactoring team's core focus was solely on the infrastructure. A good analogy is that the engines were changed out on the airplane while it was still in flight.

Remember the Food Pyramid for Healthy Living
Symptom: Developers were interfering with each other
Root Cause: Poor code structure and no separation of concerns
Solution: Modularize the code base and adopt a layered architecture

Having a tightly coupled code base can wreak havoc on developer productivity. Interaction complexity is extremely high and one code change can potentially affect multiple areas of the code. The application can be classified as brittle and development typically takes much longer than in a layered architecture. Building layers in your architecture will lead to a well-defined separation of concerns allowing each layer to be understood as a coherent whole. Interfaces are typically used as the contract between each layer. By implementing the Interface pattern your application can now substitute each layer with an alternative implementation. The benefits of this paradigm will be discussed in greater detail in the next symptom. The first step taken to modularizing the code base was to break the project into five distinct sub-projects. These sub-projects were compiled according to their dependencies. This enforced that each layer only knew about the ones below it. Figure 1 offers a before and after picture of the logical code base.

Notice that each distinct functional area dictates where the layer boundaries are. These are not revolutionary concepts, just good pragmatic architectural decisions. A loosely coupled architecture makes adopting an Inversion of Control (IOC) container like Spring much easier than not. The next symptom's solution would be hard if not impossible to implement without a layered architecture.

Take Your Injections
Symptom: Unable to consistently run tests in a development environment or gather Web Services metrics.
Root Cause: Reliance on external Web Services availability
Solution: Dependency injection, aspect-oriented programming (AOP), and mock objects

With the advent of SOA came the troublesome deal of unit testing. As if testing wasn't hard enough, you're now reliant on someone else's application to execute unit tests. Another problem with a SOA is the inability to audit your service calls without intrusive metrics-gathering code throughout your application. The first order of business was to create an external provider layer with well-defined interfaces. Figure 2 shows the use of the façade pattern for all of the external Web Service calls done by the application. Classes in the external provider layer implement an interface and are injected into plain old Java object (POJO) business services.