WebSphere APIs for Edge Side Includes

A set of Java APIs and JSP custom tags for accelerating Web application delivery through distributed fragment caching and assembly.

Date Posted: May 19, 2003

Overview

Requirements


	1.How does ESI relate to traditional HTTP caching?

	2.What is a fragment and why would I want to cache one?

	3.What is a surrogate?

	4.What content cannot be cached?

	5.How can a new application be best designed to take advantage of fragment caching and assembly? What about an existing application?

	6.What ESI functionality does WESI support?

	7.How does WESI differ from Dynacache with Edge Side Include Caching?

	8.When would I want to use Dynacache with Edge Side Include Caching instead of WESI?

	9.What kinds of configurations does WESI support?

	10.Where can I find more information?

1. How does ESI relate to traditional HTTP caching?

Traditional HTTP caching is only useful in cases where the whole page is cacheable and does not contain personalized content. ESI allows caching to operate on the level of fragments rather than whole pages.


	Back to top

2. What is a fragment and why would I want to cache one?

A fragment is a part or all of a rendered HTML page. Although a whole page may not be "cacheable," it may contain sections of varying cacheability that can be separated into fragments and cached independently. Any content that can be independently requested can make up a fragment. This means that a fragment cannot depend on any information placed in its request scope by its parent or other fragments.


	Back to top

3. What is a surrogate?

A surrogate (also sometimes called a reverse proxy) handles requests on behalf of an origin server. Clients contact the surrogate directly and the surrogate routes those requests to the origin as needed or serves responses from its own internal cache. The surrogate may also be responsible for assembling whole pages from page fragments. Examples of surrogates include Akamai's EdgeSuite and ETS and IBM's HTTP Server with WebSphere plug-in. Please see "What kinds of configurations does WESI support?" (below) for more information.


	Back to top

4. What content cannot be cached?

Content that is highly personalized (and cannot be further broken up into more common fragments), rarely accessed, or has a short lifetime can be cached, but will be of little benefit. WESI can cache content only on the basis of a full URL. If the content depends on anything other than the full URL -- session ID, cookies, etc., caching on the basis of the full URL will result in the incorrect content being served. In this case, Dynacache must be used instead. See "When would I want to use Dynacache instead of WESI?" (below) for more information.


	Back to top

5. How can a new application be best designed to take advantage of fragment caching and assembly? What about an existing application?

For this and other similar information, please see our Developerworks article (to be published soon).


	Back to top

6. What ESI functionality does WESI support?

WESI supports fragment inclusion, cache control, and fragment invalidation through the use of JSP custom tags (for JSPs) or a Java API (for servlets).


	Back to top

7. How does WESI differ from Dynacache with Edge Side Include Caching?

WESI supports page inclusion, cache control, and invalidation within the J2EE programming model through the use of explicit mark-up of content with JSP custom tags and Java APIs. Dynacache with Edge Side Include Caching, on the other hand, depends on the use of its cachespec.xml configuration file for information regarding cache control and invalidation. The content itself is not modified.


	Back to top

8. When would I want to use Dynacache with Edge Side Include Caching instead of WESI?

WESI does not implement some advanced functionality. If you find yourself needing this functionality, you should switch to Dynacache. WESI caches content on the basis of the full URL only. If you need to cache content on the basis of a partial URL or on the basis of cookies or session information, you will need to use Dynacache. While WESI allows you to specify custom dependency IDs for invalidation, it does not provide any mechanism for generating complex dependency IDs. Dynacache provides more support for complex dependency ID generation.


	Back to top

9. What kinds of configurations does WESI support?

WESI requires WebSphere Application Server 5.0.1 at the origin. It supports three different operating modes depending on the type of surrogate present.

Operating Mode 1: The surrogate is ESI/1.0-compliant. This includes Akamai's ETS and EdgeSuite.
Operating Mode 2: The surrogate is a Web server with the WebSphere plug-in.
Operating Mode 3: There is no surrogate present. WESI will perform in-place assembly of fragments with no caching. This mode is primarily intended for testing and debugging.