Modern J2EE Architecture Directions

Quite from "Sun Certified Enterprise Architect for J2EE Technology Study Guide" - ...If you systems do not perform and meet the expectations of the customers, then these customers will find other companies with systems that can handle their expectations. Therefore, the architectures you create can have a direct impact on your company's bottom line...

Introduction

This article was inspired by Rod Johnson's book J2EE Development without EJB. I was very excited when EJB came to live in 1998, it seemed like finally there was a generic solution to common problems that had to be solved over and over again in almost every project I was working on. Over number of years I started to come to a conclusion that EJB is not the best chose solution for most of the problems. Today this opinion is commonly shared among vast community of business software developers as well as open source developers. The Rod Johnson's book classifies the problems in very clear and constructive way and introduces the better systematic approach to solving problems EJB was originally intended to address. This article is my interpretation of the book and it also expresses some of my own ideas. For people that are passionate about developing the software, I recommend to read the entire book (http://tinyurl.com/59sb9). I realize that it's too much to expect busy people like we all are to read the whole book end to end, hopefully this article will grab the attention of those whose best interest is in writing better software.

Typical system Architectural components

We are going to review a very typical application architecture based on the architectural requirements that are most common these days for web applications.

Most of modern J2EE architectures clearly define 3 layers:

• Presentation layer
• Business service layer
• Data access layer

Comparison of Presentation layer technologies

Let's try to compare the technologies available to us for the presentation layer. We will only review web based solutions since thick client is not as commonly used any more:

Technology	Overall Definition	Tools support	Integration with the middle tier components.
.NET	Fairly easy to get started. Makes the developer work the Microsoft way.	Pure Microsoft solution. Microsoft has outstanding IDE. There is no much tools to choose from.	Plays nice only with Microsoft players. Otherwise requires sophisticated solutions like Web-Services which makes infrastructure very complex, testing difficult. Arguably the developers from different tiers have to obtain more skills when different technologies used on different tiers.
model 1 jsp	Fairly easy to get started. Quickly the maintenance becomes a major issue.	Good flavor of commercial as well as OS tools and libraries available.	Integrates well with Java middle tier. Usually Microsoft based solution is not considered on the middle tier when JSP is used on the presentation. Should not use the Remote Components unless there is a hard requirement upfront.
Model 2 jsp - MVC (Struts, Tapestry, Spring, etc...)	Steep learning curve. On the long run creates highly maintainable solution. Clear roles separation.	The same as with model 1 jsp	The same as with model 1 jsp

Comparison of Business service layer technologies

If we look in to Business service layer of some web based application today, most likely we will fined one of the following technologies:

• Remote EJBs
• Local EJBs
• .NET Serviced components
• ad hoc
• Service layer running in a lightweight container such as Spring

Here is a comparison chart of these technologies:

Technology	Following comparison criterias are used: * Simplicity * Productivity * Testability * Maintainability * Operational costs * Other Justifications and Limitations
Remote EJB	* Complex to implement and use business objects. Steep learning curve. The developers are expensive to train and hire. * Productivity tends to be poor, because of complexity of distributed and EJB programming * Testability is very poor. Almost impossible to test outside of the EJB container. Testing in the container is slow and complex. * From maintenance perspective, should only use when there is a hard requirement for remote access or multiple types of remote and/or local clients. Not easily portable to different vendors. * Operational cost is very high. High upgrade costs since heavily depends on the container APIs. Not easy to introduce new components without major redesign. Systems interdependencies tend to grow quickly which eventually creates a maintenance nightmare. Refactoring tools do not work due to the complexity of the underline APIs. * Usually requires significant investment in high cost EJB container (as an alternative - free containers like Jboss are gaining the momentum quickly). The support costs are usually very high. Troubleshooting problems in production is very difficult and not efficient.
Local EJB	* As complex as remote EJBs. * Productivity is slightly better then remote EJBs. * Testability is the same as for the remote EJBs. * Maintainability is the same as for the remote EJBs. Operational cost is as high as for the remote EJBs. * Can only use with in the same JVM as clients which comes with better performance then remote EJB. Still as hard to port to different vendors as the remote EJBs.
.NET Services Components	* Fairly simple. Relatively easy to make an object a "serviced component". * Good productivity, especially given Microsoft tools support. * Testability is problematic. Serviced components just like EJBs depend on the framework. * Maintainability and operational cost is comparable to the remote EJBs. * Microsoft solution - good choice when Microsoft is used across all layers. Not easy to integrate with other technologies. Runs best on Windows.
ad hoc	* Simplicity could vary on a lot of different factors, mostly depends on experience of developers creating it. Usually simple then the EJB based architectures. Can grow complex fairly quickly as soon as a need for services that EJB offers out of the box arises (things like declarative transactions). * Productivity varies on implementation, usually better then EJBs. * Testability depends on implementation strategy. Usually gets out of control quickly. * Maintainability might be better initially, very quickly becomes problematic. * Operational cost usually minimal (specially initially). As new requirements come up might quickly grow out of control with introduction of other 3rd party components serving the goal. * There is no really good excuse for coming up with the ad hoc solution these days. If the money is a concern there is a variety of OS solutions that will serve the most sophisticated needs. If money is not an issue, constraining the solution into 3rd party vendor API (like EJB or .NET) is better on the long run then reinventing the wheel.
Services running in a lightweight container such as Spring.	* It is as complex as POJO can get. With the IoC container they usually don't depend on container API. * Productivity is very high. The only performance hit associated with using this technology will come at initialization time (in case of any EJB container the initialization hit will be much more significant). * Testability is good. Easy to test simple POJOs in any environment - outside as well as inside the container. Does not require complex testing frameworks. Easy to configure environment dependent Java beans properties. * Maintainability is good. Easy to use refactoring tools. Major design flaws that can occur in any system are easiest addressed with this solution because of inherent simplicity of a component model. * Operational costs are minimal. Does not require high cost 3rd party container (can be used if required). * As simple as it gets. This is truly the way (not the only way of course) for creating loosely coupled components systems. Great community support (very high quality too). Clearly this solution defines a common trend in the industry and influencing the overall direction of EJB spec development (EJB 3.0 is more POJO oriented). Natively supports AOP (which is becoming an architectural requirement) which allows to introduce crosscutting concerns easier without intermingling the code throughout the system.

Questionable arguments for using EJB (quoted from the book, chapter 5, page 108.)

Ed Romans included a good summary of traditional wisdom in choosing when to use EJB in his excellence, if somewhat dated, Mastering Enterprise JavaBeans(Willey, 2001). This discussion is also available online at http://www.theserverside.com/resources/article.jsp?1=Is-EJB-Appropriate . Roman rightly attempts to enumerate the valuable services of EJB, replacing hype with rational argument. The main reason he gives for using EJB follows. However, the equations have changed since 2001 in nearly every case. I've summarized Roman's points in italic, and included my own discussion in normal font (*those are the discussions of Rod Johnson):

• Your system is built faster and more reliably Because without EJB's declarative middleware services such as CMT you'd need to develop your own infrastructure framework. Real-world experience tends to show that systems are not usually built faster because of EJB usage: rather, the reverse. But the crucial development since 2001 is that you no longer need to develop your own infrastructure to do without EJB's declarative services. For example, the Spring framework can deliver declarative transaction management without AOP. Before 2003, no credible alternative solutions existed.
• It's easier to hire new employees. You need to train employees if you use your own framework. This is another powerful argument against developing an in-house infrastructure framework - hardly ever an advisable way to replace EJB. But it's a poor argument against open source solutions such as the three mentioned earlier, which are themselves are widely understood. And it's an argument weakened by the complexity of EJB: a good alternative solution may be much simpler and easier to understand.
• You benefit from the best practices the world is building around EJB such as EJB design patterns. In practice, the existence of a patterns industry often divorced from reality is a good reason not to use EJB. J2EE applications using EJB are likely to have gratuitous and harmful architectural complexity, such as unnecessary remote method calls. In fact, the popularity of complex and often inelegant "J2EE design patterns" does not guarantee a sensible architecture. Application architecture should be driven by the problem at hand, not popular usage patterns around a technology such as EJB.
• You can support different user interfaces, such as thick clients and web clients. This is an argument in favor of implementing a distributed application with EJB. However, only for RMI/IIOP remoting is EJB the only reasonable choice for remoting. And the multiple client-type scenario doesn't occur as often in practice as in J2EE texts. If you don't need this complexity, don't incur it.
• You can work with industry-standard tools to rapidly develop your system. Tool support for EJB development in overrated. No amount of sophisticated tool support can make authoring EJBs as easy as authoring POJOs.
• You can separate your web tier and application server. Yes, but you rarely want to. If the web container isn't secure that is a major concern in itself. Also, an HTTP server such as Apache can be used to allow a firewall in front of all parts of the J2EE application server, including the web container.

Motivations for Spring

quote from the book follows as is (Chapter 7, page 144)...:

• To address areas not well served by other frameworks. There are numerous good solutions to specific areas of J2EE infrastructure: web frameworks, persistence solutions, remoting tools, and so on. However, integrating these tools into a comprehensive architecture can involve significant effort, and can become a burden. Spring aims to provide an end-to-end solution, integrating specialized frameworks into a coherent overall infrastructure. Spring also addresses some areas the other frameworks don't. For example, few frameworks address generic transactions management, data access object implementation, and gluing all those things together into an application, while still allowing for best-of-breed choice in each area. Hence we term Spring an Application framework, rather then a web framework, IoC or AOP framework, or even middle tier framework.
• To allow for easy adoption. A framework should be cleanly layered, allowing the use of individual features without imposing whole world view on the application. Many Spring features, such as the JDBC abstraction layer or Hibernate integration, can be used in a library style or as part of the Spring end-to-end solution.
• To deliver ease of use. As we've noted, J2EE out of the box is relatively hard to use to solve many common problems. A good infrastructure framework should make simpler task simple to achieve, without forcing tradeoffs for future complex requirements (like distributed transactions) on the application developer. It should allow developers to leverage J2EE services such as JTA where appropriate, but avoid dependence on them in cases where they are unnecessary complex.
• To make it easier to apply best practices. Spring aims to reduce the cost of adhering to best practices such as programming to interfaces, rather then classes, almost to zero. However it leaves the choice of architectural style to the developer.
• Non-invasiveness. Application objects should have minimal dependence on the framework. If leveraging a specific Spring feature, an object should depend only on that particular feature, whether by implementing a callback interface or using the framework as a class library. IoC and AOP are the key enabling technologies for avoiding framework dependence.
• Consistent configuration. A good infrastructure framework should keep application configuration flexible and consistent, avoiding the need for custom singletons and factories. A single style should be applicable to all configuration needs, from the middle tier to web controllers.
• Ease of testing. Testing either whole applications or individual classes in unit tests should be as easy as possible. Replacing resources or application objects with mock objects should be straightforward.
• To allow for extensibility. Because Spring is itself based on interfaces, rather then classes, it's easy to extend or customize it. Many Spring components use strategy interfaces, allowing easy customization.

...end of the quote