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).
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.
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.
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.
I'm very anxious to see how the JAX-RPC 2.0 JAXB 2.0 marriage handles this
problem.
-Jon
-----Original Message-----
From: Jim Murphy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 2:21 PM
To: [EMAIL PROTECTED]
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
with!
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.
>
>
> hi,
>
> do you know if anybody tried to add support for XmlBeans
> (http://xml.apache.org/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
> ...).
>
> thanks,
>
> alek
>
