AW: SOAP Response Caching

Hi,

I'm a student interested in Web services. Could you provide me with some
sources of information (good links) for somebody who doesn't know what
really is going on? Thanx for your help!

All the best
Robert

-----Ursprungliche Nachricht-----
Von: www-ws-request@w3.org [mailto:www-ws-request@w3.org]Im Auftrag von
Mark Nottingham
Gesendet: Thursday, September 06, 2001 10:07 AM
An: Mark Baker
Cc: www-ws@w3.org
Betreff: Re: SOAP Response Caching



On Wed, Sep 05, 2001 at 01:14:06AM -0400, Mark Baker wrote:
> 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.

It's for any request/response use of SOAP; not just HTTP, but over
TCP or any other underlying protocol you care to use. If you're using
SOAP in some fashion that can leverage a particular underlying
protocol's caching mechanisms to your satisfaction, a Module isn't
necessary; go forth and cache. However, the semantics as well as
real-world operational characteristics of many protocols - especially
HTTP - may make caching SOAP difficult if not impossible.
Additionally, some uses of SOAP will be across multiple bindings.
Hence, a Module.

My current view is that there are some good uses of HTTP caching in
SOAP; it involves making a GET request (perhaps with a query), and
getting a SOAP Envelope as a response payload. However, I'd model
this as a SOAP one-way Message Exchange pattern, because the HTTP
request isn't a SOAP request. It's still a Web Service, but it isn't
SOAP on the request side.

This allows simple services to take advantage of HTTP caching, while
more complex services that have more complex requests need to use
SOAP to express the request, rathern than traditional request URI
query arguments. This works nicely; HTTP caching is best for simple
cases.


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

And I maintain that the HTTP caching model isn't interesting to reuse
with SOAP, for most purposes. It was designed years ago as an
optimisation for hypertext browsing, based on distributed filesystem
caching, and its implementation is probably the most irregular thing
about HTTP.

SOAP's ability to target extensible blobs of XML at intermediaries
is a godsend for caching; when I first learned of it, it was
immediately clear that the best thing for caching and SOAP was for
them to be used together, with these mechanisms.

On a personal note, I've built a career out of being something of an
oracle for those (implementors, publishers and end users) lost in the
maze of HTTP caching. Whilst reusing HTTP caching mechanisms in SOAP
does give me a certain amount of job security, it also sentences me
to quite repetitive work. Please, make it stop!


> 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-).

I think you mean 'no-store', not 'no-cache'.

Practically speaking, that is the current state; SOAP's use of POST
in the HTTP binding means that no cache implementation I'm aware of
will store any SOAP response. According to RFC2616, POST is cacheable
with explicit directives (thogh I've seen that refered to as 'a
mistake' by Those in the Know), so the group may need to specify
Cache-Control on responses, just for completeness.


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

This is a matter that has been under discussion [1] since before REST
appeared on the horizon (at least from the WG's perspective).


[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0055.html

--
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Friday, 7 September 2001 00:17:35 UTC