Develop > Presentation layer > WebSphere Commerce integration with WebSphere Portal
WebSphere Commerce Portal caching
Cache is a technique that when applied properly can improve the overall system response time. It can therefore accelerate the machine to its maximum appropriate utilization while keeping the hardware costs low. That is, caching allows you to do repeatable computer tasks more rapidly.
JSP caching for portlets
Portlets are Java-based Web components that process requests and generate dynamic content. This portlet generated content is called a fragment, which is a piece of markup, such as HTML or WML, adhering to certain rules. The fragment can be aggregated with other fragments to form a complete document, called a portal page. Because the JSR 168 specification does not define any caching API for portlets, each vendor needs to provide its own to satisfy the need of portlet caching.
WebSphere Portal provides an easy to use caching technique called Portlet Caching. This caching technique is built around the DynaCache technology in WAS and allows portlet developers and administrators to configure the cache scope and the cache expiry time of the specified content. The cache scope and cache expiry time are configured by page, portlet, and theme. WebSphere Portal then combines this information to produce a final cache scope and expiry time for each page it serves. In general, whenever any portlet content that requires the usage of any session information can trigger the entire portal page to be scoped to just that current session. That is, any fragment of a portal page which requires access to a session can cause WebSphere Portal to reduce the cache scope of that entire page to only that user’s session.
This cache behavior may not be ideal for a high traffic dynamic content Web site, such as a WebSphere Commerce portal site, where further tuning is needed for some portlet content. Instead of having just a single portlet time-based invalidation scheme, it is necessary at times to have the ability to individually tune each cacheable content, where some business operational parameters, such as the WebSphere Commerce store ID or catalog ID, can be included as part of the caching scheme.
JSP Caching for Portlets is a caching technique that allows any WebSphere Commerce JSR 168 portlets to be configured to directly work with the WAS DynaCache service. Portlet developers, therefore, are no longer restricted to a single time-based expiration cache policy. With JSP Caching, portlet developers can perform any caching technique that DynaCache supports, such as defining the own custom cache identifier and invalidation scheme.
The main objective of using JSP Caching with portlets is to allow the use of the DynaCache configuration (cachespec.xml) within portlets, while maintaining a minimal impact to the existing portlet programming model.
To achieve this technical objective, a JSTL tag library is introduced to emulate the existing portlet action URL and render URL tags, known as the Cache tags. These portlet JSP Cache tags generate JavaScript code that retrieve the newly generated portlet URL from the Dynamic Content Provider upon each cache hit.
The following list provides the main components in the JSP Caching model:
Dynamic Content Provider
A Dynamic Content Provider (DCP) is a runtime user exit program that can be added to any cacheable content, such as a portlet JSP. A DCP can contain additional processing logic to modify cached content upon a cache hit. When DynaCache renders the content upon a cache hit and identifies this associated DCP, the callback method of this DCP, provideDynamicContent(), is called. Additional dynamic content can be generated and merged with the final HTML output. See Use the DynamicContentProvider interface for dynamic cache for more information.
JavaScript
By using the Dynamic Content Provider upon cache hits, new portlet URLs can be generated as a text string which is then wrapped around by JavaScript code so that previously defined portlet URLs can be dynamically substituted when loaded by the user’s web browser. Portlet URLs generated by WebSphere Portal can only be used once. Therefore, it is necessary to regenerate any embedded portlet URL within the cached content upon each cache hit.
cachespec.xml
A DynaCache configuration file, cachespec.xml, is required inside the portlet web application to specify the cache setting for the portlets. Only one cache configuration file is necessary for all portlet JSPs within the same portlet application.
Tag libraries
A JSTL tag library provides a set of portlet APIs that can be used directly on JSPs for emulating the existing <portlet:actionURL> and <portlet:renderURL> tags. These tags are known as Cache tags. Instead of placing another encoded portlet URL in its place, the new JSP Cache portlet tags generates JavaScript code which retrieves another portlet URL generated by the Dynamic Content Provider.
Depending on which method is used for accessing the portlet URL, whether the portlet request is issued as a GET or a POST, a slightly different usage pattern is required.
- Enable the portlet URL JSP Cache using the GET method
Out of the two GET and POST methods, portlet URL caching using the GET method is simpler and can almost mimic the <portlet:actionURL> and <portlet:renderURL> tags. The enablement should be performed in the original portlet JSP file.
- Enable the portlet URL JSP Cache using the POST method
Portlet URL caching using the POST method requires an additional event handler tag to be added to the onSubmit event of an HTML form. The enablement should be performed in the original portlet JSP file.
- Enable existing JSR 168 portlet JSP files for JSP caching
To illustrate the usage of the cache tag on a JSP file, a WebSphere Commerce portlet JSP file is used as an example to demonstrate how you can replace WebSphere Portal's Portlet Caching configuration with this JSP file Caching.