axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Murphy <jmur...@mindreef.com>
Subject Re: XmlBeans and Axis? [Re: Doc/Literal support in axis
Date Wed, 17 Mar 2004 22:22:57 GMT
Anderson Jonathan wrote:
> 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.

I don't get why this is a problem.  Say I have a handler that wants to 
transform a request in some way (decrypt, remove a Header whatever). 
Isn't that just consuming one stream and producing another?  If it wants 
to consume one stream map that to Java using some marshaling/binding 
mechanism to operate on then generate the result stream based on that 
why would it matter?


> 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.

I can see that.  So if WSS4J is in the chain I'll end up with a DOM. 
Seems like I should still be able to bind that DOM to Java in any way I 
choose.

Why wouldn't a very thin Axis working with several Java 
binding/marshaling layers be a compelling approach?

Jim Murphy
Mindreef, Inc.

Mime
View raw message