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.
