Igor's Blog

Achieving better object oriented design and ability to use TDD by using Lightweight containers.

by Igor Stoyanov.

Many J2EE web applications contain too much code in the web tier. There are various reasons for this, but I think the most important are:

- Too few books emphasize the importance of a thin web tier. There are many books discussing MVC frameworks, emphasizing on the importance of properly designed web tier, separating control logic from presentation logic but much less of how the web tier should related to the rest of the application.

- There are many web frameworks but there’s no framework for business objects.

- Putting business logic in the web tier is often perceived as the quickest path to a solution. The previous point helps to understand the cause of this common misconception. However, it is a misconception, as working with a more sophisticated architecture will quickly show.

Until recently, the only framework that addresses partially some of these issues was EJB. Although, there are many problems and complexity related to using EJB, this was the primary framework for managing business tier objects. There are many nice thing specified in EJB such as declarative transaction in container management of business object, scalable remote architecture, very fine grained declarative security. However, the complexity of implementation, problems with performs in some cases, difficulties to test and too much overhead form majority of J2EE applications cause the emergence of lightweight container for managing business transaction.

The most popular lightweight containers are Spring framework, Pico container and HaveMind. These lightweight containers take some of the successful ideas from EJB to bring a greater level of sophistication to non-EJB architectures. They are similar to EJB arhcitecures in being centered around a layer of managed business service object. However, this is where the similarity ends. Instead of running inside an EJB container, business objects run inside a lightweight container. Lightweight containers aren’t tied to J2EE, have negligible startup cost and eliminate the deployment step of EJB.

The beauty of lightweight containers is that the business objects that they manage are POJO running inside of the containers. They are managed via AOP interception to deliver enterprise services. Unlike EJBs, they don’t usually need to depend on container APIs, meaning that they are also usable outside any container.

All these factors make lightweight containers the preferable choice if using Agile Methodologies together with TDD. According to agile, the design and implementation should be driven by the business requirements not by unnecessary complex specifications that have to be implemented. According to TDD, this is currently the only choice in order to achieve superior design and quality of the software application. This is of course if you have the freedom to choose technologies to work with.

I will look more closely at the currently most advanced lightweight container – Spring Framework. There are so many things that Spring Frameworks provides to make development easier that it is very hard to be described or summarized. I will talk about the most important of ones:

- Interface-implementation Separation

EJB enforces a separation between interface (component interface of business methods interface) and implementation (bean implementation class). This is actually one of the best things in EJB, as programming against interfaces rather than classes is a best practice with many beneficial consequences, such as “pluggability”.

Most lightweight containers do not enforce such a separation. However, they do recommend doing it, but in my experience, giving more freedom to developers doesn’t always provide better results. At least in this situation, I would rather prefer EJB approach of enforcing implementation against interfaces.

- Inversion of Control (IoC)

Most business objects have dependencies, such as other business objects, data access objects and resource. Because of that, there is a need to look up other managed object and resource, and therefore must dependent on a container to satisfy that. In satisfying this look up services lies the major difference between EJBs and lightweight containers as Spring framework. Both architectures achieve this look up service by Inversion of Control (IoC). The difference is that EJB architecture implements IoC with Dependency Lookup opposed to Spring framework, which implements IoC with Dependency Injection.

- Declarative Transaction Management

This is almost similar to EJBs architecture. The difference is that Spring frameworks provides much finer grained transaction management and much more flexibility in specifying transaction strategy.

The next diagram illustrates a typical Spring framework web application architecture. The Spring architecture is conceptually similar to the “local EJB architecture”. However, it tends to work out very differently in Practice.

Reference:

Example application using Strust and Spring could be found at:

http://www.onjava.com/pub/a/onjava/excerpt/BFLJava_chap8/

Explanation of how Spring handles multithreading at (very good):

http://www.javalobby.org/articles/thread-safe/index.jsp

Example simple application using Strust+Spring+Hibernate(should probably start from here):

http://www.onjava.com/pub/a/onjava/2004/04/07/wiringwebapps.html?page=1

Many useful materials can be found at AppFuse project:

http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse

Of course, there are lots of materials and examples at www.springframework.org