Comments
Richard Davies wrote: The UK has a good crop of technology pioneers in cloud computing - for example ElasticHosts, FlexiScale, Flexiant, OnApp - and also some strong government initiatives such as G-Cloud. We will have to see whether this kind of technical leadership converts into swift mass-market adoption or not.
Cloud Computing
Conference & Expo
November 2-4, 2009 NYC
Register Today and SAVE !..
SYS-CON.TV
Today's Top SOA Links


Mixed Nuts
Mixed Nuts

One of the most frustrating things I've ever encountered in my life is trying to loosen a nut using a socket from the wrong measurement system. You know, I've got a metric nut, but an English socket set. So I find a socket that's close, but it's loose, and inevitably I end up stripping the nut, bruising my knuckles, and generally using language I don't care to repeat. To paraphrase an old saw - the only thing worse than no standard is two standards.

Web services often feels equally bruising, to my brain, if not to my knuckles (although I tend to bruise them hitting something in frustration too). Whoever said, "The wonderful thing about standards is there are so many of them" was certainly familiar with Web services.

In this issue we focus on standards and interoperability. Although I rant and rave, things are better now than they were initially. Most SOAP implementations will now work with one another, and the WS-I has released the first version of the Basic Profile, which will assist everyone. I remember one of our earliest proposals concerned workarounds to make different Web services implementations actually work together. We've come a long way.

But that doesn't mean we're out of the woods by any means. As usual, there is a problem. Or rather, there are multiple problems. Most of them involve standards. The first problem is that there are too many standards bodies. Between the W3C and OASIS, it's a cinch you can make your marketing point by proposing some standard and seeing which place it sticks. Then the poor WS-I gets to figure out how to make it work with all the other various overlapping standards. It doesn't help that some of these bodies will actually accept multiple standards for the same thing - it's bad enough the two bodies have a competition going, but to have one body running multiple standards for the same idea is really dumb.

Fortunately for the most part the basics are now working. But the battle around the next set of standards - security, business process, and management - is still sizzling. It looks like the business process specification is solidifying under BPEL4WS, but the various orchestration and choreography specifications and their subspecifications are still up in the air. Security is stuck with the split personality of SAML and WS-Security, and management is a mess.

What we need at this point is a grass-roots movement to limit the number of standards and focus adoption on a single standard - effectively short-circuiting the whole argument. This would allow us, the consumers, to effectively accelerate the development of Web services by starving out unworthy standards. Much like a consortium uses its buying power to arrange better pricing.

So, I hereby propose the establishment of the WSSSC - the Web Services Standards Selection Committee. The WSSSC will not propose new standards - we'll leave that to OASIS and W3C. Nor will we try to make them work together; we'll leave that to the WS-I. Our sole purpose will be to sort standards into meaningful categories, and to pick the one that we think best suits the needs of the industry. Once we make a selection, we'll be bound to use only that standard.

Of course, we'll need offices, computers, and such. Send your contributions, starting at $10,000 addressed to me, care of the magazine office. Once we reach $1 million, I will get everything rolling...

But seriously, we do need to pressure the industry to stop the insanity. Too many bodies, too many standards. Options are good, to a point, but the automobile only really got started when Henry Ford said "You can have any color you like, as long as it's black." Time for a little black paint in the Web services soul. Oh, and any contributions I do receive will be used for a new socket set with both English and metric.

About Sean Rhody
Sean Rhody is the founding-editor (1999) and editor-in-chief of SOA World Magazine. He is a respected industry expert on SOA and Web Services and a consultant with a leading consulting services company. Most recently, Sean served as the tech chair of SOA World Conference & Expo 2007 East.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

The article states that "Security is stuck with the split personality of SAML and WS-Security" - this is not so. SAML is a standard for exchanging security information, while WS-Security defines a standard representation of security information within a SOAP header. WS-Security does not compete with SAML; rather, it incorporates the use of SAML assertions as one of the multiple security tokens it supports.

And it's amazing how quickly these standards are created. I "wonder" if many of these standards happen to specify the exact mechanism some vendor has already done or will most easily work with the products they already offer...

SOAP started off quite simple, but it's gotten extremely ugly quickly. The WS-I has only helped in that they've said most of the "nifty" features tacked onto SOAP aren't to be used because they create the interoperability problems.

We'll continue to suffer with these problems as long as we allow people to create standards before they're proven in the field. The RFC process is much better in that people can PROPOSE all sorts of standards, but before they become a standard, there need to be implementations that prove it's really worthwhile.

Unfortunately, we're following the OSI model into oblivion.


Your Feedback
Joseph M. Chiusano wrote: The article states that "Security is stuck with the split personality of SAML and WS-Security" - this is not so. SAML is a standard for exchanging security information, while WS-Security defines a standard representation of security information within a SOAP header. WS-Security does not compete with SAML; rather, it incorporates the use of SAML assertions as one of the multiple security tokens it supports.
David wrote: And it's amazing how quickly these standards are created. I "wonder" if many of these standards happen to specify the exact mechanism some vendor has already done or will most easily work with the products they already offer... SOAP started off quite simple, but it's gotten extremely ugly quickly. The WS-I has only helped in that they've said most of the "nifty" features tacked onto SOAP aren't to be used because they create the interoperability problems. We'll continue to suffer with these problems as long as we allow people to create standards before they're proven in the field. The RFC process is much better in that people can PROPOSE all sorts of standards, but before they become a standard, there need to be implementations that prove it's really worthwhile. Unfortunately, we're following the OSI model into oblivion.
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021

SYS-CON Featured Whitepapers
ADS BY GOOGLE