Practical J2EE Application Architecture

A typical enterprise application spans multiple tiers and may be distributed over several machines. Data may be accessed from any of these tiers based on the application design. For example, in a multi-tiered J2EE application, data from the persistent store will usually be accessed in the EJB tier. An application with high transaction volume and with a need to provide short response time to the clients may have multiple machines in the EJB tier accessing a single data store. In such applications, access to the data store can become very expensive because generally the backend data stores run on high-performance expensive hardware and software. Even when expensive hardware and software is used, the system may not easily scale when more users and information are added to the data store since the amount of information to be retrieved could grow exponentially. In order to provide a scalable solution, a cache should be incorporated in the enterprise applications. A cache provides the following benefits:

• Reduces the number of network calls by minimizing calls to the data store

• Reduces application latency

• Improves response time of the application

Common solutions offered today include the following:

• A web-tier cache is generally used to cache HTML pages or JSP fragments and sits in the web tier in front of the web server. More and more applications are moving toward JSP fragment caching. Some vendors provide custom tags for caching JSP fragments, which enables caching content produced within the body of the tag. The contents cached can be the final view of the content, or simply the values calculated for variables. The latter is useful when the presentation is independent of the computed data. The JSP Tag Library for Edge Side Includes, or JESI (JSR 128 at www.jcp.org), is a specification for a custom tag library that developers can use to automatically generate ESI code (ESI is a markup language that enables partial page caching for HTML fragments) using JSP syntax. For more on the ESI standard, refer to http://www.esi.org.

• An application-level cache is generally useful in applications that access data store directly in servlets, JSPs, session beans, or entity beans with bean-managed persistence. The cache then sits between the application and the data store. In this case, a JCACHE specification (JSR 107 at www.jcp.org)–compliant cache can be used to provide caching of Java objects once the objects are retrieved from the data store and transformed to its appropriate Java type. JCACHE standardizes caching of Java objects and provides for cache expiration, spooling, and cache consistency. For entity beans with container-managed persistence, the containers employ appropriate caching strategies. Vendors may provide some control over the caching strategy by using vendor-specific deployment descriptors.

• Some container vendors offer EJBs classified as read-only entity beans. This allows caching of entity beans that were marked as read-only. The configuration of caching attributes are provided via the vendor-specific deployment descriptor. Vendors also provide proprietary API for invalidating cached data. This solution is vendor specific and therefore not portable. It is expected that read-only entity beans with container-managed persistence will become part of the post-EJB 2.1 standard.

• Data stores also implement sophisticated caches. For example, an RDBMS will have a database cache to speed up database access and minimize the expensive disk block access and look ups. In this section, we discuss only application-level caches.

Application Data Caching

J2EE technology provides infrastructure support to enable developers to build multi-tiered, distributed applications using EJBs. In most multi-tiered applications, the most expensive resource from a price and access perspective is a data source such as an RDBMS. In such applications, it is beneficial to architect and design an application-level data cache.

Most application being built today have two types of data access needs:

• Transactional data In this case, the application reads and writes data to the data store.

• Read only data In this case, the application only reads data from the data store.

Transactional data does not lend itself well to caching. Generally, the frequency of changes to data causes too many cache invalidations. The frequency of updates also does not allow for a stable cache. This results in too many cache misses and defeats the purpose of caching. Thus, it is not a good practice to have a cache of transactional data. This is also true for any data where the frequency of updates can be measured in seconds and minutes rather than hours and days. In this scenario, the services offered by a J2EE container and the contracts specified for a container-managed persistence bean will be adequate. In cases where data is read-only, or it is updated less frequently, caching application data can provide good benefits. Resources permitting, read-only data is a prime candidate for caching in memory.