axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject [Axis2] detecting need for DOM ... [Re: [Axis2] Proposal - DOM Implementation for Axis2
Date Tue, 17 May 2005 17:06:21 GMT
Eran Chinthaka wrote:

>  
>
>>hi,
>>
>>doesn't it mean that XML will be parsed twice or events replayed
>>(PullParser pp = messageContext.getSOAPEnvelope().getPullParser())  and
>>original OM tree that was first built is then discarded (first built by
>>StAXSOAPModelBuilder but without DOM then again by StAXSOAPModelBuilder
>>but with DOM)?
>>
>>i think there is a better solution: if it is detected that that one of
>>modules/handlers requires DOM (described in its metadtaa) then why not
>>to use builder/factory that will produce OM classes that implement DOM
>>interfaces from beginning?
>>    
>>
>
>Yeah, this is the nice picture we like to see, which may not be the actual
>picture.
>
>We create the builder within the transport. So do u want to expect the
>transport to find the correct builder and assign ?  
>  
>
yes if possible - just by knowing path (servlet/service/SecureFoo) you 
know quite a bit ..

if not possible to determine it then at later stage XML tree must be 
rebuilt - but that should be the last resort

>And take this example. We know that there is a service in our Axis Server,
>which security is optional. Meaning messages may come with or without
>encrypted. So when a message comes to the service how can the transport
>know, whether the message is encrypted or not. If he knows that, yes we have
>the nice cute picture u mentioned ;).
>  
>
i think in this case having factory to build OM with DOM is still 
preferable to having rebuilding DOM tree - DOM impact should be 
primarily memory if you use only OM interfaces

>So that's the reason behind us treating the message as a usual one
>initially, and if the domain specific handler, like wsse handler, detects
>what to do he can follow the proposal put forward by Ruchith.
>  
>
i think it is very serious flaw in your design that will have very 
negative impact on AXIS2 memory usage and performance - hopefully it is 
not going to be come as problematic as AXIS1 switching between DOM, 
SAAJ, and SAX event stream when in worst case it reparsed input for each 
representation (hmm i start to forget details and maybe that is good 
sign that i no longer remember that ...)

best,

alek

>
>>Ruchith Fernando 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
>>>
>>>
>>>
>>>      
>>>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>
>>    
>>
>
>
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message