RE: Protocol independence

Relocated to www-ws.  Let's keep it here until we have something
to report back.

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

I disagree.  It's trivial (and deterministic! 8-), to look at a
protocol and determine whether or not it is an application
protocol, if that's what you meant.

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

Not necessarily, no.  If you had two application protocol methods
that were identically defined, then sending SOAP envelopes over
those would mean the same thing.  I don't know of any (though some
are similar, like HTTP GET and FTP RETR, or NFS WRITE and HTTP PUT),
but they may exist.

And by "meaning", I just mean the intent of the message, and what
is understood between sender and recipient, about what this message
is requesting be done.  So "GET some-uri" has meaning "get me a
representation of the resource identified by 'some-uri'", for
example.

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

Well, if that envelope only includes the serialized state of some
object (i.e. a document), then there's no problem, as it's no
different than my "hello" example; the meaning of the messages
varies.  e.g. POSTing a SOAP-encapsulated vCard means something
different than PUTting a SOAP-encapsulated vCard.

It sound like you agree with me though, that message semantics
normally vary when different application protocol methods are
used.

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

We *can* definitely say that, or at least say that SOAP can also be
used in this way.  In the XML Protocol WG, we used the word
"chameleon" to refer to this use.  Also, the SOAP 1.2 HTTP binding
explcitly supports this use of SOAP too, as faults are transferred
over HTTP error codes, rather than HTTP success codes (as they are
in SOAP 1.1, but not 1.0 or 0.9 or XML-RPC).

The SOAP processing model definitely does *not* preclude varying
message semantics based on the protocol or method in use.  Had
anybody suggested it did during the development of SOAP 1.2 while
I was on the WG, I would have objected strenously.  But nobody did.

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

At least we agree on that. 8-)

MB

Received on Tuesday, 8 April 2003 14:27:23 UTC