SOAP and transfer/transport protocols

On Mon, May 27, 2002 at 03:15:14PM -0700, David Orchard wrote:
> <snip/>
> 
> > I agree that we want to extend the Web to do things like reliability,
> > transactions, conversations, etc..  I just think that what most people
> > are using SOAP for, is not that.  It's changing the way the Web works
> > (putting the method name in the POST body, rather than using HTTP's
> > methods), and then building the extensions on top of that
> > changed thing.
> > SOAP actually has a use, that I worked hard on in the XMLP WG, that
> > allows it to be used in this manner.
> >
> 
> I think there might be a requirement and usage scenario that the SOAP/POST
> binding meets that you don't agree with.  My take at expressing these are:
> 
> Ease of multiple protocol deployment requirement: It shall be possible to
> use a variety of protocols under SOAP to send/receive SOAP messages, without
> the application developer having to know method specific details about the
> protocol underlying SOAP.

I can understand why you'd want to do this with transport protocols
(to an extent), but not with application/transfer protocols.  Can you
explain why this is required or even desirable?

As I see it, there are two ways in which SOAP can be used in a protocol-
independant fashion.

One way, when using application protocols, is to treat them all as
transport protocols; a way of moving bits from A to B with some QoS.
This way, they all look the same, modulo the QoS that they offer.

The other way is to respect the application semantics of these
protocols by not putting your own application semantics (methods) in
the message, allowing the semantics of each hop in the route to be
dictated by the protocol in use on that hop.

An example of the former in pseudo-SOAP would be;

<add>
  <vcard>
    <fn>Mark Baker</fn>
    ...
  </vcard>
</add>

or

<replace>
  <vcard>
    <fn>Mark Baker</fn>
    ...
  </vcard>
</replace>

An example of the latter would be;

<vcard>
  <fn>Mark Baker</fn>
  ...
</vcard>

Also, the latter approach is the only one that can do what Roy talked
about, that I quoted earlier;

"The difference between an application-level
protocol and a transport-level protocol is that an application-level
includes application semantics, by standard agreement, within
the messages that the protocol transfers.  That is why HTTP is called
a Transfer protocol.  It is impossible to conform to an
application-level protocol without also conforming faithfully to
its message semantics."
 -- http://lists.w3.org/Archives/Public/www-tag/2002Apr/0303.html

>  Usage Scenario: An application developer creates
> a web service and expose it via HTTP, JMS, and SMTP.  The application
> developer performs minimal work when deploying the web service on each
> different protocol.  The application developer chooses the underlying
> protocol(s) based upon features expressed in the protocols, such as JMS'
> reliable messaging features.

JMS is a layer 6 protocol without application semantics, so I have no
issue with abstracting it.  But HTTP and SMTP are layer 7 protocols
with application semantics.

> By using just POST, this requirement/scenario is met.

Only if you buy into the former scenario, which I don't.

> FWIW, this is the way I would like to have discussions.  What requirements
> and usage scenarios are met/not met with particular architecture decisions.

Agreed.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Monday, 27 May 2002 21:34:31 UTC