See post below for my initial, entirely positive reactions to Stu Charlton's critique of the WS-* family of Web Services technologies.
Now for some qualifiers.
I wonder why Stu didn't include SOAP in the list of "good" technologies. I don't mean the overloaded meaning of SOAP (the RPC style of usage, for example), but quite simply the SOAP message, the envelope. All the WS-* stuff is useless without the primary vehicle of the SOAP message which carries them from endpoint to endpoint. One has to admit there is a certain elegance in its simplicity, analogous to the humble IP packet that is the workhorse of the Internet (read more here).
The envelope has just two parts - a header and a body. All the domain-neutral WS-* tags that Stu talks about go into the headers. The body contains domain-specific XML payloads that hopefully conform to some defined schema. Unlike with the TCP stack, where packets are recursively enveloped within other packets (e.g., HTTP inside TCP inside ESP (IPSec)), ultimately being packaged inside IP for transport over the "wire", SOAP has a single-level layering approach. All quality-of-service tags represented by the WS-* standards are placed on a co-equal basis within the SOAP header, which is OK because they largely represent orthogonal concerns. (There is still some interdependence, e.g., you can't just have WS-Security if you're using WS-ReliableMessaging; you need WS-SecureConversation as well, because the system now has to be cognisant of conversation state.)
The SOAP message represents, at once, a domain-neutral wire protocol that supports any application and a domain-specific application protocol that defines the verbs, nouns and conversation grammar of a particular application domain.
I see both SOAP and REST as ways to move domain-specific XML documents around. From that angle, they're both defining a core application wire protocol that can support any application domain (HTTP or SOAP-with-headers). Each application has to define the nouns, verbs and conversation grammar appropriate to it and exploit this "wire protocol" to move the XML noun payload in the context of an interaction verb (GET/POST/PUT/DELETE being pre-defined within the REST wire protocol or a bespoke one for SOAP/WS-*) and thereby build up a domain-meaningful conversation, what the REST folk call a state machine and what the SOAP/WS-* folk call a process.
I think we're all in violent agreement over the need to move XML around in a series of interactions that occur within the larger bounded context of a state machine or process. As has been said in many other contexts, our similarities are greater than our differences, so let's not read too much into the SOAP-REST debate.
William Vambenepe has more to add on this. It's an earlier post, but very topical. There's a lot more promise in SOAP than most of us realise, and the standards themselves sometimes belie that promise. Read William's post to see what needs to be fixed, hopefully in the next version of the WS-* standards.
Now for some qualifiers.
I wonder why Stu didn't include SOAP in the list of "good" technologies. I don't mean the overloaded meaning of SOAP (the RPC style of usage, for example), but quite simply the SOAP message, the envelope. All the WS-* stuff is useless without the primary vehicle of the SOAP message which carries them from endpoint to endpoint. One has to admit there is a certain elegance in its simplicity, analogous to the humble IP packet that is the workhorse of the Internet (read more here).
The envelope has just two parts - a header and a body. All the domain-neutral WS-* tags that Stu talks about go into the headers. The body contains domain-specific XML payloads that hopefully conform to some defined schema. Unlike with the TCP stack, where packets are recursively enveloped within other packets (e.g., HTTP inside TCP inside ESP (IPSec)), ultimately being packaged inside IP for transport over the "wire", SOAP has a single-level layering approach. All quality-of-service tags represented by the WS-* standards are placed on a co-equal basis within the SOAP header, which is OK because they largely represent orthogonal concerns. (There is still some interdependence, e.g., you can't just have WS-Security if you're using WS-ReliableMessaging; you need WS-SecureConversation as well, because the system now has to be cognisant of conversation state.)
The SOAP message represents, at once, a domain-neutral wire protocol that supports any application and a domain-specific application protocol that defines the verbs, nouns and conversation grammar of a particular application domain.
I see both SOAP and REST as ways to move domain-specific XML documents around. From that angle, they're both defining a core application wire protocol that can support any application domain (HTTP or SOAP-with-headers). Each application has to define the nouns, verbs and conversation grammar appropriate to it and exploit this "wire protocol" to move the XML noun payload in the context of an interaction verb (GET/POST/PUT/DELETE being pre-defined within the REST wire protocol or a bespoke one for SOAP/WS-*) and thereby build up a domain-meaningful conversation, what the REST folk call a state machine and what the SOAP/WS-* folk call a process.
I think we're all in violent agreement over the need to move XML around in a series of interactions that occur within the larger bounded context of a state machine or process. As has been said in many other contexts, our similarities are greater than our differences, so let's not read too much into the SOAP-REST debate.
William Vambenepe has more to add on this. It's an earlier post, but very topical. There's a lot more promise in SOAP than most of us realise, and the standards themselves sometimes belie that promise. Read William's post to see what needs to be fixed, hopefully in the next version of the WS-* standards.
1 comment:
Firstly, a note - I don't have comments on my site because of spam issues. Some day I'll upgrade my blogging software to enable them again. For now, I make do with remote conversations like this. ;-)
I wonder why Stu didn't include SOAP in the list of "good" technologies. I don't mean the overloaded meaning of SOAP (the RPC style of usage, for example), but quite simply the SOAP message, the envelope
:Shrug: I sat in a room with Don Box back in 2001 where he said something like (paraphrasing): "Now that XSD is around, SOAP is mostly unnecessary. The encoding was all that really mattered, and now it's obsolete. The envelope is mildly useful, but not really all that important. We're probably stuck with it. Sorry."
One has to admit there is a certain elegance in its simplicity, analogous to the humble IP packet that is the workhorse of the Internet (read more here).
The *idea* of a header / body split is a long-held pillar of protocol design for performance purposes. It's questionable whether using XML for that format adds a lot of value. Most SOAP processors don't actually optimize for header inspection -- they parse the whole message. It's only recently that you're seeing implementations that do header sniffing. So, here we are, over 7 years after the spec, and we're only now getting experience with how much the header/body split matters in practice.
SOAP has a single-level layering approach.
Only if it rides on top of UDP. ;-) Otherwise, you gotsta know what you're sittin' on!
The SOAP message represents, at once, a domain-neutral wire protocol that supports any application and a domain-specific application protocol that defines the verbs, nouns and conversation grammar of a particular application domain.
So does every other well-known messaging middleware protocol out there. It's been done for 25 years. The only difference with SOAP is that "it's in XML". That was the whole point of it back in 1999 when they were building it. The idea was that XML == interoperability.
One common theory in the early days of SOAP was that messaging middleware was the "key" to universal interoperability and reuse -- we just need to nail the vendor squabbles, and we'd be on a ticket to utopia. But all we do is inherent the problems we've had with MQ or JMS or [insert MOM here] integration.
There are organizations standardized on Websphere MQ for their interoperability for over 10 years, but it didn't automagically lead to agile, reusable, evolvable system of systems. Many places still require $10's of thousands to make any sort of change, and days to weeks for administrators to set up a new node. Is this going to change in a world when the only major difference is the format of the payload is (maybe) extensible?
Frankly, s/SOAP/HTTP or s/SOAP/SMTP and the quoted sentence above would also be correct. The major difference is that they have picked a very generic abstraction for the behavioral semantics, instead of letting the user define the semantics in a domain-specific way.
The difference is one of scalable governance: if crossing organization boundaries, and thus semantics, is common, we can't be expected to insert glue code everywhere, can we?
Post a Comment