Re: SOAP and transfer/transport protocols

On Tue, May 28, 2002 at 11:30:07AM -0400, Champion, Mike wrote:
> 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). 

If the payload is just a purchase order, then we are completely in
agreement about the value of this example.  I don't consider this to be
tunneling.

Sorry, I thought I was clear about this; what I object to, is putting
a method name in the payload.

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

Yes, because there are billions of different protocols that have to be
bridged (as I said, each API is a new protocol).  By using a handful of
application protocols (HTTP, SMTP, FTP, what else?), the number of
combinations of interfaces that bridges have to account for is
dramatically reduced.

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

I agree, except I don't consider the nuances of XML syntax to matter
much at the architectural level.  But I do agree that we have to work
out how to marry traditional "distributed objects" with the Web.  I've
spent most of the past 5+ years figuring this out for myself (it started
with over a year of banging my head against a wall 8-), and have
actually implemented my vision in my company's products.

At 50,000 ft, the way you bridge two architectures is to ensure that
the architectural constraints used by each are respected.  The only
architectural constraint used traditionally by "distributed objects"
(which I refer to as OO-RPC), is that all methods are invoked on
things with identity.  Agreed?

Conversely, the two most important (software) architectural principles
of the Web are, a) that all methods are invoked on things with identity,
and b) that all methods are generic to all things with identity.  This
will probably be more contentious, but Roy talks about it in his
dissertation.

If you merge/union those two, you end up with the Web.

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

Received on Tuesday, 28 May 2002 12:08:45 UTC