Proposed issue: Separately named specification

There are three major usage modes or ways to think about SOAP. 

1. as a very generic messaging framework, as described in part one of
the specification.

2. as a remote procedure call mechanism as in Part 2, Section 5.

  2 a) An encoding for parameter values
  2 b) A method calling syntax

3. as an extension mechanism for HTTP, as discussed in 6

Unfortunately, communication between developers or between customers and
vendors is hampered by the different levels of interoperability implied
by these different usage modes. For instance a vendor supporting SOAP
messaging might not support RPC. Their product would not be
interoperable with a product that depended upon RPC. And in fact (though
this is a lesser issue) a SOAP implementation that supported RPC but not
the SOAP encoding might not be compatible with one that supported just
RPC. Some RPC-oriented SOAP toolkits might not have any mechanism for
sending "pure XML" SOAP messages not using the SOAP encoding or RPC
conventions. Unfortunately SOAP is full of the kind of optional features
that the XML people tried so hard to avoid. 

This is an interoperability headache and the beginning of a
terminological nightmare. Some people believe SOAP is an "abstract
messaging language" like MIME envelopes. Others believe it is a concrete
RPC language...like DCOM for the Internet. They are both right and
acting on their correct beliefs they will be able to easily make
software that is completely incompatible. A user buying a "SOAP
implementation" has no idea what they are getting.

I propose, therefore that SOAP be split, as XSL was split, into
languages with unique names. I propose SOAP-Messaging, SOAP-RPC and the
SOAP HTTP Binding. Arguably SOAP-RPC could also be split into the SOAP
encoding and SOAP-RPC but it may not be helpful to slice that finely.

 Paul Prescod

Received on Tuesday, 12 February 2002 16:13:50 UTC