axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Suriarachchi <amilasuriarach...@gmail.com>
Subject Re: Performance Comparison
Date Fri, 30 Apr 2010 08:23:26 GMT
On Fri, Apr 30, 2010 at 3:53 AM, Andreas Veithen
<andreas.veithen@gmail.com>wrote:

> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ruchith.fernando@gmail.com> wrote:
> > This overhead is mainly due to OM<->DOM conversion that was
> > unavoidable because we used WSS4J (which uses Apache XML-Sec) which is
> > based on DOM.
> >
> > This following effort by Saliya et al. is a project where they tried
> > to implement those base libraries based on OM:
> > http://wssecforaxis2.blogspot.com/
> >
> > They were able to produce very good perf numbers.
> >
> > Maybe it is time to consider rewriting C14N, XML-Sig, XML-Enc on AXIOM?
>
> That is one option. The other is to develop an object model that
> implements the Axiom API and DOM at the same time. Of course, this is
> exactly what DOOM promised to do, but realistically speaking, that was
> a failure, because it is neither a complete implementation of the
> Axiom API nor a complete implementation of DOM. The fact is that it is
> not able to support Axis2 (because of the missing support for
> OMSourcedElement and other reasons) and its DOM implementation is just
> enough to support some selected frameworks.
>
> Some of the reasons why DOOM is a failure are structural/architectural:
> * DOM is document-centric, while the Axiom API is factory-centric.
> DOOM never provided a smart answer to that problem.
> * The code in the DOOM classes mixes different aspects: implementing
> the Axiom API, implementing the DOM API and managing the data
> structures necessary to store the XML/SOAP infoset. This makes the
> code very complex and difficult to maintain. The problem is worsened
> by the fact that it is not possible to come up with an object oriented
> design (class hierarchy) that properly models the XML infoset model
> and at the same time supports the Axiom and DOM APIs in a natural way.
> * ...
>
> It is clear that an approach that attempts to optimize WS-Security
> processing by using an Axiom+DOM implementation will never be able to
> leverage all the features provided by Axiom (and thus not be able to
> match the performance of a native WS-Security implementation), but it
> is nevertheless a very attractive one:
> * No need to rewrite WSS4J and related libraries. This is an obvious
> advantage because WSS4J is very stable and well tested.
> * If one includes the SAAJ object model into the scope of the project,
> one could get rid of the code in axis2-saaj that relies on the (in
> this context) very inefficient proxy pattern.
> * Parts of the JAX-WS API also rely on DOM and/or SAAJ (handlers,
> provider endpoints, dispatchers). Having an Axiom+DOM implementation
> would allow us to avoid conversions here as well.
> * Last but not least, it would make the Axiom project more attractive
> (to end users and other projects) because it would become possible to
> leverage the Axiom features (deferred parsing, streaming, sourced
> elements, etc.) without the need to adopt a non-standard API. For
> example, the WSS4J integration in CXF uses the SAAJ reference
> implementation; while the CXF project would definitely not be
> interested in Axiom as an object model, it may be interested in the
> deferred parsing feature, provided that Axiom has good support for
> DOM/SAAJ.
>

I think DOM Api can not support differed building. And that is why it has
used a different API without implementing the DOM API.

For an example OMElement returns an iterator when getting children and xml
parsing can be done when user calls getNext. But DOM elements returns a
NodeList. When this node list returns whole set of children has to be read.

thanks,
Amila.


> * Building a new implementation of the Axiom API could be an
> opportunity to get rid of some of the performance issues in Axiom as
> well and to optimize its memory footprint.
>
> I've been working on such an implementation over the last few months,
> but it's currently still in a "research" stage. It's a valid
> proof-of-concept of some of these ideas, but there are still many
> important aspects missing. If there is interest, I can provide more
> information.
>
> Andreas
>
> > Thanks,
> > Ruchith
> >
> >
> > On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ssanka@gmail.com>
> wrote:
> >> Perhaps we may want to do some performance tuning[1] before the
> >> release of Axis2 version 1.6
> >>
> >> Sanka
> >>
> >> [1]
> http://www.ibm.com/developerworks/webservices/library/j-jws14/index.html?ca=drs
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >>
> >
> >
> >
> > --
> > http://ruchith.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> > For additional commands, e-mail: java-dev-help@axis.apache.org
> >
> >
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Mime
View raw message