Today's web developers have a lot of choices when it comes to web application platforms. Among them, Java EE has always stood out as a "scalable" solution -- it may not be the easiest platform to prototype a web site, but it protects your software investment over longer terms. For instance, Java EE is a cross platform solution supported by many vendors. That means you can choose from many hardware, software, services vendors to accommodate the current and future needs of your applications. Java is also an OO language with well designed application frameworks / libraries, and a large pool of qualified developers. That makes your application cheaper to maintain over the long term. However, when it comes to enterprise features, the single most important differentiators between Java EE and competing solutions (e.g., from Perl, PHP, .NET, to the latest hype such as Ruby On Rails), is that Java EE servers are easy to cluster. You can simply add more hardware to handle more requests, without re-coding the application.

Easy clustering allows you improve your web application performance today, and more importantly, it can future proof your applications for new Internet architectures, and even new business models. For instance, AJAX (Asynchornous JavaScript and XML) technology significantly improves the usability of web applications. But to refactor your existing web applications to use AJAX, you should anticipate several folds of increase in web requests. That is because an AJAX page make multiple HTTP requests to the server to partially update the page, as opposed to one request per page in traditional web applications. Another example is the proliferation of SOA (Service Oriented Architecture) web services. Web applications in a SOA infrastructure are used to deliver component services instead of final UIs. An application typically needs several web service calls across different domains to gather enough information for a web page. As a result, the machine-to-machine interaction in the SOA world generates much more web traffic than the browser-server interaction today. In general, as we move to Web 2.0, web sites become less document-centric and more application-like. Those future needs call for more powerful application servers, and the best way to archive that is through application server clustering.

The core technology behind a clustered Java EE solution is the distributed in-memory cache. The cache is replicated on all server nodes in the cluster. Hence it acts like a cluster-wide shared memory. You can configure the cache to automatically expire old or less used entries, save its content to the disk when the JVM shuts down, and manage read/write transactions when several different server nodes access the same data concurrently. In a database driven web application scenario, the cache manages the distributed application state and optimizes database access.

First, the cache stores all the HTTP web sessions in the application. So, all the server nodes have access to the same user sessions at any time. The HTTP load balancer can direct any user to any server node. In another the word, the HTTP session cache makes the entire cluster transparent to both web users and developers, as if it is one single application server. The transparent cache increases developer productivity since it allows us to deploy applications written for a single application server to a cluster without any changes to the Java code. The cache also has good performance since it stores data in-memory. In contrast, in a Perl/PHP/Ruby based web framework, you typically have to cluster stateless application servers and save the session state information to the database. For every web request, the application has to load the user session from the database. Hence, in those non-Java EE frameworks, a clustered deployment requires significant changes in both code and database structure from the non-clustered prototype. Under the cache-less scenario, the clustered database has to be carefully partitioned by experienced architects to allow fast access to the frequently requested user session data. In a nutshell, the distributed cache is a critical component that makes Java EE web applications easy to cluster.

Besides HTTP sessions, the distributed in-memory cache can store any transient application state information that do not need to be permanently stored in the database. Examples of such transient data include workflow processes and status, real-time server statistics or sensor readings, incomplete transactions, and unprocessed communication data. The application state cache is especially useful in SOA applications where information displayed to the end users actually come from a variety of different sources that have their own persistence mechanisms. For instance, a web application can display the current weather, traffic condition, stock price, or promotional deals. All those information come from external SOA service components and are transient in the web application. They are best managed in the in-memory cache. With a generic distributed cache, multiple Java EE application servers can be deployed in a computing grid and share computing tasks transparently to the user.

For non-transient application data that do need to be stored in the database, the cache improves the overall application performance. The cache groups multiple database update operations into a single batch for a single trip over the network. It also stores frequently read database objects and queries, and provide the application fast in-memory access to those objects. In both cases, the cache reduces the database load, and more importantly, reduces the slow round trips between the database server and the application server. The database cache is especially important in AJAX applications since the it sends in many more incremental updates to the database (i.e., an auto-saving text editor) and asks for much more frequent database reads to incrementally updates the UI (e.g., an auto-complete text field), compared with traditional document centric web applications.

Database cache is widely used in Java applications regardless whether they are clustered or not. But for clustered applications, a distributed database cache is crucial to archive the best performance. The distributed cache's content is updated when any server node updates the database. Common Java persistence frameworks (e.g., Hibernate and EJB 3.0) allow cache to be transparently plugged in underneath their abstract data access API. You do not need to make any change to your data access code in order to take advantage of the cache. You can simply configure the cache service in your Java EE container.

The transparent distributed cache makes it easy to develop and deploy Java applications in clustered environments. In fact, most Java web applications, even prototypes, are already cluster-ready. You simply need to choose a cache implementation, configure it using XML files, and load it together with your application in a Java EE container. Unfortunately, there is no standard cache API or XML configuration files in Java EE yet (JSR-107 is an effort in this direction but it seemed dormant at this moment). The good news, however, is that you have wide variety of choices for distributed and transactional cache implementations, from the open source JBoss Cache to the commercial Tangosol. Most those cache frameworks can be used in almost any Java EE application server container. Check them out and future proof your Java EE applications!