Enterprise

This article provides a solution for improving productivity in scenarios where EJBs are used to implement business services using Spring, an Open Source POJO container, as a lightweight mock container for testing and using XDoclet attributes to define design-time considerations. The proposed solution has been validated using a POC. The subsequent sections explain the problem context, the different alternatives and their pros and cons, the industry trends and best practices, and a solution based on these trends and best practices.

Problem Context
One of the common debates while developing a business service using J2EE technologies is whether the EJB model or a POJO model is a better option. Let's analyze the good and bad aspects of these two choices. EJB Containers are standards compliant, usually backed by a vendor providing support. They provide several features required for enterprise-level business services:

• Enabling the service to be accessible remotely with inbuilt support for clustering (with load balancing and failover for the remote calls).
• Support for declarative transaction demarcation (that enables better reuse of the business services) with support for JTA (for distributed transactions) and propagation of the transaction context even across remote calls.
• Support for developing business services with an asynchronous invocation model through JMS and MDBs.
• Support for making the business services accessible as Web services through standardized mechanisms. They also provide support for EIS integration through JCA.
• Support for declarative security and propagation of the security context across remote invocation too.
• Provide tools for development like WSAD for WebSphere.

One of the biggest complaints about using the EJB model for developing business services has been the long build-deploy-test cycle involved in this approach, which results in low productivity. POJO Containers like Spring, which is an open source framework, have come up with solutions to fill this gap by providing the framework needed for developing business services using a POJO model, wherein the services are modeled as POJOs and Spring provides features similar to the EJB container like declarative transaction demarcation, etc. Spring also provides a good configuration mechanism similar to that provided by an EJB container.

Since Spring by itself doesn't provide the equivalent of JMS and MDBs and many of the features required for enterprise application development, including remoting, clustering etc., it can't be used to replace a J2EE container. Developing the business services as POJOs in Spring thus provide higher productivity, but it usually results in the services getting tied to Spring's equivalents of the J2EE container-provided features such as its declarative transaction model, remoting model, Web services stack, etc.

J2EE containers usually provide more robust, standards-compliant features than their equivalents provided by Spring. For example, J2EE containers are more likely to support the latest JSRs like JSR 109, which defines a standard and portable mechanism for packaging and deploying Web services, and similarly JSR 181, which defines a simple-to-use annotations-based model for developing Web services. There are several other JSRs such as 104, 105, 106, 156, and 157 for defining standards for Web services that are more likely to be supported by J2EE containers than Spring. Similarly the remoting capabilities provided by most commercial J2EE containers provide advanced features needed by enterprise services like support for clustering with load balancing and failover for the remote calls as well as transaction propagation across the remote calls, etc., through the remote EJB model and for the other models built on them. Similarly as explained in the article that is listed first in the References section, the EJB end-point model provides a simpler mechanism for developing Web services since the container takes care of serializing the requests to the EJBs. In comparison, the Web Tier end-point model is generally supported by POJO containers that require the POJO developers to take care of the synchronization aspects. So, strategically it's better to rely on standards-compliant and vendor-supported J2EE container features than Spring's equivalent features.

Trends
The EJB3 spec is trying to address some of these problems by providing an annotations/attributes-based mechanism that will allow the business services to be developed as POJOs and allow all design-time considerations like transaction demarcation and remoting to be defined through annotations (see the fifth entry in the References section). This enables the EJB interfaces and stubs to be autogenerated and allows the services to be developed and unit tested as POJOs. Some of the application server vendors are offering test harnesses and mock containers (refer to the test harness, Reference #2, provided by Oracle in their EJB3 preview, which supports testing entity beans out of the container) that provide the basic container features like JNDI and CMT needed to test services modeled as POJOs with the annotations. Unfortunately, EJB3 is still not finalized and it will be long before AppServer vendors provide support for it. The next issue is extending the support provided by the test harnesses for testing the business services outside of an EJB container, which may be limited and may not be portable.

Industry Best Practices
The following is a look at the best practices, in terms of use of technologies while developing J2EE applications, and especially modeling the business services:

• Use of Stateless Session Beans for implementing the stateless business services
  -A related pattern that recommends the use of EJBs with POJOs behind them (see Reference #3).
• Use of JMS and MDBs for business logic with asynchronous invocation.
• Use of the J2EE container-provided features like the declarative transaction demarcation (CMT) mechanism and its Web services stack-based features for making the business logic accessible as Web services.
• Use of POJO-based persistence model.

Solution
Solution Strategy
Using only Spring to model the business services is flawed because it wouldn't be based on standards and wouldn't leverage the high-end features provided by AppServer vendors, and using only EJBs has the disadvantage of low productivity. So, an ideal scenario is to use a J2EE application framework that combines the good aspects of these two options. It should provide a mechanism through which it allows POJO-based development to enable faster build-deploy-test cycles, thus overcoming the productivity issues associated with EJBs, but then translates all of the required features to J2EE/EJB container features so that the application can be deployed in an application server leveraging the vendor-supported container features. It should therefore enable using a POJO container such as Spring as a mock container for testing.