Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <200505190221.j4J2LDHU081766@squid.cmb.ac.lk>
From: "Eran Chinthaka" <chinthaka@opensource.lk>
To: <axis-dev@ws.apache.org>
Subject: Re: [Axis2] Proposal - DOM Implementation for Axis2
Date: Thu, 19 May 2005 08:14:15 +0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
thread-index: AcVbiWczzAqLvdrNR9avecy7+EKNGQAOPH/QABWEvYA=


Hi Werner and all,

Please see my comments below.

>=20
> Hi,
>=20
> having two trees implies that both trees need to be in
> sync, at least if it comes to WS.
>=20
> Pls consider the use cases for WS:
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
> Regards,
> Werner
>=20
> > -----Urspr=FCngliche 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
> >
>=20