J2EE Application Deployment Considerations

2.1 Performance Consideration

It is common understanding that remote calls are more expensive and take longer to execute than local calls. During a remote procedure call, the local proxy objects must make copies of all of the arguments and transport them over the wire, through RMI, to the remote objects, resulting in increased network traffic and slower response time.

Consider the scenario where the user issues a command through a web page, which in turn invokes the servlet, followed by the processing of the business method in the session bean and entity bean. At least four network operations may occur, two of which are remote EJB calls:

Figure 5. Remote Call Sequence in a Typical Business Operation

In the case where a session bean may call other session beans or multiple entity beans, additional remote calls will be made. If performance is a top priority concern, adjustments must be made in the architecture and design to reduce the number of remote calls or reduce the cost of a remote call.

There are multiple ways to address this performance problem:

1. We could reduce the number of network trips by using coarse-grained design patterns for the EJBs.
2. We could eliminate some remote calls by using local, rather than remote, interfaces for entity beans.
3. We could turn some remote calls into local calls by changing the packaging structure to maximize the number of beans within one EAR.

2.1.1 EJB Granularity

If the access interfaces are too fine-grained, it results in excessive network traffic and high latency. One must investigate the architecture and design to ensure the right level of granularity is being used. There are several J2EE design patterns that can control granularity. The two most famous are transfer object and Session Facade. Since the focus of our discussion is on deployment and packaging, please refer to the J2EE Blueprints web site to learn more about these patterns.

2.1.2 Local Vs. Remote Interface

J2EE 1.3 introduces the concept of local enterprise beans. This will allow an entity bean to expose a local interface, thus allowing parameters to be passed by reference rather than by value. However, in order for a session bean to access local enterprise beans, the local enterprise beans must be packaged in the same EAR file as the session bean. There are two ways to achieve this:

• Create a Session Facade in front of the entity beans at the data tier. This will allow us continue to expose the functions of the entity bean to external applications. However, depending on the granularity of the Session Facade, it may not give you much performance gain.
• Move the entity beans into the business tier and allow the session beans at that layer to access the local enterprise beans directly. This reduces the reusability of the entity bean. Since the local entity bean is now only available for beans that are located in the same EAR file, other business beans residing outside of this application module will not be able to access it. This may result in duplicate instances of the same entity bean within different application modules. Scalability options for the application are also reduced, as the local entity bean is now tied to the same J2EE container used at the business tier.

2.1.3 Packaging Structure

Some J2EE application servers (e.g., BEA WebLogic) may optimize remote calls between beans (see the WebLogic Reference Document on Classloading) into local calls if the beans are in the same enterprise application. This is especially beneficial if one session bean may call multiple session beans or entity beans. There are drawbacks with this approach as well:

• Reduced maintainability. All of the beans that are packaged within the same EAR must be deployed and re-deployed at the same time. This will prevent the possibilities of upgrading or changing just one bean at runtime.
• Platform dependence. This kind of optimization is not offered by all application servers, and it may not have any effect if you switch application server vendors in the future.
• May break design assumptions. Many developers design their beans with the assumption that all parameters will always be passed by value instead of by reference. Changing the calling convention may break that assumption, especially if the transfer object pattern is being used together with BMP entity beans.

2.2 Resource Location Consideration

Another area where we should consider is the location of common resources and libraries. One rule of thumb is that a resource should go together with the J2EE modules that use it. However, if you have the case where a common resource is being used by several modules, you may want to place it where it is accessible by all of the modules. In addition, it is a bad practice to put resources in your system CLASSPATH as they may cause conflict with other J2EE modules deploying in the same container. This will also limit your options in terms of hot deployment.