WebSphere Application Server dynamic cache service

---

WebSphere Application Server dynamic cache service is an in-memory cache system that has disk off load capability. Its caching behavior is described in the form of XML cache policy files. Cache policy is configured when building the XML configuration files, or with graphical user interface (GUI) tools such as the WebSphere Application Server's Administrative Console or the Application Assembly Tool.

Unique ID strings distinguish unique entries in WebSphere Application Server's dynamic content caching solution. These ID strings can be defined declaratively with the XML configuration file or programmatically by the user's Java program.

WebSphere Application Server dynamic cache service can control external caches. Different groups of external caches can be defined, each with its own set of member caches. The interface between WebSphere Application Server and external cache is the External Cache Adapter provided by WebSphere Application Server.

WebSphere Application Server dynamic cache service includes an alternative feature named disk overflow, which stores the overflow cache entries on disk for potential future access.

Servlet/JSP Result Cache

Servlet/JSP Result Cache intercepts calls to a servlet's service method, and checks whether the invocation can be served from a cache. If the servlet cannot be served from cache, the servlet is invoked to generate the output that will be cached. The resulting cache entry contains the output; the side effects of the invocation, for example, calls to other servlets or JSP files; and the meta data about the entry including timeout and entry priority information (see Figure 5-4).

Figure 5-4: WebSphere Application Server Servlet/JSP Result Cache

Servlet/JSP Result Cache caching can be based on:

• Request parameters and attributes

• The URI used to invoke the servlet or JSP

• Session information

• Other options, including cookies

Figure 5-5 shows that the Servlet/JSP Result Cache can be used to cache whole pages or fragments at the WebSphere Application Server. A page, A.jsp, is made up of three fragments: B.jsp, C.jsp and D.jsp. All three fragments are independently cached at the application server.

Figure 5-5: Caching fragments with the Servlet/JSP Result Cache at application server

The cache entries generated by Servlet/JSP Result Cache can be cached at the presentation layer. Alternatively, they can be pushed to external caches, such as the cache component of WebSphere Edge Server or IBM HTTP Server. See the section Edge of Network Caching Support for more information about external cache support.

For J2EE applications that have high read-write ratios, Servlet/JSP Result Cache creates an opportunity for significant gains in server response time, throughput, and scalability. Moreover, since Servlet/JSP Result Cache is nonintrusive and is enabled declaratively, currently deployed and running Servlets/JSPs can be configured to take advantage of dynamic content caching without changing any code.

Command Cache

Command Cache introduces the next level of granularity to dynamic content caching. Its primary goal is to serve the object's content from cache and thus minimize the execution of remote messages, such as back-end database JDBC calls, or calls to access data at remote nondatabase servers.

Generally, Command Cache is used to cache dynamic data that requires back-end data retrieval or additional computation or manipulation later. Command Cache forms a good synergy with Servlet/JSP Result Cache because, in some cases, even caching the most granular, final formatted fragment is not sufficient. For example, a personalized page may contain a stock list fragment (Figure 5-6). This fragment consists of two sets of information: the stock list that is highly personalized, and the corresponding stock symbol pricing information that is generalized information and usable by many users. Suppose the stock list is the customer's stock portfolio, which is highly sensitive and is stored at the back-end server. In this case, it is not effective to cache the final formatted fragment. Since the stock quotes are highly volatile, this fragment will be regenerated repeatedly. The net is every time this fragment is reconstructed, it is necessary to retrieve the stock list from the source. A better approach is to use Command Cache to cache the stock list and avoid fetching the list continually from the back-end database.

Figure 5-6: A stock list fragment

Command Cache is caching at the Java application level. To use Command Cache, user applications need to be written to the WebSphere Command Framework API. WebSphere Command Framework is based on the Command Design Pattern widely used in Java programming paradigms. Typically, these applications use "setters" to set the command's input states, one or more "execute" methods, and "getters" to retrieve the results. The results can be either formatted or raw data.

Command Cache intercepts the "execute" method call of a command written for Command Cache and checks whether the command object can be served from the cache. If the command object does not exist in the cache, the logic in the "execute" method is performed and the resulting object is cached.

The caching behavior of Command Cache is defined declaratively with the XML cache policy file, which describes whether and how a command should be cached. Command Cache can be used at the presentation and/or business logic layer in multi-tier environments.

Command Cache is easy-to-use. For existing applications that follow a Model, View, and Control (MVC) design pattern, Command Cache can be implemented with minimal impact to existing code.

Replication support

Replication Support further extends the value of caching in an e-business application. With this support, caches can be shared (central cache) or replicated (local cache) among servers. Replication can be enabled and configured declaratively with XML cache policy files. Cache policy also defines the cache entries or groups that should be shared or replicated.

Replication Support uses a built-in high performance standard-based JMS messaging system as its underlying engine for data replication.

Figure 5-7 shows an example of three servers configured to have their local caches replicated with each other. The messaging broker can be the built-in JMS broker belonging to one of the three servers. In this case, the broker is the built-in JMS broker at server one. Request for data (1) hits server one (or any one of the three servers). If the requested data is not in the cache, the data is fetched from the back-end server (2). Resulting data from the back-end server (3) is cached at server one and then returned to requester (4). When the cache of server one detects the cache update request, it publishes a message (a) regarding the change to the messaging broker. Whatever change occurred at server one is automatically replicated to server two (b) and server three (c).

Figure 5-7: An example of cache replication

Invalidation support

The difference between caching static and dynamic content is the requirement for proactive and effective invalidation mechanisms, such as event-based invalidation, to ensure the freshness of content. The time-based invalidation alone is no longer adequate for dynamic cache invalidation.

WebSphere Application Server dynamic cache service provides rule-based, time-based, and group-based invalidation techniques. The WebSphere Application Server Enterprise Edition, Version 5 offers access to a programmatic cache and invalidation techniques. Invalidation policies can be defined with XML cache policy files. Invalidation policies allow triggering events to invalidate cache entries without the need to write explicit code. More complex invalidation scenarios may require code, which invokes the invalidation API.

The responsibility for synchronizing the dynamic cache of external caches and the WebSphere Application Server is shared by both systems. For example, a public Web page dynamically created and cached at the application server using Servlet/JSP Result Cache can be exported by Application Server and cached by the WebSphere Edge Server's Caching Proxy. Caching Proxy can then serve the application's execution results repeatedly to many different users until notified that the page is invalid. Content in the Caching Proxy's servlet response cache is valid until the proxy server removes an entry because the cache is congested, the default timeout set by the Caching Proxy's configuration file expires, or the Caching Proxy receives an Invalidate message directing it to purge the content from its cache. Invalidate messages originate at the WebSphere Application Server that owns the content and are propagated to each configured Caching Proxy.

Edge of Network Caching support

WebSphere Application Server dynamic cache service can control external caches.

External Cache

WebSphere Application Server dynamic cache service can use IBM HTTP Server's high-speed cache, referred to as the Fast Response Cache Accelerator (FRCA), as its external cache, to cache whole pages and fragments.

The Edge Components of WebSphere Application Server Network Deployment V5.0 can also be configured as WebSphere Application Server's external cache for whole page caching. In such case, the WebSphere Application Server dynamic cache service can be enabled to match pages with their universal resource identifiers (URIs) and export matching pages to the external cache (Figure 5-8). The contents can then be served from the external cache instead of the application server to significantly save resources and improve performance.

Figure 5-8: An example of exporting content to the external caches - WebSphere Edge Server

Figure 5-8 shows an example of exporting a dynamic cache page from the WebSphere Application Server to the cache component of WebSphere Edge Server. More information about caching dynamic content at the edge of the network can be found in a white paper titled WebSphere Edge Services Architecture Guide to Edge Applications of WebSphere Edge Server Library [11].

Distributed Fragment Caching and Assembly Support

WebSphere Application Server leverages the Edge Side Includes (ESI) [9] specification to enable caching and assembly of distributed fragments.

Edge Side Includes (ESI) [9] is a simple mark-up language used to define Web page fragments for dynamic assembly of a Web page at the edge of network. ESI is an open standard specification supported by Akamai [12] and leaders in the Application Server, Content Management Systems, and Content Delivery Networks markets.

With the Distributed Fragment Caching and Assembly Support, WebSphere Application Server customers can defer page assembly to any ESI compliant surrogate server, such as Akamai EdgeSuite service. This may result in significant performance advantage if fragments can be cached and reused at the surrogate.

WebSphere Application Server provides distributed fragment caching and assembly support through the WebSphere HTTP plug-in. WebSphere Application Server uses the WebSphere HTTP plug-in to communicate with the HTTP Server. This plug-in has the ability to cache whole pages or fragments. Additionally, it can dynamically assemble web pages containing ESI <esi:include> tags. Any server with WebSphere HTTP plug-in support can gain the benefits provided by the WebSphere Application Server dynamic cache service.

With WebSphere Application Server dynamic cache service's external cache control, distributed fragment caching and assembly support, dynamic content can be exported, cached, and assembled at the most optimal location, closer to the end user. More important, WebSphere Application Server can maintain control of the external cache through its Invalidation Support to ensure the freshness of cached content. As a result, WebSphere Application Server customers are equipped to create and serve highly dynamic Web pages without jeopardizing page performance and user experiences.

In the table below, you can see which caching technique and cache distribution technique are most useful for each type of Web content.

Table 5-1: Caching and cache distribution techniques

Type of Web content	Caching technique	Cache distribution technique
Published / static (*.html, *.gif, …)	WebSphere Edge Server Caching Proxy
Dynamic fragment/page (dynamically generated and reusable)	WebSphere Application Server Servlet/JSP Result Cache WebSphere Edge Server cache component and/or IBM HTTP Server as external cache WebSphere Application Server's HTTP plug-in distributed fragment caching and assembly support	WebSphere Application Server Servlet/JSP Result Cache configured with WebSphere Edge Server and/or IBM HTTP Server as external cache WebSphere Application Server's Cache Replication Support
Dynamic data (data object)	WebSphere Application Server Command Cache	WebSphere Application Server Cache Replication Support

---