A multitiered J2EE-based enterprise application is usually deployed on multiple J2EE application servers running on geographically separated machines. It may also integrate the services distributed in heterogeneous applications within an enterprise (such as an ERP application or a mainframe legacy application). The Java application servers may also be grouped in clusters for scalability and high availability. Improving overall system performance is becoming a challenging task.

To build a high-performance J2EE application, we will create a reference data service by downloading frequently used data from a mainframe legacy system to each J2EE application server, and design an efficient object repository to control object access and data synchronization with component-based analysis and design, the publish/subscribe messaging model, the Java event model, the Immutable Object pattern, and the Strategy pattern.

Before we discuss any performance tuning strategies, let's take a closer look at J2EE-based applications. A typical J2EE application consists of Web modules deployed on the presen-tation tier, EJB modules deployed on the business logic tier, and connector modules deployed on an integration tier and EIS tier. Figure 1 portrays a sample collaboration of components in a typical J2EE application.

The most time-consuming processes of the collaborations are the communications between the connector components and mainframe legacy application, the JDBC accesses between the data access components and database, and the remote method invocations between the Web components and the EJB components.

We can categorize business entities in a business domain into two groups: the static group that includes the entities whose states can only be changed by end users, and the dynamic group that includes the entities whose states may be updated through the business process. A sample of the static group is a profile of a customer in a Web-based banking system: the address of a customer can be updated by a bank teller. A sample of the dynamic group is an account of a customer: the balance of an account may be changed through the deposit, transfer, payment, or withdrawal process.

A reference data service is a façade that internally calls a mainframe legacy system that handles data for all applications in an enterprise. This article discusses an intelligent solution for a reference data service: create a cluster-wide object repository to store the data changed only by end users (usually saved in a mainframe legacy system) in the memory of each J2EE application server. The following is a summary of the benefits offered by this solution:

1. Automated vertical sync - the states of each object in any object repository are synchronized with the underlying mainframe legacy system.
2. Automated horizontal sync - the states of each object in different object repositories are kept in sync.
3. Data access service - provides coarse-grained interfaces to retrieve objects and their relationships from the object repository. Shields the complexity of location, access, transport, and conversion.
4. When the state of an object in the legacy system is changed by an end user, the change is immediately represented at each object repository.
5. Improving overall system performance by reducing the remote method invocations between the Web components and the EJB components, and the communications between the connector components and mainframe legacy system.

In the reference data service solution, the in-memory object repository distributes to multiple J2EE servers. These servers are grouped into different clusters. Some servers may be out of service and leave the clusters. Other servers may join the clusters and provide services. To keep data in sync among the servers, we use MQ JMS Pub/Sub messaging as the delivery infrastructure of the event. It decouples the destination of an event from the sender. The number of message producers and consumers can be dynamically changed. So the repository in one server is not aware of the existence of the repository in another server. The startup or the shutdown of one server will not impact the service of the whole object repository.

Java Event Model
The traditional solution of a refresh mechanism is based on a timer: the data in the memory is reloaded from a legacy system only when the timer expires. Any change that occurs before the timer expires is not represented in the memory. The timer-based solution may also cause system overhead when the timer expires but the data is never actually updated.

My refresh mechanism solution uses the Java event model (see Figure 3), which is based on the concepts of the event, event source, and event listener. The event source object maintains a list of listeners that are interested in receiving events that the source produces. When the Event Source object generates an event, it notifies all listeners that an event has occurred. The underlying mainframe system works as the event source, and the in-memory repository is the event listener. The event-based refresh solution updates the repository only when the state of an object is changed in the mainframe system.

Strategy Design Pattern
The Strategy Design pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently among clients that use it.

In my solution for reference data service, the Strategy pattern is used to fulfill the task of initializing the object repository in each J2EE server. As shown in Figure 4, the RepositoryController component in the business-logic tier delegates that task to the MQConnector component in the integration tier. The MQConnector fetches data from a legacy application and returns the result to the RepositoryController, which completes the task of loading data from a mainframe application to its in-memory repository by calling its strategy (MQConnector).

However, the RepositoryController component in the presentation tier sends that task to the ModelProxy component. The ModelProxy calls the remote RepositoryController in the business-logic tier to retrieve the objects from its repository, and then returns the result to the RepositoryController in the presentation tier. So the RepositoryController in the presentation tier uses its strategy (ModelProxy) to initialize its repository by getting the data from the RepositoryController in the business tier rather than from the mainframe application.

Immutable Object Pattern
The Immutable Object pattern increases the robustness of objects that share references to the object and reduces the overhead of concurrence access to the object. It accomplishes this by not allowing an object's state information to change after it's constructed.

We use the Immutable Object pattern to achieve the data integrity of objects stored in repositories. One object can be read by any component, but can only be updated or deleted by the RepositoryController class. The RepositoryController class implements both the feature of the vertical sync, which ensures that the state of the objects in a repository is synchronized with the underlying mainframe legacy system, and the feature of the horizontal sync, which ensures that the objects are safely kept in sync in each J2EE application server.