As part of the SOAP vs REST/HTTP/Web discussion on xml-dev, the issue of why should one concider using SOAP vs the ad-hoc passing XML of XML messages has come up. Here is my take on these issues.

SOAP or REST/HTTP/Web

SOAP is intended to be used to build distributed systems using a message passing methodology. I don't think it is necessary for this to take place in a RESTful way. If a binding for SOAP over HTTP that is RESTful is defined, great! If SOAP can't use HTTP because SOAP is found to be fundamentally non-RESTful (which I do not believe is the case), then I think SOAP is no less valuable for building the kinds of systems it is intended to be used for.

SOAP is much more then RPC over HTTP using POST. Resolving the questions around the relationship between SOAP, XML Web Services, the Web, REST, and HTTP will help SOAP move past it's (IMO, misguided) RPC over HTTP beginnings. If, when all is said and done, I'm left with something that should be called "XML Services" or "XML Internet Services," instead of "XML Web Services," I really don't care.

There are many other uses for XML on the web besides building message passing distributed systems. I am all for those uses. They should all be used as needed.

SOAP Messaging or Ad-Hoc XML Messaging?

It should be possible for distributed systems to be created and maintained by decentralized uncoordinated entities. Controlling (designing and implementing) both the sender and receiver of a message is a special, and relatively uninteresting, case.

This implies that such systems must be able to evolve without centralized control. Specifically, the definition of what comprises a correct message may be changed independently by the sender or the receiver at any time. That is not to say the system should continue to work when such changes occur, but that it must fail in a predictable way when it is broken.

To support this, there must be a shared formal description of how messages should be structured, how they should be delivered, and how they should be processed. Only then can you reliably detect when you receive a message you didn't expect and, when possible, communicate this failure in an unambiguous way to the sender of the message.

SOAP is nothing more, and nothing less, then such a formal description.