axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject processing layers ... Re: XmlBeans and Axis? [Re: Doc/Literal support in axis
Date Wed, 17 Mar 2004 21:46:08 GMT
Anderson Jonathan wrote:

>The only problem with decoupling the SOAP processing layer from the Java
>data binding layer is the implications such an approach has on "intermediary
>node" processing.  Almost every SOAP stack I've seen implements "SOAP
>intermediary nodes" as some sort of interceptor (Axis handlers, JAX-RPC
>handlers, .Net WSE filters, Glue filters).
hi Jon,

i agree. and that is the reason why one need to be careful about choice 
of intermediary representation of messages passed in pipeline.

>The problems is that intermediary nodes can change the content of the SOAP
>envelope, plain and simple.  This really complicates that SOAP XML data
>binding issue.  Intermediary node implementations need access to the SOAP
>header information at the very least...  any type of security processing
>(Web Services Security XML Signatures or XML Encryption, for example)
>requires access to the entire envelope, typically as a DOM.
this all is fine and can be made to work with flexible use of XML 
Infoset (based on my experience) until you get to the last part: the 
requirement of DOM - DOM3 may finally provide mechanisms for 
customizations so that may be how this will be done in future (still 
making DOM even more complicated ...)

>Case in point: the WSS4J Axis handlers HAVE to marshall/unmarshall to DOM
>Level 2, given that the WSS4J XML-Security toolkit of choice (Apache
>XML-Security) operates on DOM Document instances.  This flies in the face of
>Axis' SAX based data binding approach.
why, o why, there is no SOAP:Footer to allow signatures be computed in 
streaming fashion?

>Seems to me that a) intermediary nodes are very significant when you're
>dealing with the SOAP processing model and b) they could potentially have
>their own unique data binding requirements in addition to the data binding
>approach the actual service implementation uses.
yes. that is why you want to pass around XML Infoset based documents 
representing SOAP messages (DOM or something more lightweight). it seems 
that streaming is lost cause and trying to make SOAP/XML streaming was 
not considered important enough to guarantee any support in all WS* 
standards. i can say this based on my lost battle to maintain streaming 
in XSOAP (or how i started to love document/literal approach ...) i gave 
up on streaming and by making everything document based implementing all 
kind of WS-* became much easier.

still i think about possibility of doing a lazy XML infoset tree that 
would allow to bypass tree creation and access XML stream for not yet 
parsed parts of XML stream (XmlPullNode is proof of concept of such 
approach in XPP2).

>I'm very anxious to see how the JAX-RPC 2.0 JAXB 2.0 marriage handles this
we will see :) however based on decisions such as to make SAAJ require 
DOM i would not put my hopes too high ...

anyway i do not think that it matters that much. we should not forget 
that XML and SOAP is about what goes on the wire and how this gets 
produced is of secondary importance IMHO ...



>-----Original Message-----
>From: Jim Murphy []
>Sent: Wednesday, March 17, 2004 2:21 PM
>Subject: Re: XmlBeans and Axis? [Re: Doc/Literal support in axis
>I favor the approach this suggests:
>Make the SOAP stack an XML delivery and minimal SOAP processing engine
>and leave XML<->Java type translation to another layer.  Chose Castor,
>XmlBeans, JAXB 1.0, 2.0 whatever.  The choice is dictated by how I want
>to work witht he XML recognizing that the XML is really what I'm working
>Jim Murphy
>Mindreef, Inc.
>Aleksander Slominski wrote:
>>Dennis Sosnoski wrote:
>>>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.
>>do you know if anybody tried to add support for XmlBeans
>>( to AXIS?
>>we have XmlBeans integrated in WS/XSUL (aka XSOAP4) which is document
>>style based in its core so it needs some kind of data binding. XmlBeans
>>works very well in this capacity as it has a very extensive support for
>>XML Schemas (AFAIK there is nothing open source that has better support

The best way to predict the future is to invent it - Alan Kay

View raw message