Prevent Clusterphobia

Clustering improves scalability, but isn't completely portable between application servers

Reaching New Levels

There are many differences between application server approaches to clustering, each of which has an impact on the scalability of the application. For example, there are three different ways to make the session state available at the HTTP session level: replicating it in memory, storing it in the file system, or storing it in a database (Java Database Connectivity [JDBC] persistence). Within each of those three methods are other differences, too. If the session is stored in a database, what type of database is it? What capabilities are available for optimizing the access?

There are also relevant differences at the EJB level. For instance, what is the approach used for making a selection among a set of redundant servers within a cluster? One set of differences has to do with the location of the selection logic. The selection logic is intended to keep track of available redundant servers and decide which server to select for servicing a request. This selection logic may be located at the client itself, in a naming service, or at a centralized location.

Again, some application servers support more than one of these approaches, while others support only one. Those differences go a step further: Which algorithms or metrics are supported to distribute requests among available servers? It might be a simple round-robin scheme where servers are selected in a cyclical manner, with or without the facility for user-specified weights.

Your application server may allow you to tune distribution of requests based on metrics related to server load such as CPU load, disk input/output, memory thrash, or number of requests queued. Your application server may also let you control distribution of requests at a more granular level, such as the performance of individual application components. In this case some of the options may include availability of cached results, average execution time, frequency of execution, time lapsed since last execution, or component response time. Finally, your application server might allow you to manage the frequency of broadcast intervals for updating any of these metrics and synchronizing the component states among clustered servers. Better yet, the vendor may leave it up to you to implement your own, more advanced algorithm for finely tuned load balancing.

Clustering Around the Application Server

These are just some examples of the many differences between application servers, and clearly as an application architect you need to be aware of these differences. An application architecture designed with special attention to the needs of scalable/clustered solutions can help avoid the worst of the potential scalability surprises resulting from application server differences. For example, in general, your J2EE application design should minimize the number of remote calls that are necessary, because remote calls are far more expensive than local calls. However, when designing and developing for clustering, this widely applicable principle takes on a far more important meaning, because a clustered configuration by definition requires more remote calls than one that is not clustered.

Rate This Article Rating: 1 (best) 2 3 4 5 (worst) Comments: Optional e-mail address:

A number of tasks within a J2EE application can involve remote invocations. Examples of such tasks include naming service lookups, EJB invocations from clients such as servlets, method calls among EJBs, and multiple database connections within the scope of a single transaction. You can minimize the need for remote calls in several ways. For instance, you can reduce the number of naming service lookups through linked EJB references. You can reduce the number of EJB invocations from clients such as servlets by wrapping the calls to needed EJBs in distinct umbrella session beans for each application service needed by the clients. You can also reduce the need for remote calls by colocating the EJBs involved in a task into a single EJB container. Or you can reduce the need for multiple JDBC connections to more than one instance of a particular database within the scope of a transaction by accessing one database and then using your database facility to access the second database.

An awareness of the differences among application servers, combined with an application design that takes clustering into consideration from the beginning, should yield applications that are less vulnerable to the differences between application servers.

Should the J2EE specification include strict guidelines on clustering? While standards and portability are positive forces, so is the opportunity for competition. Encouraging creativity and different approaches within general guidelines yields better products than those that would result from specifying all the differences away. Just be sure you aren't misled by the notion of portability.

Ajaz Rana, Ph.D. [ajaz.rana@marchFIRST.com] is senior architect in MarchFirst's New York office.
Chris Gomes & Daniel Eng are application architects in MarchFirst's New York office.
Albie Collins is a technology partner in MarchFirst's New York office.