Build strong, flexible J2EE apps with a WebSphere cluster environment

When you need strong, extensible, and flexible J2EE apps, tap into a WebSphere® cluster environment. This article describes what you need to consider when designing a Web-based application in a WebSphere Application Server cluster environment, including application file update and synchronization, serialization of session objects, and dynamic caching. Don't have the WebSphere Application Server software? Download a free trial of WebSphere Application Server version 6.1 for Windows and Linux.


Bin Zhou (, Software Developer, IBM

Bin ZhouBin Zhou is an Advisory Software Developer in the IBM Beijing Lab, China. His main focus is on WebSphere Commerce contract and pricing components development.

07 June 2006

Also available in Chinese


When building a strong, extensible, and flexible J2EE application, you need to consider several factors. One important consideration is allowing the application to run efficiently in a cluster environment. This article discusses what you need to consider when designing a Web-based application in a WebSphere Application Server cluster environment.

The WebSphere Application Server clustering mechanism allows a complete application server (including EJB container, EJBs, Web containers, Web modules, and servlets) to be copied as a cluster. Clustering provides workload management and failover of URL and EJB requests. Individual cluster members, which are identical copies of the cluster, can run on nodes within the WebSphere cell. The cluster can be on the same node or on different nodes. A Network Deployment cell can contain no clusters, or have many clusters depending on the administration needs of the cell. For information about WebSphere Application Server cluster, see the WebSphere Application Server online help.

There are two types of cluster topology, vertical cluster or horizontal cluster. A vertical cluster has cluster members on the same node, or a physical machine. A horizontal cluster has cluster members on multiple nodes across many machines in a cell. This article will discuss the horizontal cluster topology as shown in Figure 1.

Figure 1. Cluster topology
Cluster topology

We will discuss three considerations when you design a Web-based application:

  • Implementing application file synchronization: We will look at what is the common mechanism and how you implement it using a new feature of WebSphere Application Server 6.0.
  • Serializing the session object: Since objects that have been included in a session will be synchronized across nodes of a cluster, they must be implemented with the serializable interface. An example is provided to show how to do this coercively.
  • Using dynamic cache: We will discuss sharing Java™ objects across a cluster by using WebSphere Dynamic Cache and Data Replication Service.

Implementing application file synchronization

In the enterprise application lifecycle, it is common to update a deployed application by applying fixes, adding new Web contents, or updating application behaviors. Generally, the application provides a user interface to allow the user to upload the file, which will be changed or created on the server side.

Take the following scenario as an example: a user wants to update the Web site logo image file and the original file is archived as part of a .war file application. The application provides relevant function and a user interface allows the user to fulfill this task. Then the user selects a new image as the new Web site logo and uploads it. The system uses the new file to replace the original image file and the change is visible when the user accesses his Web site again. Everything is running smoothly in the environment with a single node of the application server. However, there are some problems in the cluster environment.

In a cluster environment, shown in Figure 2, the upload request from the user will be received by the Deployment Manager in the WebSphere Application Network Deployment server, and then it will be dispatched to Node A. Node A will execute the corresponding business logic and replace the original image with the new one on its local file system. While the other member of the cluster is not aware of this change, its local copy is not updated. As a result, the file is inconsistent across the members of the cluster. Once Node B takes over the request, in case Node A breaks down because of a fatal error, the original Web site logo is used. It looks like the customer lost his changes.

Figure 2. Inconsistent file in a cluster environment
Inconsistent file in a cluster environment

This means when an application is running on WebSphere Application Server, it requires that the configuration files, binary files, and resource files be synchronized among the cluster members. There is a mechanism to handle the above issues. The solution is using a shared file system (for example, NFS) or a shared database. In this solution, all the changed or updated files are put into the same shared file system, or put into the same database. For the shared file system, all the applications use the same location, so any file change is visible to the applications. For a shared database, applications can get the changes from the database.

The disadvantages of the above solution are:

  • The shared file system and database cause a new single point of failure.
  • It increases the complexity of programming and configuration.
  • It introduces a new performance bottleneck.

Another solution is using the fine-grained WebSphere Application Server application management API to implement the file synchronization across each member of the cluster. This feature is provided in WebSphere 6.0. WebSphere 6.0 has many improvements to make application deployment easier and more efficient. For more information, see the WebSphere Application Server Information Center. One of the most significant improvements is allowing a portion of the changed application code to be presented to the system. You do not need to stop the current running application.

WebSphere 6.0 also provides flexible application file management. It allows application updates by:

  • Replacing an entire application (for example, a full .ear file).
  • Replacing, adding, or removing a single module in an application (for example, .war, EJB.jar, or .rar files).
  • Replacing, adding, or removing a single file.
  • Replacing, adding, or removing multiple files.

After application files are updated on one of the members in the cluster, another new feature, Rollout Update, is used to synchronize the file on each member across the cluster. It updates an application by:

  • Saving the updated application configuration.
  • Stopping all cluster members on a given node.
  • Updating the application on the node by synchronizing the configuration and restarting the stopped cluster members on that node.

Let's go back to our previous example about the Web site logo update. In this scenario, the logo update and synchronization should be a parent to the user without the manual intervention of a WebSphere administrator. That means the application has to control the application update, such as replacing the original file that was archived in the ear file, and performing the file synchronization across members of the cluster. You can do this by invoking the Java Management Extensions (JMX) interface provided by WebSphere. JMX is a standard for Java application resources management. For more information about JMX, see the JMX Web site. Figure 3 shows the flow of updating and synchronizing the file using the fine-grained update feature.

Figure 3. Updating and synchronizing files using the fine-gained feature
Updating and synchronizing files using the fine-gained feature

Once the application receives the file that was uploaded from the user, it calls the File Updater to construct the delta EAR file. The delta EAR is an archive that has the same structure as the full application ear file. The difference between the delta EAR and the full application EAR is that the delta EAR only includes the file you intended to update. The File Updater builds this delta EAR. It can be a simple Java class that encapsulates the delta EAR generation logic, or a relevant complex component that adds the validation logic and the generation file.

Serializing the session object

Clustered applications can improve system reliability and availability. However, this also introduces some challenges, such as session management. The HTTP session is a collective that includes user-specific information. The session is maintained by a container for a period of time, from the beginning of the user's access to the end of the user's last access. A session consists of a series of session attributes. These attributes are actually Java objects that may have been created by the system or a developer.

In a cluster environment, developers must be aware that the HTTP session can run in multiple JVMs. The session attributes should be kept consistent in each JVM. Otherwise, the same input may cause different results when the application runs on different nodes because the user-related data is inconsistent in these two nodes.

WebSphere provides real-time fully coherent data sharing for clustered applications. However, the precondition is that all shared attributes must be serialized and deserialized. When you put a Java object into a session and want it shared across all nodes, declare this Java object as a serializable interface. The following code shows the validation when putting an object into session attributes.

public class MySession{ 
      public static void addObjectToSession(HttpServletRequest req, String key, 
      Object value) 
           HttpSession session = req.getSession(true); 
           if(value instanceof Serializable) 
                session.setAttribute(key, value); 
                throw new NonSerializationException (); 
      public MySession() 

In the above example, you create a new class named MySession to add objects into a session. You can add it by calling the addObjectToSession() method. You first check whether the object implemented the serializable interface. If it did, then add the object into the current Http Session. Otherwise, a NonSerializationException occurs. Sometime the information included in session attributes will be insignificant when it runs in another JVM, such as an absolute director of the file. In this situation, make these fields non-clustered by declaring them as transient.

Using dynamic cache

As mentioned above, keeping the application data in a central database ensures consistent server write and consistent read data in the cluster environment. The disadvantages of this solution is that the database server introduces a new single point of failure (SPOF) and may not be suitable for applications that require high performance. Another solution is using WebSphere Dynamic Cache and Data Replication Service (DRS). You can implement this solution in the memory-based object cache and by sharing objects on certain servers across the whole cluster. Figure 4 shows the architecture of WebSphere Dynamic Cache with Data Replication Service.

Figure 4. WebSphere dynamic cache overview
WebSphere dynamic cache overview

WebSphere Dynamic Cache is the solution for J2EE architecture and cache objects. The output of the Web service, servlet and JSP in the presentation layer, WebSphere command classes, and Java object can all be cached by using application programming interfaces (APIs) or by declaring cache policies and adding them into the application.

Data Replication Service (DRS) is an internal WebSphere Application Server component that replicates data. DRS makes data for session management, dynamic cache, and stateless session bean available across servers in a cluster. Dynamic cache can take advantages of DRS in the application server to replicate cached data across servers in a cluster. Invalidations are transmitted across the cluster to keep the data consistent and valid. Figure 5 shows sharing application data across clusters by using dynamic cache and DRS.

Figure 5. Shared object in a cluster
Shared object in a cluster

At first, applications are running on Server One and putting Object A into its local cache by calling the DistributedMap API. By configuring correctly, DRS replicates the cached object across the whole cluster and keeps the consistency of the cached data. As a result, Object A is replicated to the local cache of Server Two. When the application runs on Server Two (in case Server One encounters problems or the transaction is dedicated to Server Two according to the load balance policy), the application can now consistently pick up Object A with Server One from the local cache of Server Two.

WebSphere Application Server stores and manages cached Java objects by using cache instances. Cache instances are also used to logically group related objects. Objects stored in the cache in a particular instance are not affected by other cache instances. As mentioned above, the DistributedMap public interface gives the application direct access to cache instances.

An application can store and retrieve any object that implements the java.util.Map interface. Any other Java objects that you cache must be implemented as a or interface. Servers in a cluster access cache instances by using its JNDI name. These servers must be in the same replication domain. The code example shows how the application looks up a cache instance through its JNDI name, puts an object into a cache instance, and then retrieves it later.

Import javax.naming.InitialContext; 
InitialContext context=new InitialContext(); 
DistributedMap map=(DistributedMap)context.lookup("cache/example_cache_instance");
map.put("cache_id", yourJavaObject);
YourJavaObject obj=(YouJavaObject)map.get("cache_id");


This article discussed three aspects to consider when designing an application that runs in a WebSphere cluster environment. Application data stored on files system should be consistently kept in each cluster server. The solution for this requirement is using a shared file system or a shared database. Using the fine-gained file update feature, you can have a more flexible application file across the cluster, and avoid introducing a new single point of failure. Session management is an important consideration for a Web application. You should consider making the object serialized and deserialized so that it is shared across the cluster. You can use self-defined classes to encapsulate objects into a session and then execute the validation at the same time. You can also implement application data sharing across a cluster by using WebSphere Dynamic Cache and Data Replication Service, which significantly improves the performance of the application.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

Zone=WebSphere, Architecture
ArticleTitle=Build strong, flexible J2EE apps with a WebSphere cluster environment