Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4BDE58FB.9030708@sosnoski.com>
Date: Mon, 03 May 2010 17:02:51 +1200
From: Dennis Sosnoski <dms@sosnoski.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090822)
MIME-Version: 1.0
To: Andreas Veithen <andreas.veithen@gmail.com>
CC: java-dev@axis.apache.org, commons-dev@ws.apache.org,
        Amila Suriarachchi <amilasuriarachchi@gmail.com>,
        wss4j-dev@ws.apache.org
Subject: Re: Performance Comparison
References: <y2n1e8c1ed41004281554hd28bda8p70093dc691c1c4e4@mail.gmail.com>
 	<s2yb67458761004291523rcba59b76qfae738a300019561@mail.gmail.com>
 	<o2s60708f4b1004300123pa53bb104s9dd2e2243b1ac140@mail.gmail.com>
 	<201004300727.50854.dkulp@apache.org> <4BDBD45D.9030506@sosnoski.com>
 <AANLkTik7dFefEG7DIBoTj2VUN7eMXgGS3aEdQ9xnTRs_@mail.gmail.com>
In-Reply-To: <AANLkTik7dFefEG7DIBoTj2VUN7eMXgGS3aEdQ9xnTRs_@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Andreas Veithen wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dms@sosnoski.com> wrote:
>   
>> ...
>>     
>
> Each of the two approaches (porting WSS4J to Axiom / building a new
> optimized Axiom+DOM implementation) have their pros and cons and I
> think there is enough room for the two. They could even be
> complementary provided that the new Axiom+DOM implementation has a
> lower memory footprint and better performance.
>
>   
>> As a radical suggestion, how about just implementing a build-on-demand DOM
>> subset suitable for use by WSS4J and other tools? This wouldn't need to
>> support all the DOM operations (including those using NodeList).
>>     
>
> That part is actually almost ready [1] (with more than just a subset
> suitable for WSS4J). However, to work with Axis2 we have no other
> choice than to support the Axiom API as well, at least the object
> model part of it (while getting rid of what you called the "mess").
>
> [1] http://code.google.com/p/ddom/
>   

Well, I suspect most people who've looked into the Axiom code and tried 
to follow the spaghetti paths involved in building the nodes would agree 
with the "mess" characterization. :-)  This is not to say that the code 
is necessarily poorly written, either - it's just a very complex process 
to try to build a DOM incrementally, as the Axiom developers have found.

Your DDOM project looks like an interesting 2nd-generation take on 
Axiom, and as such it should definitely represent a major improvement. 
After thinking it over and seeing how deferred building is actually 
applied with web services, though, I wonder if a simpler approach 
wouldn't be better.

On the inbound side it's pretty easy to implement deferred building, 
since all the current-generation web services stacks use pull parsing. 
If you need to build a DOM, you just use the pull parser to do so and 
supply a pull parser facade for reading data back out of the DOM, and 
all the rest of the code just works with the pull parser. The outbound 
side is more difficult. ADB implements a StAX reader for pulling data 
out of data bound objects, but other data bindings such as JiBX and JAXB 
do not. This means that if you want to build a DOM for any portion of 
the bound data you pretty much need to do the whole thing, since these 
data bindings use push output.

But that's actually not such a drawback, since it corresponds with the 
way WS-* uses the data in the document - if you need a DOM 
representation for *any* of the data in the SOAP Body, you probably need 
it for *all* the data. It doesn't have to be that way, but in practice, 
how often do you see WS-Security, for instance, applied to only a 
portion of the SOAP Body?

So rather than an incremental build-on-demand model, I think an approach 
which just flipped DOM on or off at the message level would work just as 
well for web services. On the inbound side, if a SOAP Header is present 
you'd just always build a DOM representation of the Header part so it 
can be passed to handlers in an easily-manipulated form. If any of the 
handlers request the content of the SOAP Body you'd then build that as a 
DOM and pass it in. Outbound side is pretty much the same, with the data 
only requested from the data binding if needed to build the DOM and 
otherwise streamed directly to the output. Using this approach there's 
no need to build the DOM incrementally, other than at this very granular 
Header/Body level, so all that's required is a simple and 
high-performance DOM (or DOM subset) with just enough built-in smarts to 
recognize the Body expansion part, along with a StAX reader which takes 
a DOM as input.

  - Dennis

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org