SOAP for the Enterprise

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.