Platforms

The two major platforms for developing Web services are Sun's J2EE and Microsoft's .Net. On paper, there isn't much to separate the two technologies insofar as they both offer similar features in terms of a component model, data access, rich runtime environment, broad library support, and of course the all-important Web services aspects.

Microsoft .Net

Perhaps the biggest single differentiator of the .Net approach is that everything is supplied by a single vendor and has thus been honed to work together harmoniously, and that same vendor has provided some of the most sophisticated tool support on the market to make working with the .Net framework a pleasant and productive experience.

This ease-of-use is carried forward to the Web services features, ASP.Net, where to expose a piece of functionality to the network (including the automatic production of WSDL and handling of SOAP messages) is simplicity itself, requiring only a single line of code per operation. This ease-of-use does not, however, mean that the platform handles only simple cases; in fact the truth is far from it. The ASP.Net features allow advanced developers to handcraft the way in which SOAP messages are handled, and there is rich support for other useful technologies like XSLT and DOM.

J2EE

In stark contrast to the single-vendor approach of the .Net framework, the J2EE standard is maintained by a single body (Sun) supported by a plethora of vendors such as IBM, BEA, and Oracle. In theory, this means that developing Web services on J2EE-based application servers opens up a wealth of choice and allows true mix-and-match component based solutions to be built. In practice, however, things are not always quite so straightforward since each vendor supports its own set of conventions for aspects like component deployment and configuration, while they can still remain faithful to the J2EE standard. Furthermore, not all platforms ship with useful features like XSLT processing components, DOM, or in some cases even a SOAP stack.

However, if we consider Web services level in isolation from the rest of the J2EE stack, things are significantly better. In particular, the open-source AXIS toolkit from the Apache group is a firm favorite for building Java-based Web services since it has kept apace with the feature list of the best of breed Web service platforms, including ASP.Net and WASP server (Systinet). Furthermore, since AXIS has partial support for JAXM and JAXRPC interfaces, code written to use AXIS can be ported to other Java Web services platform with a minimum of effort.

A Single Web Services Platform?

There is one certainty in the battle between the platforms: There is no certain winner. Regardless of what statistics the Java and Microsoft camps can roll out and, irrespective of the views of platform zealots, both platforms will exist in the future Web services landscape (in addition to a plethora of other "niche" platforms).

For your own part, remember that Web services are simply user interfaces for computers. Just as we wouldn't necessarily decide on a particular platform just because it makes writing GUIs easier, the same is true in the Web services arena. Your choice of platform will be made based on the constraints of existing infrastructure and the needs of the project as a whole, not just the Web services aspects.

The only way to be sure that you will have full coverage is to learn the key APIs on both platforms. While this might sound like a lot of additional work, experience shows that it is not the hard work is in understanding the underlying protocols and not in the APIs while the number of API calls needed to get up and running on both platforms is relatively small.