RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Clustering at the JVM Level to Maintain Business Logic Integrity

The typical three-tier architecture keeps the code Java developers need for clustering inside the business logic, making clustering a real chore. Clustering at the JVM level makes Java applications easier to write and cheaper to run.

he way a typical three-tier architecture separates the concerns of data-management logic, business logic, and presentation logic makes clustering, the practice of deploying a single application on multiple machines, a laborious and expensive task for Java developers. (See Sidebar 1. The Typical Three-Tier Architecture.) With the separation structured the way it currently is, business logic currently includes the code required for clustering. Without a clustering plug-in at runtime, developers are left to cluster their own business logic, the frameworks they use, and in some cases, the container in which it all runs.

Even in the simplest case of load-balanced Web applications with session state and servlet architectures, the application servers that cluster session are expensive and the clustering implementation impacts the business logic by violating the language's object orientedness. Java applications would be easier to write and cheaper to run if the Java Virtual Machine (JVM) could be extended through a plug-in, allowing multiple machines to cooperate as one. Clustering at the JVM level this way provides the Java developer with benefits that can drastically speed up his or her work. How drastically? Think crossing the United States on an airplane versus in a wagon train (see Sidebar 2. A Case Study: NTT Results from Terracotta Clustered JVM Solution).

Separating explicit knowledge of the deployment footprint or infrastructure logic from business logic (e.g., using JMS or databases to share serialized object state) presents another leap in the simplification of enterprise application development. Consider the challenge of scale-out. Today, it is an explicit deployment footprint characterized by many inexpensive servers running together under a single application, and developers "code" to it as a model. Scale-out should be delivered both as part of the infrastructure and as a runtime service. Allowing the deployment footprint to be determined at production time will lead to faster development, more robust applications, and greater performance.

This article explains the clustered JVM approach and describes its impact on Java from the developer's point of view (with code samples). It also illustrates the resulting performance, based on real world testing.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date