One of the ingrained attitudes in the United States is the desire to simplify choices to a binary decision. Black or white. Coffee or tea. Winner or loser. Even our expressions reflect this ­ "two-horse race," "two-party system." And it's no different in the world of Web services. On the one hand, we have the entire world of Microsoft's .NET initiative. On the other hand we have the many-headed beast known as Java. Java or .NET. Seems simple enough.

But like most simplifications, this one is not entirely accurate, and in fact ignores an entire gamut of choices that exist, and are valid. If Web services was the political system, these choices would be the Independents, the Ross Perot Party.

The simplification that is made with Web services is that in order to do Web services, you need to pick an overall architecture. Naturally, Microsoft, Sun, IBM, and BEA would love for you to continue in this line of thinking because it sells product for them, and not just in Web services.

Not that an architecture platform isn't important. Without it, your chances of ever doing anything meaningful are pretty limited. But most of the time, you have already selected your architecture. And it may or may not match the platform that the two big camps may want you to use.

And that's part of the problem with Web services ­ we tend to define it as a platform, and assume the installation of a particular platform in order to actually implement Web services.

But that's a fallacy. In reality. Web services exists as a separate entity, distinct from these platform choices, although perhaps intimately tied to platforms. If we look closely at the Web services stack (stay tuned for a poster from WSJ illustrating this for our devoted readers) we can see that at its most basic, Web services consists of UDDI, WSDL, and XML (and possibly, probably SOAP). Now, excluding SOAP for the moment, all of these protocols are neutral to the platform. That's not to say that one or another doesn't run better on a particular platform, or that in your architecture it doesn't belong on a particular platform ­ of course it does. But what it does say is that the choice is up to you, not to Microsoft, BEA, IBM, or anyone else. You get to choose where UDDI runs within your company. You get to choose where WSDL resides. You get to set your XML schema, and even with SOAP, you still have more than a single option.

The reality, of course, is that there are more options. Companies like Sonic, Tibco, Cape Clear, and Kenamea, to name a few, present a third alternative ­ the Agnostic Approach. These companies take the road that says there's nothing wrong with selecting J2EE or .NET ­ but there's nothing sacred about them either. And if you think about it, what good would Web services be if we were only able to use them with Java and Windows. For Pete's sake ­ the biggest advantage to Web services is that we can wrap CICS and COBOL/Fortran/PL1/whatever on a mainframe and let it look like any other Web service.

Now, my background is clear ­ remember that I used to edit Java Developer's Journal, and before that PowerBuilder Developer's Journal. I'm clearly a PC kind of guy, so don't think that WSJ is turning into some IBM 390 magazine. But at the same time, isn't it something special to be able to include all those platforms? Isn't it about time we were able to create a solution that included the mainframe, UNIX platforms, Windows, and Macs? I think so. I think that in reality, that's what Web services is all about.

In other countries, one of the options when voting is "None of the Above" ­ a refusal to select any of the major candidates. While .NET and J2EE are certainly strong options, we need that third choice ­ None of the Above.