RE: SOAP and transfer/transport protocols

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Monday, May 27, 2002 9:30 PM
> To: David Orchard
> Cc: www-ws-arch@w3.org
> Subject: SOAP and transfer/transport protocols
> 
>
> > What requirements
> > and usage scenarios are met/not met with particular 
> > architecture decisions.
>
> Agreed.

OK, what requirements and usage scenarios are not met when SOAP
is treated as the application protocol, and HTTP is a transport
protocol rather than an application protocol?   Since this is
well-trodden territory, let's avoid references to Dr. Fielding's
work and argumentation of the "it should be a requirement
not to tunnel HTTP", or "we should not accept use cases that are
inconsistent with the Web Architecture" variety.  What *tangible*
use cases cannot be achieved if the Web Services Architecture allows
SOAP to be tunnelled over HTTP POST?  (I'm assuming that there will be
a GET binding so that those who have a requirement to hyperlink to 
"safe" services can do so).

Consider a situation where a web services application uses HTTP to
reach an intermediary, which uses SMTP to reach another intermediary, 
which uses MQ Series to reach an application.  What 
practical advantage for developers or users is achieved by 
"allowing the semantics of each hop in the route to be
dictated by the protocol in use on that hop?"  What is the
disadvantage in this scenario of treating SOAP as the application
protocol and SMTP, HTTP, and some hypothetical, proprietary MQ Series
binding as details of how bits are moved around?

Received on Monday, 27 May 2002 22:58:42 UTC