Mike Herrick, who just happens to be one of my Burton Group clients, has accused me of having "totally drunk the WS-* the Kool-Aid". He goes on to say, "I just was disturbed that given the history on things like J2EE she so easily assumed that WS-* will survive and thrive."
Let me make this clear:
I'm one of the folks responsible for mixing the Kool-Aid. I presented at the W3C Workshop on Web Services (representing Sun). I participated in numerous standardization efforts at W3C, OASIS, WS-I, uddi.org, and JCP. I have a vested interest in making sure that WS-* succeeds.
I had a similar vested interest in CORBA (I was working for DEC at the time), and I was just as enthusiastic about CORBA then as I am about WS-* now. At the time, CORBA was the state-of-art in distributed computing technology. And today, I think WS-* is the state-of-the-art in distributed computing technology. But I by no means assume that WS-* will always remain the state-of-the-art. I assume that something better will come along. Unfortunately, it hasn't come along yet, so we have to make do with what we have now.
The single, most important feature that inspires my enthusiasm about WS-* is that it has universal support from all the major vendors. The technology has become pretty much pervasive (although the industry is still stuggling with interoperability issues), and there's a huge ecosystem of vendors and products and tools that support it. WS-* also has some really interesting innovations (separation of header and body, the composability of the various SOAP extensions, policy-based management and control via intermediaries, etc), which I think make it particularly well-suited for enterprise-class service-oriented application systems.
There. I've qualified it. WS-* is enterprisey. But is that really such a bad thing? If you need comprehensive enterprise-class semantics (security, reliability, session management, transactions, etc), then it really helps to use an enterprisey middleware system.
People accuse WS-* of being too complex. (Somewhat remarkable when you think back to 2000 when everyone was extolling SOAP's simplicity.) Well -- if, as a developer, you need to understand the details of all 60+ WS-* specs, then, yes, WS-* is way too complex. But that's a symptom of WS-*'s immaturity. If we had proper tooling, the only folks that would need to be concerned with all the 60+ specifications are the folks implementing the WS-* toolkits. Developers should really only need to be concerned with a handful of the specs: SOAP, WSDL, and XML Schema--maybe WS-MetadataExchange. Everything else should be handled transparently by the toolkits. I think we'll get there. Microsoft's WCF ("Indigo") demonstrates how easy it can be to use WS-Addressing, WS-ReliableMessaging, WS-Security, WS-Trust, and WS-SecureConversation. All you have to do is specify an annotation, and everything is automatically implemented behind the scenes. I expect the other vendors to deliver better tooling at some point. Now that WS-Policy has finally moved into the standards track, we should start getting much better configuration tools.
But I can't ignore the debate between REST and WS-*. I'm a huge proponent of the KISS principle. So I don't recommend using WS-* for all service interactions. If an application doesn't require enterprisey infrastructure semantics, then it's much more appropriate to use a simpler middleware system, such as "plain old XML" (POX) over HTTP. In fact, for applications that require Internet scalability (e.g., mass consumer-oriented services), POX is a much better solution than WS-*.
But that doesn't mean that POX is the best solution for all systems, either. POX doesn't support a clean separation of business and infrastructure functionality, so if you are using POX and you need enterprisey infrastructure semantics, then you need to code the infrastructure functionality in your application code. Bad idea. The reason you use middleware in the first place is to help reduce the amount of infrastructure functionality the developer has to write.
The point is that you should always use the tool that best fits the job. Let the application requirements dictate your selection of middleware.