The flap surrounding Web Services is really heating up with Microsoft on one side and Sun's Liberty Alliance on the other. With so many CEOs shouting, it's hard to know which way is up. With that in mind, our own Lori MacVittie has put together a quick analysis based on her experience in developing Web apps.
Who owns Web Services, Anyway?
by Lori MacVittie
After spending a long few days writing and deploying Web services so I could test a new product release of a Web services load generation/functionality verification tool, I'm ready to have a fit.
Apache SOAP has some issues. While it's got a decent base of deployment at this point, there are some quirks that make it a hassle to get Microsoft-SOAP-toolkit-based products/services to interact with the default deployment of a Java-based Apache SOAP service. You can overcome them, if you know where to look, but it ain't pretty. And because most testing tools are still Microsoft based, you can understand why I'm a bit disgruntled with my experience.
And now, a larger question on the specifications. Scott McNealy accused Microsoft of hijacking XML during his JavaOne Keynote. While that's not entirely true (and, of course, Microsoft and its loyal followers will deny this), I'm baffled by a few key points.
1. Microsoft was VERY involved in the development of both the SOAP 1.1 and the WSDL 1.1 specifications (which are not expected to become recommendations; SOAP 1.2 and WSDL 1.2 are, but not until next year). Note the extensive Microsoft personnel on the authors list. Among them, as of January or February 2002, is Don Box, formerly of DevelopMentor.
2. The default message format for SOAP is RPC/encoded. "One of the design goals of SOAP is to encapsulate and exchange RPC calls using the extensibility and flexibility of XML. This section defines a uniform representation of remote procedure calls and responses" -- from the W3C SOAP 1.1 Specification.
3. The Microsoft .NET default message format is document/literal.
4. Most Java-toolkit-based SOAP implementations (like Apache SOAP) don't support the document/literal message format. Only a few other toolkits -- IONA, Microsoft, PocketSOAP -- support the doc/literal msg format.
Now, if Microsoft was very heavily involved in SOAP's development (the company didn't author it, but it was instrumental), why would it default to something else? Industry watcher, XMethods lists a large number of Web services available for public consumption, indicating that Microsoft .NET implementations universally use DOC message format, while all others use RPC format. Sure, Microsoft supports RPC, but it defaults to DOC. You have to understand the difference to interoperate with non-Microsoft clients.
The breakdown:
- Microsoft .NET 72
- Microsoft SOAP 7
- Apache SOAP 18
- Other RPC 60 (A large number of Delphi implementations exist. Go Borland! I mean Inprise, I mean Borland....)
The big difference here is that .NET is DOC and Microsoft SOAP is RPC. A huge difference exists in client accessibility, but because the default is to do .NET, this gets really ugly, really fast.
Now, granted, Apache SOAP isn't the most robust toolkit available, nor does it appear there are plans to make it "the" solution. It's not all bad news, though. XMethods maintains a lengthy list of Web services on which are listed more RPC-based implementations (GLUE, Delphi and BEA) than Microsoft .NET.
If you aren't aware of this discontinuity between .NET and others and if you write/generate a client, you aren't going to get very far.
