Experiences with SOAP

March 2002

For the record, we are using the MS SOAP 2.0SP2 toolkit on the Server (backend) and GLUE 1.2 as the client.

GLUE works very well. I did initially find a bug in its support for sending byte arrays using Base64-encoded data (an interop problem where MS SOAP followed an ambiguous portion of the SOAP spec better than GLUE), but the author of GLUE fixed the problem in the next release after I reported it to him. I also had a problem doing anything useful with xsd:anyType, which maps to java.lang.Object. I haven't pursued this, since our design doesn't require xsd:anyType. A colleague is using GLUE to provide a Web service, and it has worked very well for him, though his method calls are far fewer -- and much less complex -- than mine. GLUE can also create Java stub code from WSDL or create WSDL from java classes.

Apache SOAP (not Apache Axis, which is newer) was not very useful as a client. There was a huge amount of work involved in getting it to make/receive calls, though it did seem to work well enough on the few I tried. Apache Axis was in early alpha stage when I was choosing libraries, so I have no experience with it.

MS SOAP Toolkit 2.0SP2, which is the latest version (as of last month), seems to be a bit behind. Here are some of the problems I found with it:

Crashes whenever it receives a SOAP message that is greater than ~ 600KB in size.
Does not support SOAP attachments. Combined with the above limitation, you must be very creative in finding a way to transfer a binary file.
Does not handle return type of String[] very well. It's possible to map this from SOAP to COM, but not at all easy. It can take String arrays as method parameters easily enough, and can even handle complex types with properties defined as String[], but just doesn't handle String[] retvals very well. We generally worked around this by returning a simple String of XML that represented the information that would have been present in the String array.
Can generate WSDL from a VB (or C++) class, but cannot generate the WSDL portions relating to complex types (the XSD). These must be done by hand. It also cannot handle importing existing XSD into the WSDL, so you really do have to do it by hand. Or write some perl scripts to do this for you, as we have done. This makes life very hard for the developer, since hacking WSDL by hand is error-prone (and must be done whenever an interface changes).

Items #2 and #4 are promised to be fixed in MS SOAP Toolkit 3.0, which was due out last Summer (but is still not available). I'm not sure about #1 and #3.

Perhaps the tools are much better in Visual Studio.NET (I haven't used it, so I can't say). Say what you like about Microsoft, but you must admit that their development tools are *generally* easy to use. But, frankly, I was surprised at how much more advanced GLUE was than the MS SOAP toolkit. Even after some extensive Google and MSDN searches, I wasn't able to find even one other tool for COM that was able to automatically generate WSDL (and vice versa).

In case you were wanting to try your hand at building some SOAP clients, you should have a look at www.xmethods.net . This site lists several dozen free SOAP services on the Internet that you can call (for toy applications), like getting the temperature in a given ZIP code or getting the current price at bn.com for some book (given its ISBN). Many of the services has WSDL documents and some of them have sample clients for different languages so you can see how they work.