axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Performance Comparison
Date Thu, 29 Apr 2010 22:23:46 GMT
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.
* 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
>
>

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


Mime
View raw message