axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: Doc/Literal support in axis
Date Wed, 17 Mar 2004 06:05:10 GMT
Nelson Minar wrote:

>This discussion has been very useful. Thank you!
>
>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.
>
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.

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.

>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?
>
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 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 than
>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.
>  
>
With 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.

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


Mime
View raw message