Slippery SOAP: The 2-Sides of SOAP

For now this document is a scratch-pad where I will document the world's different views of SOAP. I feel this is important because there are many people who like SOAP because they feel that it is a better RPC protocol. Then there are other people who like SOAP because they feel that the RPC aspects are in decline. I feel that there will be some "interesting" collisions when these two views collide in the real world. Of course a SOAP supporter would say that there are a spectrum of uses and that they will coexist without conflict. At the very least, the competition between views is contributing to widespread confusion in the industry.

The RPC-is-in-Decline View

The strongest argument for this point of view comes from the SOAP specification itself. Over time it has evolved from being DCOM (RPC) over the Web to a protocol where the RPC portion is an "adjunct".

Many folks are providing arbitrary document oriented messages using SOAP/HTTP. In fact, there seems to be an emerging point of view that document/literal is preferred over rpc. So please, let's not say soap=rpc

- David Orchard (standards guy for BEA and member of the W3C's Technical Architecture Group) - on www-tag

He also encouraged attendees to consider when building Web services whether to program to an object-centric or XML-centric model. One pitfall to look out for in the object-centric path is how to obtain extensibility when you are programming at a high level, he said.

- Mark Lucovsky (architect of Hailstorm) -Infoworld CTO Forum

The trend in SOAP really is to make it less of a "SOAP-RPC on steroids" and more of a generic, transport-neutral, message architecture-neutral, low-level but theoretically interoperable protocol

- Michael Champion (he was paraphrasing his impression of the emergent view of SOAP) - on xml-dev

SOAP-RPC is getting too much hype as you rightly point out. But SOAP (envelope, extensible header section, and body) is very useful. Just strip out the encoding stuff, your life will be more pleasent

- Justin Rudd, on a Web discussion forum

[SOAP is] an extensible message based framework without much core functionality other than extensibility itself.

- Microsoft's Henrik Nielsen on xml-dev

SOAP primarily defines a message format. What distinguishes SOAP from arbitrary MIME types is that SOAP implies a particular processing model (with respect to headers) and defines a family of well-known fault formats.

- Don Box (one of the inventors of the original RPC SOAP) in xml-dev

Among the problems with HTTP, said Box, is the fact that it is a Remote Procedure Call (RPC) protocol; something that one program (such as a browser) uses to request a service from another program located in another computer (the server) in a network without having to understand network details. This works for small transactions asking for Web pages, but when Web services start running transactions that take some time to complete over the protocol, the model fails.

- Don Box (one of the inventors of the original RPC SOAP) in xml-dev

The RPC-is-Cenral View

I will present less evidence of the "SOAP is RPC" view because SOAP started out being entirely RPC so obviously this is still the dominant view in most people's minds, still the dominant usage pattern and still what most toolkits support best. It is hard, when you find a quote that treats SOAP as RPC to know whether it is historical and thus reflects an out-dated point of view, or is modern.

As I said in the introduction, with SOAP you can make requests of Amazon.com's database just as if you're calling a local function. You just need to know what function to call and what parameters to pass it.

Adam Trachtenburg A PHP Web Services Client ONLamp.com

SOAP defines an "XML-RPC" protocol for client-server interaction across a network by using the following mechanisms:

- Original SOAP specification

If SOAP/1.0 (the last pre-IBM version) (also the pure-RPC version -- PP) was a bad idea, then so was SOAP/1.1 (the first post-IBM version, which was submitted to the W3C) (also the first version to mention that SOAP can be used in a non-RPC fashion -PP). There were no major improvements to SOAP from 1.0 to 1.1. The specification was reorganized to make the modular design of SOAP more apparent. However, the few minor technical changes we made were arguably a step backward (in fact, I believe to date there are no SOAP implementations that do anything meaningful with the one new feature, SOAPActor).

- Don Box, on xml.com, less than a year before the "SOAP is an envelope" quote above,

"For the purposes of this document, SOAP is a Remote Procedure Calling protocol that works over HTTP."

- Dave Winer's Busy Developer's Guide to SOAP -- Dave is one of the other inventors of SOAP

"One of the big issues for the 1.1->1.2/XMLP move was how many design patterns it should support other than RPC, and a lot of the confusion about its being both a dessert topping and a floor wax comes from its being (((not (not a dessert topping)) and (not (not a floor wax))).

- Clay Shriky, decentralization mailing list

Why Do I Care?

• The situation is demonstrably confusing. One need only mention "SOAP" in a mailing list or discussion group and a huge thread will arise on the "true nature" of SOAP.
• It is bad standards design: the SOAP envelope is useful without the SOAP encoding. SOAP headers are useful without the SOAP envelope. The SOAP encoding is useful without the SOAP header. When this happens it is usually considered proper to separate the reusable bit into a separate specification for orthogonal use. For instance XSLT was split from XSL, XPath from XPointer, RDF from PICs, etc.
• SOAP has been sold on its ease-of-use and growing interoperability. SOAP RPC is easy to use because it doesn't require you to think about building or parsing messages. The newer "document style" SOAP does not have this advantage.
• SOAP implementations that take the RPC view may not be interoperable with those that take the envelope view. At the very least their APIs will be radically different. At worst, they will not even interoperate at the wire protocol level.
• SOAP's envelope incarnation is a completely different vision of a protocol, largely created by a completely different set of people.
• The world was "sold" SOAP based on the presumption that it would be an RPC protocol. You often hear: "I've used CORBA and SOAP and I find SOAP simpler". Bringing the new envelope stuff into the protocol is a way of creating a new standard that inherits the political momentum of an old standard, without proving itself in terms of interoperability. (not unlike calling an XML Schema language XML Schema as if it was somehow part of XML)
• Conversely, if the envelope takes off but we come to feel that the RPC part was ill-thought out, it will be politically impossible to remove it from future versions of the SOAP specification.
• The SOAP RPC-over-HTTP issue is quite controversial. It may slow the release of the rest of the SOAP specification.

What do I propose to do about this problem? I propose that SOAP be split into separately named and maintained specifications. That suggestion has been rejected.

Which Camp Are You In?

• Do you think SOAP is great because it is so easy to generate SOAP interfaces from existing classes?
• Do you think that SOAP Interoperability is about easily marshalling and demarshalling primitive objects in a consistent manner?
• Do you think that every SOAP method call will return synchronously?
• Do you think that it should be possible to use SOAP without knowing anything about XML?

If you answered yes to all of these then you are strongly in the SOAP-is-RPC camp.

• Do you think that SOAP is great because of its envelope and headers?
• Do you think that the marshalling and demarshalling of XML elements to objects should be explicit?
• Do you think that the message exchange characteristics of a method call will depend on the underlying transport?
• Do you think that people using SOAP need to understand XML because they will need to map between XML and native data structures?

If you answered yes to all of these then you are strongly in the so-called document/literal camp. You are also a potential recruit to the REST point of view because you have given up on the idea that distributed computing can be made as easy as local method calls.