From early on in my work as a member of the XML Protocol WG to make SOAP 1.2 usable in a REST based architecture, I found myself up against the unmoveable force known as “protocol independence”.
I was reflecting on this experience in the car this morning, and realized that I could perhaps explain the different viewpoints – of “protocol independence” and “transport vs. transfer” specifically – in terms of message metadata.
Message metadata is that data in a message which defines the context for interpretation of the rest of the data in the message. Application protocols typically have a handful of pieces of it. For example, HTTP has the protocol version, request methods, request URIs, and response codes, and each one of those changes the meaning of their message fundamentally.
My issue with “protocol independence”, which essentially says that you should put everything you need to know in the SOAP envelope, is that it requires me to a) disregard the metadata already provided by application protocols, and b) requires me to reinvent the same mechanisms higher up! Here’s two examples of that form of reinvention;
- the one I talk about a lot; defining a new place to put the requested operation
- putting the target identifier in the SOAP envelope
One type of message metadata that hasn’t, to my knowledge, been reinvented, is the response code metadata. I don’t mean the response codes themselves, as SOAP does have different standard fault types. I mean a standardized place in a SOAP envelope which indicates whether the SOAP message is a fault or not. What’s that you say? The mere presence of a SOAP fault in the body of the envelope is sufficient information to identify the fault? Ah, I see. Well then, you’ve got a message metadata problem. To explain it, consider a Web service with an operation whose job is to return the last fault that the service generated. How do you distinguish between the success of that operation and its failure? Both return faults inside the SOAP envelope! One way would be to define a wrapper that encapsulates the fault in the not-a-real-fault case, thereby hiding it. But that wrapper is exactly the kind of message metadata that I’m talking about!! Another case of reinvention, and again, completely unnecessary when you’re using an application protocol which already has a place for such metadata. When you consider that SOAP doesn’t define this wrapper, then you have to conclude that either a) SOAP is broken, as it prevents me from defining services which return data that looks like a fault, or b) there’s another way to use SOAP, as an extension protocol which reuses the message metadata of the underlying protocol (when it has any, which all application protocols do).
no comment until now