RE: SOAP and transfer/transport protocols

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Tuesday, May 28, 2002 10:34 AM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: SOAP and transfer/transport protocols
> 
> 
> IMO, "one jump" would be replacing all that software wholesale with
> HTTP routers.  I think a good intermediary step is to use HTTP for
> over-the-Internet integration, DCOM/CORBA/MQ/etc.. for within the
> firewall, and then to bridge them at the firewall.

Right, so we're back to the question of "allowing the semantics of each hop
in the route to be dictated by the protocol in use on that hop."   You seem
to believe that there is a tangible advantage to using different application
protocols on each hope rather than using the same SOAP-based
(object-specific) application protocol across all the hops.  I'm trying to
understand what that advantage is.

You say that it "becomes prohibitively expensive to secure and optimize each
protocol" and that repeated attempts to do this over the Web have failed.  I
think you need to get considerably more concrete to convince people.  For
example, consider a purchase order being sent from a small customer out on
the internet to a web service bridge that then sends it via some non-HTTP
transfer/transport to the application that ultimately processes it.  Without
using the term Bad Thing <grin> or appealing to authority (of the OSI
reference model or Dr. Fielding), explain why it is more secure, reliable,
or economical to have the bridge translate from one application protocol to
another rather than using the SOAP-based application protocol "tunneled"
through HTTP over the Web and tunnelled through MQ (or whatever) back to the
application.  (Remember, my example implies an HTTP Post operation, so
appeals to cacheing, hyperlinking, etc. are irrelevant). 

Maybe I'm misunderstanding something, but it seems to me that
application-level protocol translation is what middleware bridges do today,
and that has proved to be labor intensive, fragile, and expensive.  The
promise of SOAP is to provide enough standardization for the network effect
to do its magic on the tools/education front, as well as to minimize the
run-time overhead of all this protocol translation.  

The BIG challenge of the web services architecture is that it lies at the
intersection of several things we sortof understand -- the Web, distributed
object systems, and XML -- but that they have somewhat inconsistent
principles of operation.  We (the W3C Web services activity considered
broadly) have already made some compromises; for example, some of the
richness of XML is forbidden in SOAP because it just doesn't fit well in the
web services use case (DTDs and all the stuff they define, such as external
entities, default attribute values, etc.).  Likewise, there's a mismatch
between the data structures and type systems one can define in a distributed
object system and the constraints of XML and the W3C schema language, and
the XMLP group has wrestled with this for a long time.  There's also a
mismatch between the RESTful principles of the Web and the way that the
object systems of the languages in which the applications on each side of
the web service are written.  Our mission is to sort this out, and it will
take mutual understanding, and compromise.

Received on Tuesday, 28 May 2002 11:30:10 UTC