"My 3 Web Service Stacks"

Back in the old days when my friends and I used and taught others to use COM, Chris came up with a great way to present the essential choice you had to make when you set out to create a component. He called it “My 3 COMs”.

First, there was script COM, which used only VARIANTs and the 13 types you could put in them. Then there was VB COM, which used simple data types, basic structures, SAFEARRAYs and BSTRs. Finally, there was C++ COM, which used all sorts of fancy data types including open arrays that specified their conformance and variance on the fly.

The point Chris was making was that you created a COM class, your choice of data type determined who could use your component. In other words, your choice affected how far your code could reach. There will be a similar split in the Web services world, hence the title of this post. This time though the spin will be a little different. It won't focus on data format so much (it's all just XML), but on behavior. To wit, “My 3 Web Service Stacks“:

First, there is basic SOAP over HTTP described with WSDL and XSD. It hits a sweet spot for developers who want tools to hide XML details but is still simple enough to implement everywhere. Then there is WS-*, which offers richer functionality but is harder to implement and will not be supported by all products, especially legacy systems. Finally, there are toolkit specific features like BEA's idiom for async messaging over HTTP using a header to convey a callback URL, Iona's Artix support for a CORBA binding, or Microsoft's Indigo support for binary messaging.

In this world, your choice of feature will decide how far you can reach: to everyone, to everyone using WS-* enabled tools and infrastructure, or only to others using the same toolkit you are.

This is not inherently a bad thing. As long as everyone supports a common underlying base, having vendors compete with one another to add interesting features is good. Hopefully the best of them will be picked up by others (IP allowing) and become more common. However, it would be a bad thing if people who think they're building something open and far-reaching inadvertantly use a feature that limits their reach to others who are using the same tool.

So as we go forward into the WS future, we really need to do two things. First, service developers have to make a concious choice about how far they want their service to reach and use only the features that work at that range. Second, vendors need to make it clear to developers which features will restrict reach so that they don't accidentaly make a mistake.