WS-WhatThe?

As the community continues to invest in Web Services, particularly through the rise of SOA, vendors are adding to them an obscene amount of capabilities via specifications collectively known as WS-*. When I last looked there were no less than 48 in the set. 48. That has to be written again – 48. Obscene. Given no one body regulates the set and vendors are after a piece of the SOA pie, you can see how this has all come about.

It used to be so simple – just code invocation via the web. So I write this post as I recently had a wonder through these specifications to see if anything was actually of some use.
Turns out there are a couple.

• WS-Security for message signing and encryption. It can be useful if HTTPS communications is not for you. Turns out that its performance can be dismal though.
• WS-ReliableMessaging for messages that simply must by received.

Out of 48, for mind, these 2 are clearly the most useful. Admittedly others have benefits in certain situations – but note that a large majority of the 48 are proprietary and some far from realization.

Another I imagined could be useful is WS-BPEL, a standard describing a language that allows one to orchestrate (apparently not be confused with choreograph) a Web Service facade that invokes other Web Services and applies transformations to data. Apparently this language is easily visualizable, allowing non-developers to orchestrate the interactions. However, when I saw the section of this Open ESB presentation dedicated to WS-BPEL I laughed. Code is surely easier to understand than some of the visualized examples therein. There is a crescendo as well – check out the claims of ‘Near 0 coding’. Why oh why? Code is not the enemy – clearly some of these sorts of tools are. Developers prefer not to use them and, given the concepts at play, those in business facing roles never will either.