ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject Re: Performance Comparison
Date Mon, 03 May 2010 10:48:08 GMT
On Mon, May 3, 2010 at 10:19, Amila Suriarachchi
<> wrote:
> Is (or was) there any reason to Axiom to come up with an new API rather than
> using DOM API?

I guess that one of the goals was also to provide an API that is more
convenient than DOM.

> I was thinking that Dom does not support differed building and that seems to
> be wrong.

It is possible to do deferred parsing/building with DOM, but one needs
to write the code carefully (e.g. to avoid using the NodeList
interface to iterate over the children of a node). That is probably
another reason for choosing an entirely different API; indeed the
Axiom API more or less forces you to write your code in such a way
that it doesn't build nodes "accidentally".

> There are some axis2 specific methods to get under line xml stream etc...
> But they would have added by
> extending the DOM API.

It would indeed have been possible to build Axiom by extending the DOM
API, but that is actually not so straightforward as it seems. That for
example DOM's Node#getFirstChild method. That method returns a
reference of type org.w3c.dom.Node. So either you need to add a new
method with the extended interface as return type, or the caller needs
to cast the return value to that extended interface. The first
approach would pretty much result in something that looks like
Axiom+DOM (DOOM), the second approach would have been simpler for
Axiom but less convenient for Axis2 (or any other code using Axiom).

> thanks,
> Amila.
> On Mon, May 3, 2010 at 12:50 PM, Dennis Sosnoski <> wrote:
>> Whoops, meant to have this in my first response...
>> Andreas Veithen 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.
>> I can't really see much of a pro in porting WSS4J to Axiom. This would
>> mean either forking the code, with the associated maintenance issues, or
>> deliberately choosing to lower WSS4J's performance with other applications
>> just so that Axis2 improves (and creating an Axiom dependency for everyone
>> else using WSS4J).
>> Implementing a DOM interface usable by WSS4J on top of a modified Axiom
>> seems like a better choice, so that Axis2 can avoid unnecessary conversions
>> and boost its performance without hurting other users of WSS4J. Or instead
>> using a simpler version of build-on-demand than that implemented by Axiom,
>> as discussed in the earlier reply.
>>  - Dennis
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message