[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

• From: "Simon St.Laurent" <simonstl@s...>
• To: "Champion, Mike" <Mike.Champion@S...>
• 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:
http://xmlhack.com/read.php?item=1275

It's especially interesting to read:
http://beepcore.org/beepcore/beep-soap.jsp
and ponder exactly how much the "SOAP Envelope" really adds to the
message in a system (BEEP) that was explicitly designed for 'generic'
XML messaging.

> 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
consideration, though.

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

Simon St.Laurent

• References:
  • RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)
    • From: "Champion, Mike" <Mike.Champion@S...>

• Prev by Date: RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d toLove daBomb)
• Next by Date: RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d toLove daBomb)
• Previous by thread: RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)
• Next by thread: Re: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d toLove daBomb)
• Index(es):
  • Date
  • Thread