Re: SOAP and transfer/transport protocols

Mike,

On Tue, May 28, 2002 at 06:58:37AM -0600, Champion, Mike wrote:
> Sure, that's more or less my vision too.  Your (and Paul Prescod's)
> pushing has helped allow SOAP's HTTP binding closer to being "web 
> architecture friendly."

That's the easy part.  The hard part is to see that people (developers,
designers, architects) use it this way, which is why I'm participating
in this WG.

>  A Web Services Architecture should allow
> a smoother migration from the current "behind the firewall" stuff to 
> a more open and interoperable use of service resources on the Web. 
> But it MUST not force the DCOM/CORBA/MQ/etc. folks to migrate in 
> one jump; that simply will not happen.  

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.

This would happen in much the same way as IP was introduced, as a
protocol that could integrate LAN protocols on the Internet.  Of course,
we know how poorly IP is doing behind the firewall now. 8-)

I don't see an alternative to this.  Web services won't magically
work any better than DCOM/CORBA/MQ over the Internet unless they take
the lessons learned from 20+ years of application protocol design and
deployment to heart.

> The beauty of SOAP, IMHO, is that it is both a transport-neutral
> [and I use the term advisedly!] application-level protocol and 
> "just another XML format" that can be delivered using HTTP
> application semantics.

SOAP is not an application protocol, at least per OSI.  It doesn't
have any of its own methods.  SOAP has so many uses, that it's
really impossible to describe it unless you're describing how it's
being used in some scenario.

By moving APIs into SOAP and exposing a different interface per object,
you are using SOAP as a layer 6 protocol, and creating a new
application protocol for each object.  This is a bad thing, because it
becomes prohibitive to secure and optimize each protocol.  This has
been tried *many* times before on the Internet, and it failed each time.

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 10:25:11 UTC