- From: Geoff Arnold <Geoff.Arnold@Sun.COM>
- Date: Tue, 08 Apr 2003 11:31:49 -0400
- To: www-ws-arch@w3.org
-1
Rearranging for convenience:
> "Though envelopes sent over application protocols differ in meaning
> depending upon which application protocol and method is used, the WSA
> prescribes that application protocols shall be treated as if they were
> transport protocols. This has the following advantages and
> disadvantages; [...]"
>
> Sound good?
No. First, "applications protocol" is not a well-defined set, and it is
used here in at least two inconsistent ways.
Second, I disagree with the major premise: envelopes sent over
different protocols do *not* necessarily "differ in *meaning* depending
on the way they are transported. ("Meaning" is a pretty loaded
term to use here, by the way.)
> If I send "hello" with HTTP PUT, I am requesting that the string
> be stored at the URI.
>
> If I send "hello" with HTTP POST, I am requesting that the processor
> identified by the URI to which I'm POSTing, process that string.
>
> Those HTTP messages have *exactly* the same body, yet they mean
> *very* different things.
Replace your "hello" with a well-formed SOAP message. Now what?
If all we want to do is use HTTP as a one-way message transport, we can
either
say "use HTTP POST to send the message, all other HTTP methods are
invalid", or we can say "HTTP PUT, POST,... are treated as equivalent".
I'd prefer the first - cleaner, more consistent. What we cannot say
is "if the SOAP message is transferred via HTTP PUT, the SOAP semantics
are X; if it is transferred by HTTP POST, the SOAP semantics are Y".
The SOAP specification defines the processing model - end of story.
One thing that is clear is that we confuse ourselves by using the
term "web services" to indiscriminately cover both simple HTTP
services and SOAP services. It's analogous to the way that some
sites provide parallel FTP and HTTP access to the same set of
resources.....
Received on Tuesday, 8 April 2003 11:33:10 UTC