axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eran Chinthaka" <chinth...@opensource.lk>
Subject Re: [Axis2] Proposal - DOM Implementation for Axis2
Date Thu, 19 May 2005 02:14:15 GMT


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:ruchith.fernando@gmail.com]
> > Gesendet: Mittwoch, 18. Mai 2005 10:05
> > An: axis-dev@ws.apache.org; 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 <vreddyp@gmail.com> 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 <sanjiva@opensource.lk> 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
> >
> 




Mime
View raw message