tag:blogger.com,1999:blog-13639021.post706640042195701523..comments2024-03-05T04:05:47.416-08:00Comments on The Wisdom of Ganesh: The Good in WS-* (Update)prasadgchttp://www.blogger.com/profile/00179696156998026173noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-13639021.post-55015609783692076922008-01-28T12:55:00.000-08:002008-01-28T12:55:00.000-08:00Firstly, a note - I don't have comments on my site...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. ;-)<BR/><BR/><I>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</I><BR/><BR/>: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." <BR/><BR/><I>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).</I><BR/><BR/>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.<BR/><BR/><I>SOAP has a single-level layering approach.</I><BR/><BR/>Only if it rides on top of UDP. ;-) Otherwise, you gotsta know what you're sittin' on!<BR/><BR/><I>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><BR/><BR/>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. <BR/><BR/>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. <BR/><BR/>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?<BR/><BR/>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. <BR/><BR/>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?stuhttps://www.blogger.com/profile/04847797042239107066noreply@blogger.com