axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dittmann Werner <werner.dittm...@siemens.com>
Subject AW: [Axis2] Proposal - DOM Implementation for Axis2
Date Wed, 18 May 2005 09:01:40 GMT
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: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