Hi Werner and all,
Please see my comments below. > > 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. A small clarification. Can the WSA handler work before security. Meaning, I "think" WSA handlers will not be encrypted, if I understood the WSA spec correct. So WSA handler may run before the security handler. Please correct me if I'm wrong. -- Chinthaka > 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 > > >
