savas parastatidis

What makes a SOAP document a message

Mark Baker comments on Steve Maine's "Web Services Kernel" post and says:

"A SOAP envelope is not a SOAP message, and pretending otherwise turns a perfectly good document wrapper into a perfectly crappy application protocol."

Hmmm... I think Mark makes a good point but I also believe that it is all relative. You see, in real life, an envelope is nothing but a folded piece of paper. It has no meaning on its own. However, it's only when you fill this folded piece of paper with written pages, you put a recipient and a sender address, you attach a stamp on to it, and send/post it, it becomes a letter. Anyone seeing it on the way will say that this is a letter; they won't say it's a folded piece of paper.

The same with a SOAP documents. A SOAP document with some WS-Addressing information and some payload becomes a SOAP message. When you see one, you know that it's a message and not just a document. It's the transmission of such documents (the messages) that makes it possible for us to build WS applications.

Labels are relative me thinks 🙂

6 responses to “What makes a SOAP document a message”

  1. Mark Little
    I’d be careful how far you take the analogy between physical envelopes and SOAP envelopes. It’s worth remembering that people can use physical envelopes by themselves by turning them into postcards: stick the thing down empty and write the message on the back of it!
  2. Steve Maine
    I think that Mark’s point was that the envelope is nothing without semantics. Mark would prefer those semantics come from an HTTP protocol verb; the SOAP-centrists want those to come from wsa:Action.
  3. Steve Maine
    (Whoops – sent that too early). The question of “where do we put the semantics” is fundamentally separate from “how many verbs can we use”. I think it would be generally helpful to separate the two into separate arguments.
  4. Savas Parastatidis
    I agree that the two arguments are separate and should be separated. I am amongst those who support the complete removal of any operation/verb-specific semantics from the message and the underlying transport protocols.
  5. Stefan Tilkov
    I can’t see what’s wrong with putting addressing information into the SOAP header, thereby turning a SOAP document into a SOAP message. I agree, though, that it’s strange to send this message over a transfer protocol like HTTP; but if you want to re-use the same message over things that are as different as HTTP, TCP, UDP and TIBCO, there’s little choice but to accept this.
  6. Mark Baker
    Yah, Steve’s exactly right in his comments there. But what’s weird is that you’re always going to be dependent on a protocol. Why is it ok, per Web services conventional wisdom, for a developer to code directly to WS-Transfer operations, yet not to HTTP operations? It makes no sense. The whole “protocol independence” thing – at least where it means that the developer has to be ignorant of the protocol – is just legacy-think from CORBA/DCOM/DCE/RMI-land. There’s still other useful forms of protocol independence, such as being able to bind SOAP to different underlying protocols. But that needn’t suggest the developer-ignorant use of the term.