Re: D-AR003.1

On Thu, May 30, 2002 at 12:07:20PM -0600, Champion, Mike wrote:
> 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.

Ok.

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

Hmm.  HTTP does not "move bits around", TCP does.  You're implicitly
calling HTTP a transport protocol by saying that, so I'm not surprised
by your conclusion.

Is this point really so hard to understand?  An application protocol
defines an application layer contract on-the-wire.  If I telnet to
port 80, I know what API is presented to me; that I can do "GET /
HTTP/1.1".  If I telnet to a random port, or if I'm using SOAP-RPC
over HTTP and telnet to port 80, I don't know what API is available to
me.  The application protocol defines the "API".

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

No gain?  How about working over firewalls, not having to coordinate API
changes, etc..

As I said before, developing Internet based apps is qualitatively
different than developing Intranet based apps, because on an Intranet,
there are no trust boundaries to worry about.  "Relocating" the service
in front of the firewall, and adding some angle brackets to its IDL,
does not address the trust boundary issue.

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

See above.

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

Practically, it won't work unless there's a strong trusted relationship
between the parties.  And even then, coordination costs (of rolling out
interface changes) will be much higher than if the interface never
changes, like those of pre-specified, and long-deployed, application
protocols.

> 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  :~) 

It is good that SOAP is transfer protocol neutral.  It is bad that a
Web service attempt to be.

You've been following the GET work in XMLP.  The trend with GETF is
clearly to not treat SOAP as a layer, but to instead treat it as a peer
to its bound protocol.  The consequence of this work is that it will be
more difficult to write a SOAP/HTTP app without knowing you're doing
HTTP.  This is what I've been saying since XMLP started.

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

Received on Thursday, 30 May 2002 15:51:04 UTC