xml-dev - RE: XML over HTTP: SOAP and ...?

["Box, Don" <dbox@develop.com>]

Title: RE: XML over HTTP: SOAP and ...?

> -----Original Message-----
> From: Arjun Ray [mailto:aray@q2.net]
> Sent: Monday, March 06, 2000 1:22 PM
> To: xml-dev@xml.org
> Subject: Re: XML over HTTP: SOAP and ...?
>
> On Mon, 6 Mar 2000, DuCharme, Robert wrote:
> > I gather from http://www.develop.com/soap/soapfaq.htm#22 that
> > xml-rpc cooperates with SOAP more than it competes with it,
> > although I may have misunderstood this.
>
> I believe the issue there is whether SOAP will interoperate with
> XML-RPC (given that the latter has been used for some time, and the
> former is um, gathering steam thanks to stoking by you-know-who) and
> *continue* to do so.

There are a variety of interoperation strategies between SOAP and other XML-based transfer syntaxes (XML-RPC being one of many). Until the XTech BOF, no one from either MS or Userland has publicly mapped out a clear path for interop between XML-RPC and SOAP. Since then, DevelopMentor has written an XSLT-based translator (http://soap.develop.com/xmlrpc) and we are anxious for the XML-RPC community to pitch in a bit and help chart the course. BTW, DevelopMentor (and I) have arguably put as much public energy behind SOAP as MS or Userland has, if not more.

> The SOAP spec has "Microsoft crud" written all over it (as in,
> overload it with as many features and complexities as it takes to
> convince people that they really shouldn't bother trying to implement
> it themselves but just get um, "authorized" software from um,
> "official" sources.) 

Wow, this couldn't be further from the truth. I've been especially adamant that no one should wait for some grand marketecture, component gallery, or resource kit; rather, SOAP is sufficiently simple to implement on your own. Check out my XSLT converter. SOAP is far less verbose than XML-RPC and arguably closer to the way most people write XML. During conference talks, I typically implement a SOAP client and server from scratch in a text editor in about 15 minutes or so. The technology is approachable even if our spec isn't.

> Alternatives like WDDX, XML-RPC, and LDO go a
> long way to show that the "problem" isn't nearly as complicated as a
> reading of the SOAP spec might lead one to believe.

Some problems are more complicated than others. My co-authors and I tried to reach the "80/20" point in terms of functionality. Unfortunately, some people's "80" is another person's "20." 

Also, please be aware that you are comparing a spec that was written by multiple engineers in "spec-speak" to a web page written by one web-journalist/entrepreneur. I'd be curious to see what actual features of SOAP you find redundant or superflous. Additionally, I'd love to know if you see the limitations of XML-RPC, or did Dave's anti-MS posting on the SOAP list convert you to XML-RPC simply on principle?

 
> The trouble is that the marketing machine is going to tout SOAP as
> some sort of superset ("more general", "more flexible" - oops, gotta
> use W3C speak, sorry - "more evolvable", etc.), so enough people just
> might lose sight of the fact that a Light-Weight Protocol could
> *really* be enough.

Again, please identify two or three SOAP features that (a) are not "lightweight" and (b) are required by all implementations. You were kind enough to send me some editorial comments privately, but none of them called into question any technology in the spec, rather just our sub-optimal wordsmithing and organization (both of which will be cleaned up in the next edit cycle).

I'm sorry that the spec "smacks of W3C bogosity," but some of us would rather move on than fight old battles that are largely irrelevant by this point. Whining about how AF should have been adopted instead of namespaces sounds faintly like whining about how OS/2 should have triumphed over NT (or the Amiga should have triumphed over the Macintosh, or ...).

DB
http://www.develop.com/dbox