Webservice response caching in websphere

This cache holds the result of Web services SOAP invocations. Web services SOAP calls can be expensive, primarily due to the extensive parsing of XML files that must happen on both ends. Cache identifiers can be built from both HTTP headers and the SOAP envelope; in fact the entire SOAP envelope could be hashed and used as a cache ID.

A Tutorial here:
http://wasdynacache.blogspot.in/2010/02/caching-webservices-responses-in.html

Sample cachespec.xml in the case of a webservice caching,

<cache>
   <cache-entry>
      <class>webservice</class>
      <name>/soap/servlet/soaprouter</name>
      <cache-id>
         <component id="" type=SOAPAction>
            <value>urn:stockquote-lookup</value>
         </component>
         <component id="Hash" type="SOAPEnvelope"/>
         <timeout>600</timeout>
         <priority>1<priority>
      </cache-id>
      <cache-id>
         <component id="" type="serviceOperation">
            <value>urn:stockquote:getQuote</value>
         </component>
         <component id="Hash" type="SOAPEnvelope"/>
         <timeout>600</timeout>
         <priority>1</priority>
      </cache-id>
   </cache-entry>
</cache>

Above sample shows a simple cachespec.xml file with a single cache entry for a Web service call.

The class designation is obvious, and the name is the URI path to the soaprouter servlet, familiar to those who work with Web services. There are two cache IDs configured for this entry. The first is a combination of a stock quote lookup request and the SOAP envelope, and the second is a combination of a getQuote service operation and a hash of the SOAP envelope. With two cache IDs, the caching engine will parse from the top down and use the first one that fits the particular entry that it is working with at run time for either inserting a new entry into cache or returning a cache entry for a request.
Now let us look at a more complex example of a cachespec.xml file below.

<cache>
   <cache-entry>
 <class>servlet</class>
 <name>/ProductControllerServlet</name>
      <cache-id>
         <component id="action" type="parameter">
     <value>view</value>
            <required>true</required>
         </component>
         <component id="productID" type="parameter">
            <required>true</required>
         </component>
         <priority>3</priority>
         <timeout>20</timeout>
      </cache-id>
      <cache-id>
         <component id="action" type="parameter">
     <value>view</value>
            <required>true</required>
         </component>
         <component id="category" type="parameter">
            <required>true</required>
         </component>
         <priority>3</priority>
         <timeout>20</timeout>
      </cache-id>
      <dependency-id>category
         <component id="category" type="parameter">
            <required>true</required>
         </component>
      </dependency-id>
      <invalidation>category
         <component id="action" type="parameter" ignore-value="true">
     <value>update</value>
     <required>true</required>
  </component>
  <component id="category" type="parameter">
     <required>true</required>
         </component>
       </invalidation>
   </cache-entry>
</cache>

The above xml defines a single cache entry for a controller servlet, such as you might find in a MVC-type application.
From the top down, you see:
A cache ID for when the product controller servlet is run with a parameter named "action" with a value of "view", using the product ID. This probably indicates a view for a single product's information. Notice that not only is the parameter name of "action" provided as part of the cache ID, but a required value of "view" for that parameter is provided as well.
A cache ID for when the product controller servlet is run with parameter "action" with value "view" and a category parameter is provided. This would be an example of when a page of products in a certain category are requested.
A dependency ID named "category" and using the parameter name "category" and its value as the cache ID. This and other cache entries can have the same dependency ID and will be invalidated as a group if certain events occur (such as an invalidation rule firing).
An invalidation rule named "category", which causes it to be linked to the category dependency ID. It requires that the "action" parameter of this servlet have the value "update". Based on the linkage, when the servlet is run in update mode for this category, all cache entries for both the individual product view and the list for that category will be invalidated.