RE: D-AR003.1

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Thursday, May 30, 2002 1:39 PM
> To: www-ws-arch@w3.org
> Subject: D-AR003.1
> 
> 
>
> I brought this up becase, as I say there, most Web services people
> incorrectly call HTTP, SMTP, and other application protocols 
> "transport protocols". ...
> 
> From my POV, we need to be clear that application protocols cannot be
> separated out from Web services; that if a Web service uses an
> application protocol, that it should be using the semantics of that
> protocol.


BTW, we're discussing: "D-AR003.1 [The web services architecture must
separate] the transport of data or means of access to Web Services from the
Web Services themselves."  Sorry if you get a sense of deja vu from this
post, but I'm not sure how much of the previous discussion has been in
public ...

I think this is an important requirement -- my favorite use case
illustrating this is integrating legacy procedural software over HTTP and
various other transp ... ooops, sorry "transfer" ... protocols in multiple
hops through an enterprise or cross-enterprise infrastructure. Having a
common SOAP-based application protocol layer and abstracting away the
mechanisms of moving bits around is a Good Thing in that scenario, as far as
I can see. The alternative of having each intermediary do both a "bits on
the wire" protocol conversion AND a web services application protocol
conversion (e.g. RPC to REST to MQSeries to RPC) seems lot an awful lot of
pain for no gain.  Indeed, I can't think of what advantages a web services
architecture that insisted that the semantics of the web service be tied to
the semantics of the underlying protocol would offer in my use case, whereas
I *can* see advantages of having a single end-to-end SOAP-based application
protocol and have the intermediaries simply do the transfer/transport-level
protocol conversion.

So, you're not going to convince me to change my vote until you explain the
*practical* issues that people will face by separating the transport of data
from the web services themselves.  Ex cathedra argumentation ("incorrectly
call HTTP a transport protocol" ... "application protocols cannot be
separated from web services") is simply not compelling for this audience.

Also, since the trend in SOAP from 1.0 through 1.1 to 1.2 is to further
abstract SOAP from the underlying transfer/transport protocol(s), you're
laying down in an icy road at the bottom of a hill in the dark, IMHO  :~)

Received on Thursday, 30 May 2002 14:08:39 UTC