MS SOAP SDK vs. IBM/Apache XML-SOAP: An Update

The saying that everything moves quickly in the software industry certainly applies to SOAP, a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. In the short period of time since my original article comparing the Microsoft SOAP Toolkit and the IBM SOAP For Java SDK was published, both projects have evolved into much better and, I'm happy to say, more compatible tools.

IBM scored points with their donation of the SOAP For Java code to the Apache Software Foundation, which is now called Apache SOAP. The open source community quickly embraced the project and has been working nonstop on bug fixes, enhancements, and new functionality. IBM also released two new SOAP tools through their Alphaworks site that build on the original SOAP For Java codebase: the NASSL Toolkit and the Web Services Toolkit for Java.

At the same time, the Microsoft development team also spent the month-and-a-half following the original release of their toolkit fixing bugs, refining code, and adding features that made the toolkit ready for production use. As a primary tester of the new functionality, I have firsthand knowledge of how hard the team has worked.

But how do the two implementations compare now? Following is an update in which I use the same criteria that I used in my original article. I'll also write about some of the cool new features that each implementation offers and drop some hints about the future.

The Contenders

• Apache XML-SOAP Version 2.0
• Microsoft SOAP Toolkit For Visual Studio (Build 205)

SOAP Version 1.1 Conformance

In my previous review I failed to notice several compliance related bugs in the Apache code, but most of these have been addressed. Most egregious was the fact that the only namespace prefix that the code would accept was "SOAP-ENV." While this is more of an XML encoding bug than a SOAP conformance issue, it still caused some major problems, especially in the area of interop with other valid SOAP implementations (the Microsoft toolkit for example, which uses the prefix "SOAP," without the "-ENV" keyword appended at the end).

Perhaps one of the most annoying issues that currently exists with the Apache code is its insistence on the explicit declaration of element XSI data types (All parameters in a SOAP RPC message call must be tagged with an xsi:type attribute or the call is rejected.). This is an optional requirement in the SOAP specification. Because the Apache code does not use an external data typing mechanism (e.g. Microsoft's SDL), the code doesn't know how to properly translate the incoming request into its native data type representation, thus the requirement for explicit typing in of the request. This is, in my opinion, too restrictive and should be fixed (As I'll explain later, this is also the last issue standing in the way of full interoperability between the Apache and Microsoft tools.).

As I already noted, the Microsoft development team has worked hard to fix many of the compliance issues that plagued the first release of the toolkit, but some remain. Nothing major, but it's good to be aware of them. First, SOAP Headers are still not completely supported. For example, you can't set the mustUnderstand and actor attributes. Second, the toolkit generates improperly formatted SOAP Fault codes, and, in some cases, no SOAP fault codes are generated at all when a fault occurs. I'll spare you the details for now, but if you're using the MS Toolkit's ASP-based listener, you need to make sure that you're familiar with the error handling model that ASP uses in order to work around the issues accordingly.

Ease Of Use

Installing the Microsoft SOAP Toolkit is much easier now that it has been wrapped into a Microsoft Installer Package: Just double-click on the executable and off you go (Just be sure you're installing the toolkit on a Windows NT machine with the latest MSXML parser installed.). Hint to the Microsoft development team: I'd still like to see a web-based utility for deploying services.

The Apache code really hasn't improved in ease-of-use since version 1, though I should admit that I've been biased against the whole CLASSPATH thing. Since I use Windows 2000 most of the time, I've gotten around this problem by adding the Apache SOAP classes to my Java trustlib folder. However, it's still a pain.

Apache has made progress in improving the flexibility of their tool, including enhanced support for sending one-way SOAP messages as opposed to RPC-style messages that always return a response. Also, a lot of work has gone into abstracting the SOAP functionality from the transport protocol layer, allowing developers to use the SOAP tools across nearly any protocol stack.

The Microsoft toolkit is also more flexible than before. The Proxy component now allows greater access to the underlying SOAP Envelope, and the HTTP-based WireTransfer Object supports multiple ports and host headers.

Debugging has become an easier task with both implementations. I've never had a major problem with the Apache code, and problems that I do encounter are usually related to improperly set CLASSPATHs. Nevertheless, the bug fixes made to the Apache code over the last month have been necessary and are greatly appreciated.

I'd like to thank the Microsoft development team for all their work. The end result is a vast improvement over the previous release. While some issues regarding full SOAP Version 1.1 compliance remain (primarily support for headers and arrays), I've been assured that most of them will be addressed in future releases of the toolkit. (The team is shooting for a one month release cycle, so look for the next release sometime before mid-September. Despite these issues the Microsoft toolkit is, in my opinion, finally ready for a production environment.

Compatibility

Of course, a number of issues persist. For example, Apache tools require all RPC parameters to be explicitly typed within the SOAP envelope while the Microsoft tools don't support this feature at all (not even optionally). While the greatest fault is with Apache (optional features should be optional, not required), I think that the Microsoft team should consider enabling this feature in their tools as well (optional features should be optional, not denied altogether).

New Directions

For Microsoft, SOAP is more than just a passing fancy or "useful tool." SOAP is a bedrock feature of their new .NET Framework and is woven into that framework in ways that leave no doubt that the new protocol is fundamental to its long term plans.

To read more about how SOAP is implemented in Microsoft's .NET Framework, you can download the .NET SDK.

IBM's release of two SOAP-based applications, the NASSL Toolkit and the Web Services Toolkit, contribute a lot to the development of the Apache XML-SOAP project. The NASSL Toolkit is a simple tool that automatically generates and executes SOAP For Java requests based on type information specified in a NASSL document. The Web Services Toolkit is a development and deployment architecture for web-based application services based on any protocol (including SOAP) and represents the next step in the java-based SOAP development cycle. More on this in a future article.

What's Coming

Conclusion