Web Services Jeopardy

My blog posts related to IT strategy, enterprise architecture, digital transformation, and cloud have moved to a new home: ArchitectElevator.com.

WS-Alphabetsoup

The fact that we now refer to the Web Services standardization efforts as "WS-*" (* being the wildcard character) is a pretty good indication that most people have lost track of the countless individual standardization efforts. There is no doubt that most of these proposed standards pursue a worthwhile goal. Typically, these proposals advocate to add a set of agreed upon fields to the SOAP message header. Each proposed standard defines the name, type, and meaning of fields and how they are supposed to be used. For example, WS-Addressing recommends to add header elements <from>> and <to> that identify the sender and ultimate recipient of stream of SOAP messages. These fields are very useful if a SOAP message is routed through intermediaries on its way to the ultimate destination. Other proposed standards add fields for security, reliable message resend in case a message gets lost, and much more. The details of the standard implementation are generally of little interest to the users and developer as the intend is for every vendor to agree to the standard and to incorporate support in their Web services toolkit.

Unfortunately, this is where things get complicated. Most of these specifications are no standards at all but rather proposals drafted by a specific group of vendors. The vendor list is typically composed of the usual suspects: Microsoft, IBM, BEA, Sun and smaller middleware and Web services vendors such as TIBCO, IONA, Arjuna and others. Many drafts are even hosted on the vendor's site. Others are submitted to organizations such as OASIS, which decouples them a little bit from the vendor itself. We need to keep in mind, though, that requirements for submission to OASIS are fairly loose. The fact that a specification is hosted on OASIS is no guarantee that it is a widely adopted and supported standard. It is also no guarantee that vendors can freely implement the standard without having to obtain permission or pay license fees.

As a result, for many WS-* drafts the list of vendors at the top might be the most interesting part for the Web Services developers and architects because it gives an indication which vendors are likely to implement the proposed standard. However, recently this is no longer a guarantee either. For example, Microsoft has received some flak for their less-than-expected support for BPEL in BizTalk Server 2004 despite their active involvement in the definition of the specification. The same is true for other vendors as well -- I am just using Microsoft as an example.

WS-Jeopardy

Now that I have drawn such a grim picture about the WS-* efforts, why should we even pay attention at all? First of all because a lot of very smart people are contributing to these proposals. Most of the proposal contributors are experienced architects and developer with many years of experience developing distributed solutions. With that experience it is often that these architects identify an important aspect of distributed computing that is missing from the current Web services specifications. For example, the ability to send one-way message reliably. Or the ability to route a message through a number of recipients before it reaches its final destination. These architects then go on to form a vendor-sponsored committee to find a way to fill the gap.

This is all good. But once the multi-vendor politics come into play, things get much more difficult. Who is supposed to contribute how much, who gets to implement when, who makes the first step, who endorses, who is left out etc. etc? That's why I propose that architects and developers of service-oriented architectures should look at these standards as a form of Jeopardy. Instead of focusing on the answer (the details of the standard), have a look at what problem the standard is trying to solve. More likely than not, it is a problem that you are going to have when you go to implement your architectural vision. For example, not knowing where SOAP messages come from and where they are going makes debugging and diagnostics very hard. Not being able to reliably send asynchronous messaging is likely to result in a brittle and not very scaleable "RPC-over-the-network" model.

Therefore, I propose to many of my clients to use the WS-* standards as a checklist for their designs. I generally do not recommend they use WS-Addressing or WS-ReliableMessaging (or at least not right out of the gate). I do, however, challenge them by asking, "What is your strategy to track messages in case of error?" or "How do you intend to support asynchronous messaging?" The answer has sometimes little to do with Web Services. For example, the answer to reliable asynchronous messaging might be to use JMS or MQ or another middleware that ensures guaranteed delivery of asynchronous messages. And that's OK. ...