J2EE Application Deployment Considerations
Pages: 1, 2, 3

2.2.1 Resource Bundles (and Other Types of Static Resources)

Let's consider for a moment that there is a .properties file (a resource bundle) containing information that is required by several web applications. Because of the inherited ClassLoader relationship and isolation level, there are three ways to place this file:

1. Put a copy of the resource bundles in the WEB-INF/classes directory within each WAR file. The drawback with this approach is that if someone later decides that he needs to modify information within this file, he will need to go into each WAR file and make the same change. This is error-prone, to say the least.
2. Put the resource bundles file in a place that is specified by the system CLASSPATH. This solves the first problem of the need to modify multiple copies of the same file. However, this approach also limits your re-deployment options, as resources loaded by the SystemClassLoader can only be reloaded if you restart the JVM. In this case, changes you make to your resources may not be picked up until you restart the application server. For J2EE solutions where high availability is a concern, this will result in a more complicated system maintenance sequence.
3. Put the resource bundles and all related WAR files in the same EAR file, using the fact that the WAR ClassLoader may look into the EAR ClassLoader for resources. This system allows the greatest flexibility, as there is now only one place to update the resources. The update will take effect immediately if the enterprise application is re-deployed (provided that the application server supports hot re-deployment of EAR files). However, in order for each WAR to locate the resource, you must put the path to the resource bundles in the MANIFEST file of the WAR package.

2.2.2 Third-Party Libraries

It is not unusual for a J2EE project to include third-party software that is freely available (e.g., Apache's log4j). In this situation, it is usually better to place the JAR files for those libraries in a designated location in the EAR. The libraries should only be placed on the system CLASSPATH if the libraries will not conflict with existing libraries used by the application server and if the need to change or update those libraries is small. If you decide to put the common libraries inside of an EAR module, please make sure:

• All third-party libraries are centrally located in a designated location (e.g., /lib or /ext). This will make the job of the troubleshooting any problems easier by clearly identifying external components upon which this module depends.
• Because of the restrictions with the different ClassLoaders, you must put the path to the third-party libraries in the MANIFEST files of the J2EE modules, including WAR and EJB files.

2.3 Other Areas of Consideration

J2EE allows the development of highly scalable and highly available solutions in a relatively easy manner. As a result, a J2EE deployment architecture cannot be considered complete unless considerations are made for scalability and availability requirements.

2.3.1 Scalability

As mentioned in the beginning of Section 2, splitting the application into multiple deployment units at different tiers will provide the most flexible scalability model. However, careful considerations must be made to ensure that you have the proper granularity and modularity to balance between flexibility and performance.

2.3.2 Maintainability and Hot Deployment

Hot deployment is the ability to deploy and re-deploy an enterprise application without the need to stop and restart the application server. If hot deployment is a requirement for your application, take care to ensure that application resources, dependent third-party libraries, and other enterprise modules are packaged in a self-contained manner. Avoid building any dependency on the system CLASSPATH. Ensure that everything an enterprise application module may require is packaged within the same EAR file.

2.3.3 Security

Depending on the security requirements of the application, different security mechanisms (SSL, VPN, J2EE module declarative security model) can be implemented between tiers to provide security to the method level. Although the J2EE specification describes the level of security support required by the application server, it does not dictate how security should be implemented; as a result, security implementation is vendor-specific. If your application requires the propagation of security identities between different security domains (as with distributed security), you should definitely consult with the vendor, as there may be restrictions that would limit your choices in deployment architecture.

2.3.4 Deployment Automation

In an ideal world, all of the system administrators that you will come across would be intimately familiar with J2EE and the application server. However, it is not uncommon to find out that although your system administrator is a UNIX or Windows expert, he or she really does not know much about J2EE. So, for the benefit of those who will be deploying and managing the application on a day-to-day basis, having clearly documented deployment steps is a must. It would be even better to provide deployment scripts that automate the deployment of your applications. Many application server vendors today provide a way to deploy applications either through the vender-specific administration console or the command line, or through the Java Management Extension (JMX) API (e.g., the BEA WebLogic Management API). However, because of the different deployment mechanisms used by different vendors, you need to create different scripts for different platforms.

3 Future Direction

As more and more J2EE applications are written, it becomes crucial for the J2EE specification to define a common standard whereby applications can be packaged and deployed. J2EE 1.3 provides some specification with the packaging standard; however, there are still no standards on how to deploy an application — this is where the initiative like JSR 88 (the J2EE Deployment API) comes in.

The goal of the JSR is to define a standard API set that will enable any deployment tool to deploy any J2EE modules onto a compliant J2EE application server. Specifically, the standard addresses the following areas of concern:

• Installation: the ability to deploy a pre-packaged component to the container.
• Configuration: the ability to use a standard configuration mechanism to retrieve configuration data.
• Un-deployment: the ability to un-deploy a J2EE module from the container.

At this point, the JSR will be included as part of the J2EE 1.4 specification. With this new API, an application vendor may now create deployment tools or scripts that can automatically deploy his applications into different application servers without worrying about the differences in the deployment functions. However, there are still a number of areas that are not addressed by the JSR:

• J2EE resource deployment and configuration: deployment and configuration of J2EE resources, such as database connection pools, DataSources, and JMS, are still very much vendor-specific at this point.
• Security configuration: J2EE modules support a declarative security model by allowing the specification of security roles and groups within the deployment descriptor. However, if the security information is to be changed at deployment time, the system administrator still needs to rely on vendor-specific mechanisms to make those changes.
• Module dependency: although the new standard allows the specification of module dependencies with the deployment descriptor, the dependencies are not tracked. Thus, resources that are needed by a module are not automatically deactivated when the module is un-deployed.

4 Conclusions

Deployment is still an area in J2EE in which many developers are unfamiliar. If deployment issues are not considered during the architecture and design phases, you could easily run into situations that could lead to architecture and design changes. As illustrated above, there are many areas of consideration that should be taken into account from the beginning to ensure that your application will meet your scalability, performance, and availability requirements.

Allen Chan is the Director of Product Development for Wysdom Inc.

Return to ONJava.com.

Have a question about deployment? Ask Allen here.
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 3 of 3.

• WebLogic 8.1-J2EE1.3 , does it use JSR 88 ?
  2006-07-04 05:05:31  rommels [Reply | View]
  
  
  Hi,
  
  Very informative article.
  
  Have a query regarding Weblogic 8.1 that implements teh J2EE 1.3 spec. Since your article says:
  ----
  J2EE 1.3 provides some specification with the packaging standard; however, there are still no standards on how to deploy an application — this is where the initiative like JSR 88 (the J2EE Deployment API) comes in.
  ----
  does it mean that Weblogic 8.1 does not use this.
  
  I am aware that WebLogic 9.0 is J2EE 1.4 compliant and uses JSR 88 implementation for deployments, but not sure if WebLogic 8.1 uses JSR 88 as an extension?
  
  Thanks and Regards,
  Rommel Sharma.

• BEA Application Redployment
  2003-11-12 08:04:38  anonymous2 [Reply | View]
  
  
  In some cases when I use BEA's Web Console Manager and I redeploy or even un-deploy and deploy a site I am unable to see the latest changes. A technique I use is to serialize the index.jsp page (ie. 11112003a) and then do a view source I don't see the correct serial number I use. Is this a cache issue? What can I do for force a reload after the app has been re-deployed? I know about shift-refresh in IE, anything else?
  
  Please cc me at rtedesco@janus.jnj.com. Thanks in advance for your help!
  
  Rob

• General comments and insights
  2003-06-12 07:57:22  kadams54 [Reply | View]
  
  
  First off - Allen, thank you for the article. We'll be passing it around to our developers and deployers.
  
  Secondly, two comments based on my experiences in a build manager/deployer type role for the past 2 years (that's a lot of two's):
  
  1) We originally wanted to pursue an architecture like the one described in this article (where the 3 tiers are separated out); however, we ended up deciding to bundle all of our web applications into an EAR with the EJBs they depended on. Why? Our finding was that, in our application server, WARs were loaded (into the classloader) as peers to EARs if they were outside the EAR. In fact, the WebLogic resource the article points to (http://e-docs.bea.com/wls/docs70/programming/classloading.html#1073506) touches on this restriction:
  
  "Although you could deploy the WAR and JAR files separately, deploying them together in an EAR file produces a classloader arrangement that allows the servlets and JSPs to find the EJB classes. If you deploy the WAR and JAR files separately, WebLogic Server creates sibling classloaders for them."
  
  The text goes on to say that WAR files and JAR files can be located separately, but only by including home and remote interfaces in the WAR file, which brings me to my second comment.
  
  2) The article does not address the problem of dependencies between EJBs that cross EAR files. In this case, as in the case of WARs and JARs that are not in the same EAR, the dependent component must have the proper interfaces (and supporting classes) co-located in its container. J2EE provides a mechanism for accomplishing this in the EJB client JAR (for more info on this JAR, including how it is produced and how it is used, see "J2EE.8.1.1.2 Dependencies" in http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf).
  
  In reality, this approach is the cause of many of my headaches. When one EJB changes, you must update the client JAR in the other EJBs and WARs that use it to ensure there are no marshaling errors. This change must occur in all environments (dev, test, and production), and will likely require cross-team coordination on the testing. The development/support teams responsible for each EJB must test to ensure there is no negative impact from the change.
  
  These interdependencies become overly-burdensome as re-use increases. You can manage them to a reasonable level by increasing the automation, both in your deployment and promotion processes and in your testing processes. But even automation comes with its own problems, as convincing managers to include time for automated testing and build management can be a frustrating task.
  
  Perhaps that's why I'm becoming a bigger and bigger fan of any solution (tuples or n-spaces, web services, etc.) that lends itself to component communication without involving classes. Otherwise the components are just too tightly coupled.