RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Sunday, August 19, 2001 9:27 PM
> To: Champion, Mike
> Cc: xml-dev
> Subject: RE: "Uh, what do I need this for" (was RE: XML.COM: How I
> Learne d t o Love daBomb)
> 
> I wish I had that confidence.  I'm afraid I see SOAP as 
> having overbuilt
> on rather rickety foundations in the first place, overstressing a
> protocol that wasn't designed for (or even accidentally suitable for)
> the kinds of operations SOAP is proposed to handle.

FWIW, SOAP (as of 1.1) is a wire format, and not intrinsically tied to HTTP.
The current draft, it is true, only defines HTTP (and HTTP extension
framework) bindings, but I know that a lot of thought has gone into making
it protocol-neutral.  You mentioned BEEP ... I don't know of any official
BEEP binding for SOAP being worked on, but it is definitely on the WG's
radar, at least as a use case.

I completely agree that the Web Services hype outstrips plausible reality by
a wide margin; none of the "opera loving car" keynotes mention the little
detail that the intrinsically greater latency, insecurity, and unreliability
of the internet requires applications that employ Web Services to be
designed much differently than LAN-oriented DCOM/CORBA apps are designed...
and (potentially?) giving a new generation of script kiddies a simple way
through all the world's firewalls scares hell out of me.   

I personally (obligatory disclaimer ...) suspect that SOAP over HTTP will
find its niche mainly as a cleaner, more standardized way of doing what
people have been doing with HTTP parameters and CGI scripts "forever. I've
sweated over the production and parsing of enough URLs from Hell that I grok
the SOAP / UDDI / WSDL vision of doing this in a more orderly manner.
Whether that provides a solid foundation for Yet Another Paradigm is another
matter entirely.