This discussion has been very useful. Thank you!doc/lit actually increases interop. The problem with rpc/enc is that it's basically a simple-minded version of data binding to XML designed to be language agnostic. Because it's language agnostic it has to stick to simple data structures, and even then it runs into problems. See some of Steve Loughran's discussions of interoperability issues for examples.
Jim Murphy of MindReef/SOAPScope said:
What that means to me is that SOAP is the ... tags that allow service
designers to put application stuff in one bucket (soap:Body) and keep
that separate from non-functional stuff that goes in Headers.
I agreed. But while I like the idea of SOAP headers, I don't have anything standard to put in them. Web services security is a debacle; there's still no standard tag for me to put authentication tokens in a SOAP header. And cleverer stuff like WS-Routing hasn't gone anywhere.
My other problem with the document view is that we lose the interop. It was a magic moment for me when I could declare (in Java) a server function that returned a struct with an array of structs with complex nested data, and then a client (in Perl, .NET, whatever) could just parse it and return the data to the programmer in meaningful client data objects. I've seen this actually work, in practice, for thousands of client programmers.
With doc/lit you're no longer defining data structures, you're defining XML structures. This means you lose the automatic conversion to and from SOAP - but as I said, this has never worked all that well once you get beyond the demo stage anyway. Instead you can apply any tool that suits your platform to convert between XML and your own application data objects.
XML Schema *doesn't* have arrays (thankfully) because arrays are a programming language construct. What Schema has is <xs:element minOccurs="0" maxOccurs="unbounded"> to say that a particular component can be repeated any number of times. You may want to turn that into an array for your processing (or an ArrayList, or a TreeSet, ... or just add all the repeated items together to come up with some sort of total).I guess in theory XML Schema is enough for the clients to do the magic parsing, but in practice it doesn't seem to work so well. I love this clarification to WS-I BP1.0a: http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0-errata-1.htm
R2110, R2111, R2112, and R2113 restricts array descriptions. This is
confusing and untestable as the concept of "array" is alien to XML
Schema
So, um, if XML Schema doesn't have arrays, how am I supposed to pass an array in a document/literal service?
I personally have a lot of issues with Schema, as I said in an earlier post. Regardless of the technique used to specify the XML, though (and right now Schema is the only choice), doc/lit is definitely the way to go for interoperability.
I'm ranting a bit here, I'm sure in practice things work better thanWith doc/lit there are no interop issues as such. One problem with current implementations is that they're basically taking an rpc/enc framework and building a doc/lit facade on top of it. This is the approach used in JAX-RPC 1.1 and now being implemented in Axis. Its best feature is that it's automatic (when and if it works) and you don't need to write a schema for your data. Its worst feature is that it's automatic and doesn't give you any isolation between the XML representation and your data objects.
the picture looks in the abstract. Only when I write web services code
I usually find the picture is *worse* in practice as I sweat through
the minutae of interop in a dozen different languages.
Long term it's clear that real data binding support needs to be integrated into the SOAP framework. JAX-RPC 2.0 has the stated intention of doing this using JAXB 2.0. Right now you can kind of do this with Castor in Axis, if you're willing to go through enough trouble (I've just spent 3 days getting an Axis-Castor example to work properly, as opposed to less than a day using the hideously complex JAX-RPC RI for doc/lit, less than a day with Axis rpc/enc (even though I had to try three different versions of Axis to find one that worked), and less than a day with Axis doc/lit (again requiring trying three different versions of Axis before finding a - different - one that worked). The current Castor in Axis support is basically just grafted in, to, so you pay a high price in performance.
- Dennis
Dennis M. Sosnoski Enterprise Java, XML, and Web Services Training and Development Support http://www.sosnoski.com Redmond, WA 425.885.7197
