[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)
- From: "Simon St.Laurent" <firstname.lastname@example.org>
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- Date: Sun, 19 Aug 2001 23:10:55 -0400
On 19 Aug 2001 22:05:20 -0400, Champion, Mike wrote:
> 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.
True, and good to remember, but HTTP remains at least a dominant theme,
and it seems unlikely at best that SOAP would consider taking directions
that HTTP couldn't support easily.
> 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.
The BEEP folks have it on their radar as well:
It's especially interesting to read:
and ponder exactly how much the "SOAP Envelope" really adds to the
message in a system (BEEP) that was explicitly designed for 'generic'
> 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 figure firewalls will evolve to cope - 'stateful inspection' shouldn't
have too difficult a time picking out SOAP calls and blocking them when
appropriate. The latency, insecurity, and unreliability require deeper
> 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.
I suspect that XML-RPC handles 75-90% of what people have been doing
using HTTP and CGI for program-to-program communication forever. I have
a hard time seeing SOAP / UDDI / WSDL doing much to improve on "URLs
from Hell" (or URIs) as far as an orderly manner is concerned.
Oh well. SOAP may not represent very much of what I find interesting or
exciting about XML, but I can always hope that it will bring new people
to XML and maybe raise some interesting questions if not especially