+

Search Tips   |   Advanced Search

Example: Caching web services

We can build a set of cache policies and SOAP messages for a web services application.

The following is a example of building a set of cache policies for a simple web services application. The application in this example stores stock quotes and has operations to read, update the price of, and buy a given stock symbol.

Following are two SOAP message examples that the application can receive, with accompanying HTTP Request headers.

The first message sample contains a SOAP message for a GetQuote operation, requesting a quote for IBM . This is a read-only operation that gets its data from the back end, and is a good candidate for caching. In this example the SOAP message is cached and a timeout is placed on its entries to guarantee the quotes it returns are current.

Message example 1

The SOAPAction HTTP header in the request is defined in the SOAP specification and is used by HTTP proxy servers to dispatch requests to particular HTTP servers. WebSphere Application Server dynamic cache can use this header in its cache policies to build IDs without having to parse the SOAP message.

Message example 2 illustrates a SOAP message for a BuyQuote operation. While message 1 is cacheable, this message is not, because it updates the back end database.

Message example 2

The following graphic illustrates how to invoke methods with the SOAP messages. In web services terms, especially Web Services Description Language (WSDL), a service is a collection of operations such as getQuote and buyStock. A body element namespace (urn:stockquote in the example) defines a service, and the name of the first body element indicates the operation.

The following is an example of WSDL for the getQuote operation:

To build a set of cache policies for a web services application, configure WAS dynamic cache to recognize cacheable service operation of the operation.

WAS inspects the HTTP request to determine whether or not an incoming message can be cached based on the cache policies defined for an application. In this example, buyStock and stock-update are not cached, but stockquote-lookup is cached. In the cachespec.xml file for this web application, the cache policies need defining for these services so that the dynamic cache can handle both SOAPAction and service operation.

WAS uses the operation and the message body in web services cache IDs, each of which has a component associated with them. Therefore, each web services <cache-id> rule contains only two components. The first is for the operation. Because we can perform the stockquote-lookup operation by either using a SOAPAction header or a service operation in the body, define two different <cache-id> elements, one for each method. The second component is of type "body", and defines how WAS should incorporate the message body into the cache ID. Use a hash of the body, although it is legal to use the literal incoming message in the ID.

The incoming HTTP request is analyzed by WAS to determine which of the <cache-id> rules match. Then, the rules are applied to form cache or invalidation IDs.

The following is sample code of a cachespec.xml file defining SOAPAction and servicesOperation rules:

  • Task overview: Using the dynamic cache service to improve performance