Programmers who have been around the block at least once have usually been burned by sudden twists and turns of the software biz. Those who put their faith and confidence in IBM felt the OS/2 rug suddenly jerked out from beneath them. Novell Netware became Novell Nowhere in just a few years.

Microsoft is only a little less guilty of this kind of thing since they have had a tendency to drop things in beta rather than suffering defeat and retreat at the hands of their competitors ... so far. But there were a lot of software shops who invested in Blackbird and ended up eating crow. (Blackbird was a non-HTML version of Internet Studio. It dropped out of the sky like a dead bird when it became clear that the web would win. But Microsoft's energetic promises that they would stand by their ISV's no matter what earned them a lot of hard feelings from developers caught holding a bag of feathers.)

So you might be excused for wondering if the future of web services is really as bright as it seems right now. And, even if you're convinced that web services is, in fact, the name of the future, it's wise to look at what the major players - Microsoft, IBM, Oracle and Sun - are doing and what differences exist in their approach to web services.

The confusion over just what it is can be seen by scanning the definitions available. Some are so broad as to be almost meaningless. One site, for example, defines it as "Automated resources accessed via the Internet." Others narrow it down to, "Application services ... based on XML messaging." A definition as specific as that rules out lots of applications that are running now. The "official" standards body, the W3C, is still "debating" a complete and correct definition as 2004 has dawned, but the main page of their "Web Services Activity" group has this very simple description in the first paragraph.

"The World Wide Web is more and more used for application to application communication. The programmatic interfaces made available are referred to as Web services."

Unfortunately, because the web services technology is both new (new uses and methods pop up almost daily) and quite technical (different implementations use quite different terms and techniques), a really good definition has to be messy and full of words to be even close to accurate. I dreamed up this one:

Software that runs over a network and provides information services based on XML standards that are accessed through a URI (Universal Resource Identifier) address and an XML defined information interface. The standard XML technologies normally used in web services include SOAP, WSDL, UDDI and XSD.

Why will Web Services work?

The first reason can be seen in the definitions presented so far: Standard XML Technologies. OS/2 was IBM's attempt to lock up the operating system. Novell did have networking locked up. And if Blackbird had worked, it would have been a victory for Microsoft proprietary technology. (The jury is still out on Windows ... this remains the most serious proprietary threat to programmers. See this article for more.) All of the acronyms mentioned above have been hammered out and agreed to by all of the major players.

Web services is remarkably open - especially considering the software sins of the past. As just one example, just last September in New York, Bill Gates shared the stage for the first time in 12 years with an IBM executive (Steve Mills, Senior VP and head of IBM's software business) to run a demo showing Microsoft and IBM interoperability using - you guessed it - web services. A joint demo with Sun may take a few more years. As it turns out, Sun was hosting a competing convention at exactly the same time but on the opposite side of the US.

Critical decisions that all of these companies have made to support XML as the interoperability standard are what is behind all of this interoperability. Each company has concluded that it's better to have a piece of a big pie than all of a very small one. So we can confidently expect that information interoperability will be assured for some time to come in web services.

That is not to say that everything will work all the time on any platform. Far from it, all of these companies are all still plotting to make sure that you are keenly aware of their 'unique' advantages in web services.

But support for the 'base' standards is, in general, excellent. Take support for the XML DTD (Document Type Definition) as an example. All you have to do is read the W3C standard or the IBM XML tutorials (registration required) to realize that XML does have historic technology roots that it is dragging around with it such as the DTD. Microsoft has decided that DTD's make no sense and has miminal support for them. Instead, they rely on XML Schema (which might be an excellent architecture choice). You can read about the difference here and you can read about the XML technologies that Microsoft does encourage here. In spite of this, Microsoft's mainline XML parser MSXML 4.0, will validate against a DTD if one is present. Although Microsoft only whispers "DTD" softly while the other vendors put it right up front, nobody wants to have the label "standard breaker" branded on them.

The difference will emerge in what is sometimes called the "extend and embrace" strategy. VB .NET shows off this difference in exceptional style. While it will take some work and extra code to implement web services in VB 6, it's almost totally automatic in VB .NET. If you have VB .NET and IIS installed, try this experiment:

• Create a new project in VB .NET using the ASP .NET Web Service template.
• Remove the comments from the generated "Hello World" code created automatically
• Press F5 to run the service.
• Click the "Invoke" button to run the generated client.
• See the results in XML!

Remember, this creates both a client and a server that interact in a networked way (even if it is one that is internal to your computer) in a complete web service application! Could it have been any easier?

Now peek 'under the covers'! If you check out the web application that has been installed on your IIS server using the MMS IIS console (Start > Run > mmc %systemroot%\system32\inetsrv\iis.msc), you see a considerable amount of code has been created. This is code that you know nothing about unless you make the commitment to learn. And unless you learn it, you really don't have much of a chance of building a system that will work across the technical borders of different companies. In a way, VB .NET makes web services a little too easy!

IBM VP Steve Mills, in an interview after his historic demo with Bill Gates with Microsoft Watch (a really good source of industry insight, by the way) was extraordinarily honest about exactly how these things could be expected to work out.

Microsoft Watch: "... do you think there's a danger that Microsoft might say "OK, we've done our part and now we're going our own way"?"

Mills: "... I'm already doing those things today. I've got 48 different industry-branded versions of WebSphere ... So we're already into all this industry-vertical stuff, big-time, from a middleware-enabling standpoint. I expect them to do the same. ... So I'm not really concerned about what they're trying to do. It's sort of expected."

Mills is right! What he's really saying is that cross-platform compatibility isn't his job. His job is to sell you IBM products. And Gate's job is to sell you Microsoft products. Just as voters in a democracy get th="' vernment they deserve, so customers in an open market get the software architecture they deserve. If you end up locked into a proprietary web services architecture and you have to dance to just one vendor's tune, get a mirror and look at the person responsible. (Or -- perhaps, loan a mirror to your company management.)