Hi, having two trees implies that both trees need to be in sync, at least if it comes to WS.
Pls consider the use cases for WS: Client: on the client side the WS handler _shall_ be the _last_ handler in a handler chain, because at that point the handler can access all elements that may be sign/encrypted. As noted before the WS handler in this case modifies the existing request DOM to bring in the security elements. Server: On the server side the WS handler _shall_ be the _first_ handler of a handler chain. It is necessary to perform any security actions before the request is processed by any other part. It also makes sense to decrypt first before any further processing is done. Also in this case the request DOM is modified before it is handed back to Axis. Thus if you have two trees they must be prefectly synchronized if processing performed _after_ the security handler relies on the OM tree (e.g. serializing into XML on the client side, further handlers on the server side). Of course the other way around is also true (OM tree is modified, some other part later in the processing chain needs DOM). How does it work today: The current implementation of Axis serializes (AFAIK) the current request into a DOM tree if a DOM tree is requested, thus the WSS4J actually works on a DOM copy of the SOAP request. This serialization forces Axis to completely setup the request, fill in all references, perform attachment processing (references to attachments in the body), etc. This is necssary because the body may be encrypted by WSS4J. WSS4J may perform a large amount of modifications on that DOM tree. After that WSS4J serializes this DOM tree into the real output format (the XML document) and sets teh resulting byte stream as new current message in the SOAP Part. This is currently the only way to prevent Axis from serialize the "security enhanced" DOM tree again and to prossibly destroy signatures. Again, after security processing with WSS functions the SOAP request (XML data) shall not be modified (or can be modified because parts of the request may be ancrypted). Regards, Werner > -----Urspr�ngliche Nachricht----- > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 18. Mai 2005 10:05 > An: [email protected]; Venkat Reddy > Betreff: Re: [Axis2] Proposal - DOM Implementation for Axis2 > > > Hi, > > But won't the current SAAJ impl have a DOM tree and an OM tree at a > given instance. If a complete DOM strcture is not available then we > are in trouble when it comes to security stuff. And if the OM tree is > not reserved as well then the following handlers are in trouble. > > I think even though the SOAPEnvelopeImpl does not contain references > to SOAPBodyImpl and SOAPHeaderImpl we will still have the DOM tree > when those instances are created. In other words I think even though > it doesn't create a parallel SOAP tree it still create the DOM tree. > > E.g.: getHeader() in org.apache.axis.saaj.SOAPEnvelopeImpl creates a > NEW SOAPHeaderImpl instance and returns it. And this is the object > that is used to get the corresponding DOM element for the header > element in in the sec impl. > > IMO as long as you don't have a DOM implementation extending from the > OM impl you will have two trees. > > Regards > Ruchith > On 5/17/05, Venkat Reddy <[EMAIL PROTECTED]> wrote: > > The current SAAJ Impl does NOT create a parellel tree. It just > > delegates much of the work to the embedded OM objects. For example, > > SOAPEnvelopeImpl does NOT contain references to SOAPBodyImpl and > > SOAPHeaderImpl, but has one private instance variable of type > > org.apache.axis.om.SOAPEnvelope. Same strategy is followed for other > > clasess as well.Sanjiva, can you give more detial on the factory > > technique usage here. > > > > Also SAAJ impl allows conversion between OM and SAAJ version of SOAP > > objects (SOAPEnvelope, SOAPBody etc). > > > > Ashutosh will post more details on the current SAAJ implementation. > > > > - venkat > > > > > > On 5/17/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > > On Mon, 2005-05-16 at 19:22 +0000, Ruchith Fernando wrote: > > > > With the proposed solution I think we can get away from > having two > > > > object strctures (OM and DOM) at the same time. But I > think I can try > > > > to go ahead with what is there is in SAAJ impl without much of a > > > > problem :-) > > > > > > Wait, does the current SAAJ impl basically create a > parallel tree?? If > > > so I'm against doing it that way .. the clever factory > technique allows > > > us to not have two trees around and is hence preferable. > The SAAJ impl > > > should extend that to add SAAJ support (thru the same technique). > > > > > > Sanjiva. > > > > > > > > > > > -- > Ruchith Fernando > www.ruchith.org >
