Web service caching

The WebSphere Application Server Web service engine provides caching support, so that a Web service request can be cached and the cached response returned in place of subsequent processing; however, this caching support follows the all-or-nothing approach for both the request and the response.

In WebSphere Commerce, with operations represented by commands and the JSP composition service used to compose the result, the Dynacache features of cacheable commands and caching JSP fragments can also be used as a way to cache portions of the request and the response.

Caching a command invoked by a Web service is no different than caching a command invoked as a URL request. In fact, if the command has already been configured to be cached, then the Web service framework will take advantage of that. Similarly, the steps required for caching JSP pages or fragments for Web services are the same as for URL requests.

For JSP responses, consider the following example:

<ShowCatalog xmlns="http://www.openapplications.org/oagis/9" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.openapplications.org/oagis/9 ../../BODs/Developer/ShowCatalog.xsd" 
  languageCode="en-US" 
  versionID="normalizedString" 
  releaseID="normalizedString" 
  systemEnvironmentCode="Production">
  <jsp:include flush="true" page="ApplicationArea.jsp"/>
  <DataArea>
    <Show recordSetTotal="2" 
      recordSetStartNumber="2" 
      recordSetCompleteIndicator="false" 
      recordSetReferenceId="normalizedString" 
      recordSetCount="2">
      <UserArea/>
      </OriginalApplicationArea>
    </Show>
  <jsp:include flush="true" page="Show/Catalog.jsp"/>  </DataArea>
</ShowCatalog>

In this example, two separate JSP pages are included in the response: ApplicationArea.jsp, which can be reused in other Web service responses, and Show/Catalog.jsp.

Within Show/Catalog.jsp, there are three XML blocks, each represented as a JSP fragment:

<Catalog>
  <jsp:include flush="true" page="CatalogHeader.jsp"/>
  <jsp:include flush="true" page="ClassificationScheme.jsp"/>
  <jsp:include flush="true" page="CatalogLine.jsp"/>
</Catalog>

Either all, some, or none of the JSP fragments might be cacheable. However, for those fragments that are, the caching policy can be created to cache the content, so that the next time the JSP fragment is rendered, the cached version can be used. An example of such a policy is as follows:

<cache-entry>
  <class>servlet</class>
  <name>/webservices/OAGIS/9.0/Resources/Catalog/CatalogHeader.jsp</name>
  <name>/webservices/OAGIS/9.0/Resources/Catalog/CatalogLine.jsp</name>
  <name>/webservices/OAGIS/9.0/Resources/Catalog/ClassificationScheme.jsp</name>
  <property name="save-attributes">false</property>

  <cache-id>
    <component id="catalogId" type="parameter">
      <required>true</required>
    </component>
  </cache-id>
        
  <dependency-id>catalogId
    <component id="catalogId" type="parameter">
      <required>true</required>
    </component>
   </dependency-id>
</cache-entry>

Within this policy definition, all three fragments are cacheable based on the catalogId parameter found in the request. This catalogId will be either contained in the original service request or returned by the command executed as a result of the service request.

In the preceding example, the first time the response of the service with catalogId of 123 is executed, each JSP will be executed as well.However, the three fragments will also be cached at the same time, so the next time another request is made that includes the same JSP fragments for catalogId of 123, the cached versions of the JSP fragments will be returned.

Related concepts
WebSphere Commerce Web services with JSP pages
Understanding the WebSphere Commerce Web service framework
Dynamic caching

Related reference
JSP programming best practice: Use an appropriate inclusion mechanism
JSP programming best practice: Use the .jspf extension for JSP segments