axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: [Axis2] Proposal - DOM Implementation for Axis2
Date Wed, 18 May 2005 03:00:51 GMT
I spent a bit of time with Raul of xml-security. does not look likely.
Note that SUNW has 3 people working in xml-security too now.

-- dims

On 5/17/05, Glen Daniels <glen@thoughtcraft.com> wrote:
> 
> Is it possible to implement xml-sec without DOM?  In other words, would it be possible
/ a good idea to build an eventual
> Axis-specific WSS implementation on top of OM directly?  I understand we'd lose the use
of standard libraries, but I'm wondering
> what the performance gain might be.
> 
> --G
> 
> > -----Original Message-----
> > From: Dittmann Werner [mailto:werner.dittmann@siemens.com]
> > Sent: Tuesday, May 17, 2005 2:26 AM
> > To: 'axis-dev@ws.apache.org'; dims@apache.org
> > Subject: AW: [Axis2] Proposal - DOM Implementation for Axis2
> >
> > Ruchith, Dims,
> >
> > first of all: I'm not familiar with the enw Axis 2 OM structure
> > and mechanisms. However, just jumping in here to get a better
> > understanding and the impacts for WS-Security.
> >
> > What are the impacts of the following quote for the security handlers:
> >
> > "As long as the OM structure is preserved for the following
> > handlers to
> > work on (e.g: after security), there will be no problems at all."
> >
> > I like to point out that the security mechanisms need the complete,
> > fully serialized SOAP request (or response) as a DOM XML document to
> > work correctly. The security functions then add new elements, modify
> > existing elements, delete/replace exisiting elements of that document.
> > This is not only true for the WSS4J functions but also for the
> > underlying Apache xml-sec library. The security handler then replaces
> > the original SOAP request with the "security enhanced" document. In
> > addition its is important to know that the security enhanced doc shall
> > not be modified afterwards (e.g. new serialization of the doc) because
> > this may destroy signatures. The Axis WS handlers use Axis methods
> > to ensure that (or JAX-RPC methods in case of the JAX-RPC handler)
> >
> > Said all this I'm a little concerned about the above statement. The
> > security handler cannot preserve the OM structuture as far as I can
> > see.
> >
> > Regards,
> > Werner
> >
> > > -----Urspr√ľngliche Nachricht-----
> > > Von: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > > Gesendet: Montag, 16. Mai 2005 21:23
> > > An: dims@apache.org
> > > Cc: axis-dev@ws.apache.org
> > > Betreff: Re: [Axis2] Proposal - DOM Implementation for Axis2
> > >
> > >
> > > Hi Dims,
> > >
> > > I think the SAAJ implementation can be used once we finalize the
> > > implementation of few places such as
> > > org.apache.axis.saaj.SOAPDocumentImpl (creation of the new DOM
> > > Elements is missing in here).
> > >
> > > As long as the OM structure is preserved for the following
> > handlers to
> > > work on (e.g: after security), there will be no problems at all.
> > >
> > > 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 :-)
> > >
> > > Thanks,
> > > Ruchith
> > >
> > >
> > > On 5/16/05, Davanum Srinivas <davanum@gmail.com> wrote:
> > > > Ruchith,
> > > >
> > > > Did you consider using the SAAJ stuff which already has dom
> > > interfaces?
> > > >
> > > > -- dims
> > > >
> > > > On 5/16/05, Ruchith Fernando <ruchith.fernando@gmail.com> wrote:
> > > > > Hi All,
> > > > >
> > > > > In implementing WS-Security capabilities on Axis 2.0 we
> > > will have to
> > > > > convert the OM to DOM and provide the complete
> > > SOAPEnvelope as a DOM
> > > > > implementation.
> > > > > The following changes and additions are proposed to the OM
> > > > > implementation to support this.
> > > > >
> > > > > 1.) The org.w3c.dom.* interfaces will be implemented
> > > extending the OM
> > > > > Impls. (org.apache.axis.dom.*)
> > > > > Also there will be an implementation of org.apache.axis.soap.*
> > > > > interfaces extending from the DOMImpls.
> > > (org.apache.axis.dom.soap.*)
> > > > > In this situation we will have to change some of the
> > > method names in
> > > > > the OM interfaces. E.g.: getNextSibling,
> > > getPreviousSibling in OMNode
> > > > >
> > > > > 2.) A DOMSOAPFactory implementing the SOAPFactory will be
> > > introduced
> > > > > to provide the DOM_SOAP impls. to the StAXSOAPModelBuilder
> > > > >
> > > > > 3.) How to switch the builder when the security related
> > > handlers takes over:
> > > > >
> > > > > Since the security handlers depend on the DOM interfaces,
> > > they  cannot
> > > > > work with pure OM instances. They expect DOM impls. So
> > > now there's a
> > > > > need to switch from normal OM factory to DOM factory. Therefore
> > > > > following method is proposed to to handle this.
> > > > >
> > > > > There will be some processing of the SOAPEnvelope before
> > > it reaches
> > > > > the security handlers.
> > > > > And there will be a reference to this partially built
> > > SOAPEnvelope in
> > > > > the MessageContext object. This SOAPEnvelope consists
> > > only of pure OM
> > > > > based elements (org.apache.axis.soap.*). Now we get the
> > > pull parser
> > > > > from the SOAPEvelope we have through the OMStAXWrapper
> > > (This is used
> > > > > to get the pull events from OMElements, irrespectiveof
> > their build
> > > > > state)
> > > > >
> > > > > PullParser pp = messageContext.getSOAPEnvelope().getPullParser()
> > > > > //Returns a pp pointing to the start of the document
> > > > >
> > > > > Then we create a new StAXSOAPModelBuilder passing the
> > > DOMSOAPFactory
> > > > > together with the pull parser returned from the SOAPEnvelope.
> > > > >
> > > > > StAXSOAPModelBuilder builder = new
> > > StAXSOAPModelBuilder(pp, new DOMFactory())
> > > > >
> > > > > At this point the SOAPEnvelope reference in the message
> > context is
> > > > > pointing to the older pure OM based SOAPEnvelope.
> > > > > This will have to reassigned to the new OM+DOM based
> > > SOAPEnvelope, as
> > > > > shown below:
> > > > >
> > > > > messageContext.setEnvelope(builder.getDocumentElement());
> > > // This will
> > > > > set the reference to the new DOMSOAPEnvelopeImpl
> > > > >
> > > > > Therefore to achieve this we need to have remember the
> > > following point
> > > > > as a best practise : DON'T POINT TO THE SOAP ENVELOPE OF
> > > A MESSAGE,
> > > > > JUST POINT TO THE MESSAGE_CONTEXT ONLY.
> > > > >
> > > > > I think this is one of the best use cases which shows the
> > > beauty of
> > > > > the Factory and Builder concept used in Axis2 - OM design :)
> > > > >
> > > > > Thanks,
> > > > > Ruchith
> > > > >
> > > >
> > > > --
> > > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > > >
> > >
> >
> >
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Mime
View raw message