This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

SOAP for the Enterprise

Stefan Tilkov,

A great post by Pete Lacey:

  1. The number of people using WS-ReliableMessaging in production today totals zero.
  2. The number of people using all of WS-Security (and not just username tokens) approaches zero
  3. These numbers hold true for WS-this-that-and-the-other-thing too.

Zeroing in on WS-Security we can note a few other things. To argue that securing the message (admittedly handy, but handled by XML Digital Signatures and XML Encryption, and only complicated by WSS) and not the protocol is of absolute importance, ignores the fact that we’ve been building secure applications without this ability since time immemorial. It further ignores that a sound architecture does not ask the endpoint to do the decryption, but that the decryption is done upstream in a web service intermediary of some sort, possibly one that precedes other intermediaries, thus negating this argument entirely.

Pete highlights an aspect I did not address in my post on this topic:

Yes, the SOAP envelope all by itself can be a good thing, but SOAP is more than an envelope. You can’t ignore how SOAP is packaged and sold, how it is specified, and how it is implemented. SOAP, despite everyone’s best efforts, is still a remote object protocol, and somewhere in the message, whether it be in the SOAP Body, in a WS-Addressing header, the outer element of a wrapped doc/lit message, or in the SOAPAction HTTP Header, is the method to invoke on the remote object. And, remember, to the business developer, SOAP is also WSDL, and a mish-mash of encoding styles and serializations, and impenetrable XML Schema, and tModels, and vendor wars, and ESBs, and shoddy specifications, and on, and on, and on.

I both agree and disagree with this assertion; it’s true that the current tools and frameworks still carry all of the old RPC baggage, but from a technical standpoint, SOAP can be used differently.

On November 9, 2006 2:22 AM, Mark Nottingham said:

Well said. In theory, SOAP can be used in a way that’s complimentary to the Web. In practice, the tools don’t let you do this. This tripped up a number of Web enthusiasts who thought they could tame SOAP.

WRT WS-Security, I asked how many people were using it in a crowd of about 500 developers during a panel I was on at last year’s Java One. Two people held up their hands (and one was Axis maven Glen Daniels). I asked how many would be using it in the next year; still only a smattering of hands. Then we asked the same question about SSL, and most of the room had their hands up. Go figure.

On November 10, 2006 5:58 AM, Mark Baker said:

Maybe Mark misread your last sentence Stefan, because I agree with him, and not with you; the tools don’t let you use SOAP in a Web friendly way. IMO, that’s game over for SOAP.

On November 10, 2006 7:47 AM, Stefan Tilkov said:

OK; let me rephrase that: From a theoretical standpoint, SOAP can be used in a Web-friendly way; from a practical standpoint, it’s very hard because the tools don’t give a damn (yet).