Re: SOAP Response Caching

Hi Mark.

One important general comment.  After reading this, I get the impression
that it is for the use of SOAP that I like to call "tunnelling" (which
includes RPC), and doesn't attempt to cover the REST-friendly use of
SOAP.  I know you and I have been over the differences before, but
even if you're not yet convinced, hopefully you at least acknowledge
that SOAP can use its underlying protocol in different ways.  I think
you need to say this somewhere.

Here's my REST-centric comments to your proposal.

(for those not familiar with REST, see http://conveyor.com/RESTwiki)

> <p>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.</p>

SOAP bound to HTTP in a REST style would reuse the HTTP caching model.
If you wanted to suggest some extensions that would find themselves
into the SOAP header, that's ok, though unless they're SOAP-specific I'd
suggest doing it with HTTP headers.  Either way though, the Module itself
will require an extended SOAP/HTTP binding, since there's bound (pun not
intended) to be interactions - unless you want to suggest that the normative
SOAP/HTTP binding requires the use of "Cache-Control: no-cache" (please
don't 8-).

> <p>Response caching is implemented by three distinct caches; the Message
> Cache, the Service Expression Cache and the Message Expression Cache.</p>
> 
> <p>The <strong>Message Cache</strong> contains individual SOAP messages which
> have been cached, and is indexed by both the <strong>Service Key</strong>
> (which identifies the particular Web Service being accessed) and the
> <strong>Message Key</strong> (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.</p>

With REST, each resource provides a single "service", so this distinction
isn't required.

Later,

MB

Received on Wednesday, 5 September 2001 01:13:22 UTC