Talking about the current SAAJ implementation, it is just a wrapper over OM and not any parallel tree. Basically, all the SAAJ classes have a private data member defined which is the corresponding OM object, and most of the methods delegate work to the corresponding methods in OM.
As far as implementation of DOM API is concerned, the SAAJ SOAPElement and Node interfaces extend DOM Element and DOM Node interfaces, so we are providing full implementation of these two interfaces, but they will delegate work to OM as and when possible. Also, SOAPPart needs DOM Document implementation, so we will provide that as well. Is there anything else Security will need? Also, Sanjiva, currently we are not taking OM->DOM->SAAJ path, but if Element and Node implementation is all that is required, we can use SOAPElement and Node as well. Ashutosh -----Original Message----- From: Ruchith Fernando [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 17, 2005 1:13 PM To: Venkat Reddy Cc: [email protected]; [EMAIL PROTECTED] Subject: Re: [Axis2] Proposal - DOM Implementation for Axis2 HI Venkat, WSS4J impl and especially XML-Security impl are based on DOM. For example there are a instances in both impls where the DOM Document object is used to create elements using the createElement and createElementNS methods. IMHO we cannot change this behaviour and expect XML-Sec and to work on SOAPHeader and SOAPBody. Also the core of WSS4J org.apache.ws.security.* stuff uses only DOM. Therefore I guess we will have make sure SOAPDocumentImpl provides those methods, so we can use XML-Sec and WSS4J without a problem :-), What do u think? Best regards, Ruchith On 5/17/05, Venkat Reddy <[EMAIL PROTECTED]> wrote: > Ruchith, > > We should be able to use the SAAJ implementation for DOM support. I > dont think we need a separate set of classes to implement DOM. Ashu > and Jaya are completing the implemntation for SAAJ and test cases. > > SOAPDocumentImpl is provided as part of implementing SOAPPart for > attachements. I'm not sure you will need it for dealing with the > children inside a header or body. For example, you should be able to > access and manipulate the children inside a SOAPHeader or SOAPBody, > using just the SAAJ API, without the need to go for SOAPDocumentImpl. > > -- venkat > > > On 5/17/05, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > > 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 <[EMAIL PROTECTED]> wrote: > > > Ruchith, > > > > > > Did you consider using the SAAJ stuff which already has dom interfaces? > > > > > > -- dims > > > > > > On 5/16/05, Ruchith Fernando <[EMAIL PROTECTED]> 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/ > > > > > >
