WWW caching services
There are two basic types of content from the caching point of view:
- Static content
Static content does not change over long periods of time. The content type can be HTML, JSP rendering less dynamic data, GIF, JPG, etc.
Note that JSP rendering less dynamic data is considered to be static content from the caching point of view. When JSP is rendered, static HTML code is generated and this is cached.
- Dynamic content
Dynamic content includes frequently updated content (such as exchange rates), as well as personalized and customized content. Although it is changing content, at the same time it must be stable over a long enough time for meaningful reuse to occur. However, if some content is very frequently accessed, such as requests for pricing information of a popular stock, then even a short time of stability may be long enough to benefit from caching.
It is important to understand that caching goes beyond an applications' own infrastructure. For example, there are many cache instances currently deployed on the Internet. Figure 14-1 outlines the different tiers of caching for Web applications.
The content caching tiers are:
- Client caching services
These services can be provided by any kind of Web browsers. Web browsers can store received content locally on the client device. Unfortunately, very often you will experience that interpretations of HTTP cache directives are browser dependent.
- Internet content delivery services
These services provide the replication and caching infrastructure on the Internet. The infrastructure is based on standard concepts, protocols and taxonomy. The main actors are Internet Services Providers (ISP) and Content Delivery Network (CDN) service providers, such as Akamai, or Speedera.
The physical infrastructure is built using cache appliances such as Network Appliance, Blue Coat, Cisco Cache Engine, or InfoLibria DynaCache.
These services can also support the dynamic composition of page fragments in the network using a standard called Edge Side Include (www.esi.org). WebSphere external caching scenarios explains how WAS V5.1 supports ESI.
- External caching services
These services provide front-end caching of both static and dynamic pages. The technical component can be the Caching Proxy, part of WebSphere Edge Components, IBM HTTP Server, or the Web server plug-in. All of them can intercept requests from a client, retrieve the requested information from content-hosting machines, and deliver that information back to the client. In addition, they can store cacheable content in a local cache (memory and/or disk) before delivering it to the requestor. This enables the external caches to satisfy subsequent requests for the same content by delivering it directly from the local cache, which is much quicker than retrieving it again from the content host.
These services provide both whole page and fragment caching; and again the dynamic composition of page fragments is based on ESI.
We further discuss external caching services in WebSphere external caching scenarios.
- Dynamic caching services
These services provide the caching of servlets, JSPs, commands, Web services, or EJBs. They work within an appservers' JVM by intercepting calls to cacheable objects.
WebSphere dynamic caching scenarios focuses on these dynamic caching services.
This chapter is focused on the dynamic caching services and their integration with external cache services.
In most cases only a combination of dynamic and external services can power high volume Web sites to achieve the required level of scalability and performance. When implementing such a combination, the impact on data integrity and accuracy needs to be also considered. For example, if you have a WebSphere Commerce implementation and you use the WebSphere Edge Components to cache product pages, it can take some time until the WebSphere Edge Components cache is synchronized with updates to the product database used by WebSphere Commerce. This time can be as long as the time-to-live parameter set for the product pages.
The question to be asked is, how can you make sure that all these different caching services will support your specific application? The answer to this question is to use standard protocols, such as HTTP/1.1 and ESI/1.0.
Traditional HTTP caching is mostly used in cases where the whole page is cacheable and does not contain personalized content. On the other hand, ESI allows caching to operate on the level of fragments rather than whole pages.
HTTP/1.1 provides basic cache mechanisms in the form of implicit directives to caches. It also allows the use of explicit directives for the HTTP cache called "Cache - Control". The Cache-Control header allows a client or server to transmit a variety of directives in either requests or responses. These directives typically override the default caching algorithms.
Detailed information on the HTTP/1.1 caching directives are included in RFC 2616 (http://www.faqs.org). Additionally, RFC 3143 lists known HTTP Proxy Caching problems.
Note An additional level of caching, which is not described in this chapter, is database caching. There are a number of products available for database caching, for example DB2 DBCache, TimesTen, Oracle 9i IAS - Relational Cache, Versant's enJin.
For more information on database caching, refer to this Web site:
http://www.almaden.ibm.com/u/mohan/Here you find a link to the presentation "Caching Technologies for Web Applications".
Prev | Home | Next WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
