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

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

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

> -----Original Message-----
> From: Tom Scola [mailto:Thomas.Scola@us.rbcds.com]
> Sent: Tuesday, March 07, 2000 10:25 AM
> To: xml-dev@xml.org
> Subject: Re: XML over HTTP: SOAP and ...?
>
>
> Mark Birbeck wrote:
>
> > The main difference here is that you could write a SOAP
> implementation
> > in a weekend - you couldn't do the same for WebDAV!
>
> There's a big difference between SOAP and WebDAV.  DAV is an actual
> protocol that does work -- once you've developed DAV, you're
> done.  SOAP
> is just a framework -- once you've developed SOAP, you still have to
> develop your application on top of it.

I think that is precisely the value of the SOAP approach. At the end of the day, SOAP enables plumbers/infrastructure/libraries to generalize the XML->ZZZ serialization problem, where ZZZ is your language or progamming technology of choice. SOAP provides guidelines for serializing instances of programmatic types into XML in a way that is generalizable and automatable.

Yes, SOAP expects that you have application-level types that you want to ship back and forth. There is a clear path for doing that based on Section 8 of the SOAP spec. The problem with protocols like WebDAV, IOTP, DMTF, etc is that they reinvent the marshaling/transfer syntax over and over rather than leveraging a common format and defining domain-specific types in terms of a common set of idioms. SOAP attempts to codify how to map common programmatic constructs (structs, arrays, references) to the XML infoset. For example, given the following C++ structure definition:

struct Person {
   std::string firstName;
   std::string lastName;
};

One would encode it as follows:

<Person>
  <firstName>Don</firstName>
  <lastName>Box</lastName>
</Person>

If you wish to use XML schemas to describe your SOAP-friendly types, one would write the following type definition:

<complexType name='Person' >
  <element name='firstName' type='string' />
  <element name='lastName' type='string' />
  <anyAttribute namespace='urn:schemas-xmlsoap-org:soap.v1' />
</complexType>

XML Schemas Part II codifies the mappings between primitive types (e.g., boolean, double, string) and their XML representations. SOAP codifies the mappings between compound types (arrays, structs) and their XML representations.

Oh yeah, we also codify an extension model based on HTTP extension framework (RFC2774) and a standard mapping to HTTP, however both of these are optional.

> Pardon my naïveté, but I'm having a problem understanding the need for
> so-called "lightweight" protocols such as XML-RPC and SOAP in
> the first
> place.  If I wanted to write a distributed XML application I can:
>
> 1. Open a socket to a remote system
> 2. Authenticate the connection
> 3. Send and receive XML-encoded data over the socket

Absolutely. Thats all most SOAP applications do. The advantage to using a standardized encoding style is that people can build generic libraries to handle the marshaling/serialization of the XML into application-level types. If all you care about is exchanging XML documents, go in peace. You don't need SOAP or anything like it. If, however, you want to exchange instances of application-level types using XML as a transfer syntax, then you need just a wee bit more structure than is provided by the XML Schemas work if you care about ease of interoperation.

> Step 1 requires about 10-20 lines of C code, or about 2-3
> lines of perl
> or python.  Step 2 is complicated, but thankfully there are already
> libraries for that sort of thing such as openssl or
> cyrus-sasl.  Step 3
> is where most of the work takes place, and requires exactly the same
> amount of development time whether you're writing over a SOAP API, or
> using sockets directly.

I disagree. Our SOAP/Java implementation hides the XML serialization completely. We use Java reflection today and have an obvious plugin point to allow a schema compiler to emit static code for performance and control.

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