Web Service deployments often require more scalability, availability and performance than a single server can provide. This specification defines a means of caching SOAP [SOAP] response messages by clients and intermediaries, through use of a SOAP Module.
The Response Caching module enables caching of entire response messages in request/response message exchange patterns, including attachments if present, over any SOAP transport binding. Its cache is indexed based upon aspects of request messages which are selected by blocks inserted into response messages. This Module does not enable granular caching of the response; such a facility can be provided either by extensions to it, or by separate Modules.
This document is a draft circulated for comment only; it has not been implemented. Discussion should be directed to the author and/or the www-ws@w3.org mailing list.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [KEYWORDS].
Response Caching is directed by a response Header block; unlike HTTP caching (where the client can send Cache-Control directives), the server has exclusive control over cache coherence. Additionally, coherence is explicit; whilst the HTTP allows a heuristic to be used to determine freshness, Response Cache implementations MUST NOT cache responses which do not contain explicit coherence information. Although this version of the specification only includes one cache coherence mechanism (and no means of validation or invalidation), it is anticipated that these mechanisms will be defined by future revisions and/or extensions.
Response caching is implemented by three distinct caches; the Message Cache, the Service Expression Cache and the Message Expression Cache.
The Message Cache contains individual SOAP messages which have been cached, and is indexed by both the Service Key (which identifies the particular Web Service being accessed) and the Message Key (which contains to the combination of request charateristics that determine whether the cached response can be used). This dual-key approach accommodates the common practice of exposing multiple Web Services through a single Service URI.
The Service Expression Cache contains the XPath expression which is used to determine the Service Key for a particular Service URI, and is indexed by the Service URI.
The Message Expression Cache contains the XPath expressions which are used to determine the Message Key for a particular Service Key, and is indexed by the Service Key.
This design allows for one Service Expression for each particular Service URI, and one Message Expression for each Service Key. If the cache encounters a Service or Message Expression which is different from that in the appropriate Expression Cache, all Message Cache entries which are indexed by that Expression MUST be evicted from the cache.
The XML namespace [XML-NS] URI that MUST be used by implementations of this specification is:
http://intermediaries.org/SOAP-OPT/2001/08/23
The namespace prefix "SOAP-OPT" used in this specification is associated with this URI.
This module defines one block, 'ResponseCache', that may be inserted into response message Envelopes. Its schema [XMLSchema] is:
<schema
xmlns="http://www.w3.org/1999/XMLSchema"
xmlns:SOAP-OPT="http://intermediaries.org/SOAP-OPT/2001/08/23"
targetNamespace="http://intermediaries.org/SOAP-OPT/2001/08/23"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>
<import namespace="http://schemas.xmlsoap.org/soap/envelope/" />
<element name='ResponseCache'>
<complexType>
<sequence>
<element name='SOAP-OPT:serviceKey'
type='xsd:string' minOccurs='0' />
<element name='SOAP-OPT:messageKey'
type='xsd:string' minOccurs='1'
maxOccurs='unbounded' />
<element name='SOAP-OPT:coherence'>
<complexType>
<element name='SOAP-OPT:delta-freshness'
type='xsd:positiveInteger' />
</complexType>
</element>
</sequence>
<attribute ref='SOAP-ENV:actor' use='optional' />
<attribute ref='SOAP-ENV:mustUnderstand' use='optional' />
<attribute name='id' type='ID' use='optional' />
</complexType>
</element>
</schema>
The following additional constraints are placed upon particular values;
<ResponseCache
xmlns="http://intermediaries.org/SOAP-OPT/2001/08/23"
soap:actor="foo">
<serviceKey>concat(namespace-uri(/*/*[local-name()='Body']/*),
local-name(/*/*[local-name()='Body']/*))</serviceKey>
<messageKey>//symbol/text()</messageKey>
<messageKey>//symbol/@exchange</messageKey>
<coherence>
<delta-freshness>300</delta-freshness>
</coherence>
</ResponseCache>
Here, the Service Key is the namespace and local name of the first child of the Body (as would be used for RPC messages), and the message key is the content of the 'symbol' element, along with the content of the 'exchange' attribute on the 'symbol' element. Messages cached as a result will be considered fresh for 300 seconds.
Upon receiving a response message which contains a Response Caching block, implementations MUST:
If a cached response is used, the SOAP node which implements the cache MUST process any remaining blocks in the message before returning the response, as determined by the SOAP processing model (i.e., blocks before the caching block in the message's processing order will be processed prior to caching; those afterwards will be processed subseqently, each time the cached message is used).
Upon receiving any request message, implementations MUST:
The children of the 'coherence' element information item are used to control cache coherence. Currently, only one possible child is defined;
Note that this mechanism is not precise; transfer delay and intermediaries (either SOAP or on other layers) may add latency, causing cached entries to be considered fresh for arbitrarily longer periods of time. Additional coherence mechanisms may be defined in the future.
By default, implementations SHOULD regenerate the ResponseCache block in responses, to allow operation of downstream caches.
No Faults are specified; if a failure occurs, implementations SHOULD operate as if the cache were not present; i.e., forward the request message.
To ensure correct operation, implementations which generate ResponseCache blocks SHOULD check included XPath expressions for correctness.
This specification defines a mechanism that allows SOAP intermediaries and SOAP clients to response authoritiatively to requests, by using cached responses. Although this does not introduce any new vulnerabilities to SOAP, applications which use it should understand the security implications of explicitly allowing caching, especially if authentication, authorization or encryption is applied through another Module.
W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000.
Currently, most SOAP applications use the RPC convention. To enable Response Caching for these applications, the following Service Key is suggested:
concat(namespace-uri(/*/*[local-name()='Body']/*),
local-name(/*/*[local-name()='Body']/*))
This assigns the service key to the first child of the SOAP Envelope's 'Body' element, including both its namespace-uri and local-name. When the RPC convention is in use, this element is the root of the serialization graph of the request (i.e., the method of the RPC request).
revision: 2001/08/23