Modern advanced application servers, such as IBM WebSphere Application Server, are complex and mature products. Their state-of-the-art condition reflects the effort that has been put into the development and refinement of their capabilities.

WebSphere Application Server, in particular, features arguably the most compelling caching suite in the industry. This is one of the key differentiators of advanced brand-name server products. For example, if we were to compare Java enterprise applications to cars, an application server vendor would be the engine and drivetrain provider, with the application developer building their car around these components. But if you do not give performance proper consideration during early phases of your car design, you will not be able to take advantage of all the power IBM gives you. You car will be forever stuck in "overdrive off."

Dynamic Cache Service
One of the extremely powerful, but poorly understood and underutilized, features of WebSphere is Dynamic Cache Service. The idea of Dynamic Cache Service is simple: to take caching one step beyond static web content, such as images - to dynamically generated application content, such as servlets, JSPs and Web services. The dynamic cache service works within WebSphere Application Server JVM, intercepting calls to cacheable objects.

This feature carries an opportunity to dramatically improve server throughput and response time. At the same time, it does not require proprietary code and vendor tie-in. Sounds like next best thing after sliced bread. So why isn't it used to the fullest extent in an average Web application? Because typical dynamic content is not well suited for caching. For instance, in an online store, you absolutely cannot cache a shopping cart page the first time it is invoked and redisplay the same cart containing the same item to this and all other customers regardless of their choices. Dynamic content has been made dynamic for a reason.

Two steps to caching: Reusability and Reuse
But despair not! In many cases, you can turn your dynamic content into cacheable content. The key to caching is reuse. Caching makes sense when the content stored in the cache may be used again to service subsequent requests. This way you achieve a faster response and reduce the server processing load, freeing it up to process other requests and increasing throughput. In fact, one key measure of caching success is Cache Hit Ratio, the proportion of requests satisfied from the cache compared to the overall number of requests. It is obviously nothing other than the reuse rate.

So your goal is to achieve reuse of dynamic content. The task may be seen as a sequence of two distinct steps: reusability and reuse. First, you need to find a way to make your dynamic content reusable. This can often be achieved by using the proven divide and conquer strategy embodied in mosaic patterns that I describe below. The second step is to define the rules for content reuse. Just establishing that some content is reusable is not enough to set up caching. You must define how and when this content will actually be reused in your application. While "reusable" denotes possibility and potential, "reused" stands for realization of this possibility. So first you design what you can put in the cache, then determine when this cache entry may be returned to satisfy another request. Note that we are discussing generated dynamic content reuse at runtime here. It is different than code reuse for programming purposes.

Time matters
One simple way to achieve reusability is aggregation by Time. This idea has been thoroughly explored by traditional static Web content caching engines and means that for some period of time identical requests may return the same page without regenerating the page. To gain full control over the feature, you need time-based cache expiration and event-driven explicit invalidation or cache flush. Since these concepts have been used heavily by static content caching engines and are usually well understood, I will only note that WebSphere offers both expiration and invalidation features.

Create reusable content
The idea of creating reusable content first was presented to me during a performance tuning assignment. Our subject was a simple 2-tier Web application for catalog searching and ordering. The application was not meeting performance goals regardless of how we tuned the Application Server and Database tiers. Of special concern was the parts list (catalog) page. Further analysis showed that while each page was highly customized, they consisted of largely stable fragments describing individual parts. Rendering the page fragment for each part was database- and calculation-intensive and stressed the server. But the way each part was displayed was largely repeatable and in any case, could be easily parameterized. Dynamic Cache Service would work wonders here, if each fragment was a separate JSP or servlet output. By caching those fragments, taking into account limited parameterization, and assembling a catalog page of those cached elements, you could dramatically reduce the server load.

Out of this experience, the concept of mosaic patterns was born. Listings attached to this article show just such a catalog application. Main catalog page in catalog.jsp (Listing 1). Each part is rendered in a loop by product.jsp (Listing 2).

Mosaic Patterns
The art of mosaics has existed since ancient times. To create a mosaic, artists skillfully arrange small tiles to create beautiful imagery. Developers, too, can engage in some mosaic techniques. While these mosaic art works are all unique, they are made up of simple components repeated multiple times. Likewise, even though our dynamic Web pages might be unique, complex and one-of-a-kind, it might just be possible to split them into simpler parts.

Using the Mosaic pattern techniques suggest that you fragment your JSPs into smaller pieces with an eye on reusing these smaller fragments. While the entire page may be totally dynamic and must be generated anew with each invocation, you would look for smaller fragments that do not change as often and may be reused, either from one master page invocation to another, from one user to another, or even for all users during a certain time period.

This is a Mosaic pattern defined as applied to JSP design
Fragment your dynamic Web pages into smaller, reusable pieces. Make each piece a separate fragment JSPs and include them into the original master page using <jsp:include page="...">, <c:import url="..."> or an equivalent construact.

If you doubt whether splitting a page into small fragments is an acceptable practice in industrial-grade applications, look no further than IBM for examples. IBM's own WebSphere Portal is an excellent illustration of using mosaic patterns as it assembles its screens from a series of small JSPs. A portal page header alone is made up of not one, but at least five JSPs (see the Default theme files). You could follow in Portal's footsteps: look out for opportunities to split your pages into fragments which, while dynamic, do not change with each invocation and thus may be reused. Once these fragments are split out into separate JSPs, you can reap the benefits of servlet caching within WebSphere.

Note that creating cache-reusable content based on mosaic patterns is a non-invasive operation. Nothing you've done so far requires the use of WebSphere or constrains your choice of application server in any way. You may even delay implementation of caching until a later time. Your cache-reusable content will be waiting for you.

Reuse approach
Once you have identified reusable content, you are ready for the second step: describing the rules for actual reuse. WebSphere's Dynamic Cache Service looks for these rules in the file named cachespec.xml. In that file you specify which content is cacheable and how it can be reused. Dynamic Cache, by the way, is a multitalented tool, capable of caching servlets and JSPs, Web services, other internal services written to command pattern, as well as static content - all described in the cachespec.xml file. In this article, however, we will cover only servlet and JSP caching.

Reuse rules instruct the Dynamic Cache service what to do when a servlet or JSP output is cached and a new request for the same servlet or JSP arrives. The server can either return one of the cached entries for the page or let the Web Container generate the response anew, depending on whether the new request is "equivalent" to one of the cached versions or "different" from them all. (For caching purposes, "equivalent" requests result in the same response; otherwise, they are classified as "different.")

Cache IDs
When servlet caching is turned on, each request will first be processed by the Dynamic Cache engine. This engine first generates a String called Cache ID for each request and determines whether this request is cacheable in the first place. Then it checks whether a page with the given Cache ID already exists in the cache. If it does, the cache entry is retrieved and returned - no need to hit the Web Container. If it doesn't, the request is forwarded to the Web Container. Then, on the way back, the response is stored in the cache.