Performance Comparison

[Sanka Samaranayake <ss...@gmail.com>]

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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Thu, Apr 29, 2010 at 6:23 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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.

DOOM is certainly missing a lot of features. The reason it did not
completely implement DOM (especially DOM 3 APIs) was that, at the time
we developed it, we just wanted  this API to be minimal such that it
supported the barely minimum required to use WSS4j + XML-Sec. This was
practical at that time.

>
> 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.

Any suggestions? Because the DOOM API would be required to support
both behaviors.

> * 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.

Would this new implementation still require us to build the complete
DOM tree in memory when we sign and encrypt content (through WSS4J +
XML-Sec)? If so, wouldn't this lead us to the same issues that we face
now?

Thanks,
Ruchith

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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Thu, Apr 29, 2010 at 6:23 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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.

DOOM is certainly missing a lot of features. The reason it did not
completely implement DOM (especially DOM 3 APIs) was that, at the time
we developed it, we just wanted  this API to be minimal such that it
supported the barely minimum required to use WSS4j + XML-Sec. This was
practical at that time.

>
> 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.

Any suggestions? Because the DOOM API would be required to support
both behaviors.

> * 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.

Would this new implementation still require us to build the complete
DOM tree in memory when we sign and encrypt content (through WSS4J +
XML-Sec)? If so, wouldn't this lead us to the same issues that we face
now?

Thanks,
Ruchith

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 03:31, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 03 May 2010 3:20:36 am 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).
>
> Just to extend this a bit further (or make it more generic), change this to:
>
> I can't really see much of a pro in porting <insert favorite XML processing
> library here> to Axiom. This would mean either forking the code, with the
> associated maintenance issues, or deliberately choosing to lower <insert
> favorite XML processing library here>'s performance with other applications
> just so that Axis2 improves (and creating an Axiom dependency for everyone
> else using <insert favorite XML processing library here>).

If you add "unless the port would leverage capabilities of Axiom that
are not available in DOM" to the first sentence, then I fully agree.
If the only purpose of the port is to get around limitations in Axiom
then it would definitely make more sense to invest the time into the
improvement of Axiom. Even if there is a need to use Axiom specific
features, there is a possibility to use those features while still
keeping the DOM API, simply by having something like an abstract
DOMUtil class with two implementations (one for standard DOM and one
that contains implementations optimized for Axiom). I don't know much
about the project of Saliya et al., so I don't know if it makes sense
to do a fork in that particular case.

> Seriously, I really don't think the problem is limited to WSS4J.  It really
> would apply to any library that does some sort of DOM based XML processing.
> Things like XSLT engines, XPath things, etc...   Should ALL of them be forked
> to have Axiom versions?   I personally think that's nuts.   Let the security
> folks do security things.  Let the XSLT folks do XSLT things. Etc...   Let the
> Axiom folks concentrate on Axiom things.

+1. That is exactly the reason why I started to play around with some
new stuff that may become later the starting point of Axiom 2.0.

> Standard API's are good for a reason.   I would be good if the standard API's
> can be made to be fast.   That's my opinion.
>
> Dan
>
>
>
>>
>> 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 03:31, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 03 May 2010 3:20:36 am 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).
>
> Just to extend this a bit further (or make it more generic), change this to:
>
> I can't really see much of a pro in porting <insert favorite XML processing
> library here> to Axiom. This would mean either forking the code, with the
> associated maintenance issues, or deliberately choosing to lower <insert
> favorite XML processing library here>'s performance with other applications
> just so that Axis2 improves (and creating an Axiom dependency for everyone
> else using <insert favorite XML processing library here>).

If you add "unless the port would leverage capabilities of Axiom that
are not available in DOM" to the first sentence, then I fully agree.
If the only purpose of the port is to get around limitations in Axiom
then it would definitely make more sense to invest the time into the
improvement of Axiom. Even if there is a need to use Axiom specific
features, there is a possibility to use those features while still
keeping the DOM API, simply by having something like an abstract
DOMUtil class with two implementations (one for standard DOM and one
that contains implementations optimized for Axiom). I don't know much
about the project of Saliya et al., so I don't know if it makes sense
to do a fork in that particular case.

> Seriously, I really don't think the problem is limited to WSS4J.  It really
> would apply to any library that does some sort of DOM based XML processing.
> Things like XSLT engines, XPath things, etc...   Should ALL of them be forked
> to have Axiom versions?   I personally think that's nuts.   Let the security
> folks do security things.  Let the XSLT folks do XSLT things. Etc...   Let the
> Axiom folks concentrate on Axiom things.

+1. That is exactly the reason why I started to play around with some
new stuff that may become later the starting point of Axiom 2.0.

> Standard API's are good for a reason.   I would be good if the standard API's
> can be made to be fast.   That's my opinion.
>
> Dan
>
>
>
>>
>> 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 03:31, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 03 May 2010 3:20:36 am 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).
>
> Just to extend this a bit further (or make it more generic), change this to:
>
> I can't really see much of a pro in porting <insert favorite XML processing
> library here> to Axiom. This would mean either forking the code, with the
> associated maintenance issues, or deliberately choosing to lower <insert
> favorite XML processing library here>'s performance with other applications
> just so that Axis2 improves (and creating an Axiom dependency for everyone
> else using <insert favorite XML processing library here>).

If you add "unless the port would leverage capabilities of Axiom that
are not available in DOM" to the first sentence, then I fully agree.
If the only purpose of the port is to get around limitations in Axiom
then it would definitely make more sense to invest the time into the
improvement of Axiom. Even if there is a need to use Axiom specific
features, there is a possibility to use those features while still
keeping the DOM API, simply by having something like an abstract
DOMUtil class with two implementations (one for standard DOM and one
that contains implementations optimized for Axiom). I don't know much
about the project of Saliya et al., so I don't know if it makes sense
to do a fork in that particular case.

> Seriously, I really don't think the problem is limited to WSS4J.  It really
> would apply to any library that does some sort of DOM based XML processing.
> Things like XSLT engines, XPath things, etc...   Should ALL of them be forked
> to have Axiom versions?   I personally think that's nuts.   Let the security
> folks do security things.  Let the XSLT folks do XSLT things. Etc...   Let the
> Axiom folks concentrate on Axiom things.

+1. That is exactly the reason why I started to play around with some
new stuff that may become later the starting point of Axiom 2.0.

> Standard API's are good for a reason.   I would be good if the standard API's
> can be made to be fast.   That's my opinion.
>
> Dan
>
>
>
>>
>> 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 03:31, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 03 May 2010 3:20:36 am 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).
>
> Just to extend this a bit further (or make it more generic), change this to:
>
> I can't really see much of a pro in porting <insert favorite XML processing
> library here> to Axiom. This would mean either forking the code, with the
> associated maintenance issues, or deliberately choosing to lower <insert
> favorite XML processing library here>'s performance with other applications
> just so that Axis2 improves (and creating an Axiom dependency for everyone
> else using <insert favorite XML processing library here>).

If you add "unless the port would leverage capabilities of Axiom that
are not available in DOM" to the first sentence, then I fully agree.
If the only purpose of the port is to get around limitations in Axiom
then it would definitely make more sense to invest the time into the
improvement of Axiom. Even if there is a need to use Axiom specific
features, there is a possibility to use those features while still
keeping the DOM API, simply by having something like an abstract
DOMUtil class with two implementations (one for standard DOM and one
that contains implementations optimized for Axiom). I don't know much
about the project of Saliya et al., so I don't know if it makes sense
to do a fork in that particular case.

> Seriously, I really don't think the problem is limited to WSS4J.  It really
> would apply to any library that does some sort of DOM based XML processing.
> Things like XSLT engines, XPath things, etc...   Should ALL of them be forked
> to have Axiom versions?   I personally think that's nuts.   Let the security
> folks do security things.  Let the XSLT folks do XSLT things. Etc...   Let the
> Axiom folks concentrate on Axiom things.

+1. That is exactly the reason why I started to play around with some
new stuff that may become later the starting point of Axiom 2.0.

> Standard API's are good for a reason.   I would be good if the standard API's
> can be made to be fast.   That's my opinion.
>
> Dan
>
>
>
>>
>> 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 03:31, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 03 May 2010 3:20:36 am 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).
>
> Just to extend this a bit further (or make it more generic), change this to:
>
> I can't really see much of a pro in porting <insert favorite XML processing
> library here> to Axiom. This would mean either forking the code, with the
> associated maintenance issues, or deliberately choosing to lower <insert
> favorite XML processing library here>'s performance with other applications
> just so that Axis2 improves (and creating an Axiom dependency for everyone
> else using <insert favorite XML processing library here>).

If you add "unless the port would leverage capabilities of Axiom that
are not available in DOM" to the first sentence, then I fully agree.
If the only purpose of the port is to get around limitations in Axiom
then it would definitely make more sense to invest the time into the
improvement of Axiom. Even if there is a need to use Axiom specific
features, there is a possibility to use those features while still
keeping the DOM API, simply by having something like an abstract
DOMUtil class with two implementations (one for standard DOM and one
that contains implementations optimized for Axiom). I don't know much
about the project of Saliya et al., so I don't know if it makes sense
to do a fork in that particular case.

> Seriously, I really don't think the problem is limited to WSS4J.  It really
> would apply to any library that does some sort of DOM based XML processing.
> Things like XSLT engines, XPath things, etc...   Should ALL of them be forked
> to have Axiom versions?   I personally think that's nuts.   Let the security
> folks do security things.  Let the XSLT folks do XSLT things. Etc...   Let the
> Axiom folks concentrate on Axiom things.

+1. That is exactly the reason why I started to play around with some
new stuff that may become later the starting point of Axiom 2.0.

> Standard API's are good for a reason.   I would be good if the standard API's
> can be made to be fast.   That's my opinion.
>
> Dan
>
>
>
>>
>> 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 03:31, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 03 May 2010 3:20:36 am 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).
>
> Just to extend this a bit further (or make it more generic), change this to:
>
> I can't really see much of a pro in porting <insert favorite XML processing
> library here> to Axiom. This would mean either forking the code, with the
> associated maintenance issues, or deliberately choosing to lower <insert
> favorite XML processing library here>'s performance with other applications
> just so that Axis2 improves (and creating an Axiom dependency for everyone
> else using <insert favorite XML processing library here>).

If you add "unless the port would leverage capabilities of Axiom that
are not available in DOM" to the first sentence, then I fully agree.
If the only purpose of the port is to get around limitations in Axiom
then it would definitely make more sense to invest the time into the
improvement of Axiom. Even if there is a need to use Axiom specific
features, there is a possibility to use those features while still
keeping the DOM API, simply by having something like an abstract
DOMUtil class with two implementations (one for standard DOM and one
that contains implementations optimized for Axiom). I don't know much
about the project of Saliya et al., so I don't know if it makes sense
to do a fork in that particular case.

> Seriously, I really don't think the problem is limited to WSS4J.  It really
> would apply to any library that does some sort of DOM based XML processing.
> Things like XSLT engines, XPath things, etc...   Should ALL of them be forked
> to have Axiom versions?   I personally think that's nuts.   Let the security
> folks do security things.  Let the XSLT folks do XSLT things. Etc...   Let the
> Axiom folks concentrate on Axiom things.

+1. That is exactly the reason why I started to play around with some
new stuff that may become later the starting point of Axiom 2.0.

> Standard API's are good for a reason.   I would be good if the standard API's
> can be made to be fast.   That's my opinion.
>
> Dan
>
>
>
>>
>> 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 03:31, Daniel Kulp <dk...@apache.org> wrote:
> On Monday 03 May 2010 3:20:36 am 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).
>
> Just to extend this a bit further (or make it more generic), change this to:
>
> I can't really see much of a pro in porting <insert favorite XML processing
> library here> to Axiom. This would mean either forking the code, with the
> associated maintenance issues, or deliberately choosing to lower <insert
> favorite XML processing library here>'s performance with other applications
> just so that Axis2 improves (and creating an Axiom dependency for everyone
> else using <insert favorite XML processing library here>).

If you add "unless the port would leverage capabilities of Axiom that
are not available in DOM" to the first sentence, then I fully agree.
If the only purpose of the port is to get around limitations in Axiom
then it would definitely make more sense to invest the time into the
improvement of Axiom. Even if there is a need to use Axiom specific
features, there is a possibility to use those features while still
keeping the DOM API, simply by having something like an abstract
DOMUtil class with two implementations (one for standard DOM and one
that contains implementations optimized for Axiom). I don't know much
about the project of Saliya et al., so I don't know if it makes sense
to do a fork in that particular case.

> Seriously, I really don't think the problem is limited to WSS4J.  It really
> would apply to any library that does some sort of DOM based XML processing.
> Things like XSLT engines, XPath things, etc...   Should ALL of them be forked
> to have Axiom versions?   I personally think that's nuts.   Let the security
> folks do security things.  Let the XSLT folks do XSLT things. Etc...   Let the
> Axiom folks concentrate on Axiom things.

+1. That is exactly the reason why I started to play around with some
new stuff that may become later the starting point of Axiom 2.0.

> Standard API's are good for a reason.   I would be good if the standard API's
> can be made to be fast.   That's my opinion.
>
> Dan
>
>
>
>>
>> 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>

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

Re: Performance Comparison

[Daniel Kulp <dk...@apache.org>]

On Monday 03 May 2010 3:20:36 am 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).

Just to extend this a bit further (or make it more generic), change this to:

I can't really see much of a pro in porting <insert favorite XML processing 
library here> to Axiom. This would mean either forking the code, with the 
associated maintenance issues, or deliberately choosing to lower <insert 
favorite XML processing library here>'s performance with other applications 
just so that Axis2 improves (and creating an Axiom dependency for everyone 
else using <insert favorite XML processing library here>).

Seriously, I really don't think the problem is limited to WSS4J.  It really 
would apply to any library that does some sort of DOM based XML processing.   
Things like XSLT engines, XPath things, etc...   Should ALL of them be forked 
to have Axiom versions?   I personally think that's nuts.   Let the security 
folks do security things.  Let the XSLT folks do XSLT things. Etc...   Let the 
Axiom folks concentrate on Axiom things.  

Standard API's are good for a reason.   I would be good if the standard API's 
can be made to be fast.   That's my opinion. 

Dan



> 
> 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

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

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

Re: Performance Comparison

[Daniel Kulp <dk...@apache.org>]

On Monday 03 May 2010 3:20:36 am 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).

Just to extend this a bit further (or make it more generic), change this to:

I can't really see much of a pro in porting <insert favorite XML processing 
library here> to Axiom. This would mean either forking the code, with the 
associated maintenance issues, or deliberately choosing to lower <insert 
favorite XML processing library here>'s performance with other applications 
just so that Axis2 improves (and creating an Axiom dependency for everyone 
else using <insert favorite XML processing library here>).

Seriously, I really don't think the problem is limited to WSS4J.  It really 
would apply to any library that does some sort of DOM based XML processing.   
Things like XSLT engines, XPath things, etc...   Should ALL of them be forked 
to have Axiom versions?   I personally think that's nuts.   Let the security 
folks do security things.  Let the XSLT folks do XSLT things. Etc...   Let the 
Axiom folks concentrate on Axiom things.  

Standard API's are good for a reason.   I would be good if the standard API's 
can be made to be fast.   That's my opinion. 

Dan



> 
> 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

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 10:19, Amila Suriarachchi
<am...@gmail.com> 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 <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/
>

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 10:19, Amila Suriarachchi
<am...@gmail.com> 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 <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 10:19, Amila Suriarachchi
<am...@gmail.com> 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 <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 10:19, Amila Suriarachchi
<am...@gmail.com> 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 <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 10:19, Amila Suriarachchi
<am...@gmail.com> 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 <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 10:19, Amila Suriarachchi
<am...@gmail.com> 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 <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 10:19, Amila Suriarachchi
<am...@gmail.com> 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 <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/
>

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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

Is (or was) there any reason to Axiom to come up with an new API rather than
using DOM API?
I was thinking that Dom does not support differed building and that seems to
be wrong.

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

thanks,
Amila.


On Mon, May 3, 2010 at 12:50 PM, Dennis Sosnoski <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

Is (or was) there any reason to Axiom to come up with an new API rather than
using DOM API?
I was thinking that Dom does not support differed building and that seems to
be wrong.

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

thanks,
Amila.


On Mon, May 3, 2010 at 12:50 PM, Dennis Sosnoski <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

Is (or was) there any reason to Axiom to come up with an new API rather than
using DOM API?
I was thinking that Dom does not support differed building and that seems to
be wrong.

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

thanks,
Amila.


On Mon, May 3, 2010 at 12:50 PM, Dennis Sosnoski <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

Is (or was) there any reason to Axiom to come up with an new API rather than
using DOM API?
I was thinking that Dom does not support differed building and that seems to
be wrong.

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

thanks,
Amila.


On Mon, May 3, 2010 at 12:50 PM, Dennis Sosnoski <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

Is (or was) there any reason to Axiom to come up with an new API rather than
using DOM API?
I was thinking that Dom does not support differed building and that seems to
be wrong.

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

thanks,
Amila.


On Mon, May 3, 2010 at 12:50 PM, Dennis Sosnoski <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

Is (or was) there any reason to Axiom to come up with an new API rather than
using DOM API?
I was thinking that Dom does not support differed building and that seems to
be wrong.

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

thanks,
Amila.


On Mon, May 3, 2010 at 12:50 PM, Dennis Sosnoski <dm...@sosnoski.com> 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: http://amilachinthaka.blogspot.com/

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

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



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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 11:21, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>
>>>
>>> ...
>>>>
>>>>
>>>
>>> The nice thing about using a slightly-hacked and simplified DOM is that
>>> everything would be automatic - as it is with Axiom now, but with
>>> considerably less memory and processor overhead (because this approach
>>> would
>>> *only* defer building the DOM representation of the Body content, and
>>> would
>>> build the entire Body content as a DOM whenever anything within the Body
>>> was
>>> accessed - a lot of the memory and processor overhead of Axiom relates to
>>> the incremental one-element-at-a-time build process). And because it'd
>>> still
>>> implement the DOM interface (or at least a subset suitable for use by
>>> WSS4J)
>>> applications using WSS4J could choose to use this or continue to use any
>>> other DOM they want.
>>>
>>
>> Your statement assumes that the memory/processor overhead in Axiom is
>> caused by the deferred parsing/building support. I don't think that is
>> true. I think the reason is simply the way (the default
>> implementations of) Axiom stores the information. For example, storing
>> the attributes and namespace declarations of an element in hash maps
>> is probably suboptimal. In SOAP messages, the average number of
>> attributes (resp. namespace declarations) on elements having at least
>> one attribute (resp. namespace declaration) is probably less then 2.
>> Therefore the overhead of creating and maintaining a hash map is
>> probably not justified by any gain in access performance.
>>
>
> Yes, I can see that it'd be possible to implement a deferred
> parsing/building approach at the element level without much added memory or
> processing overhead, if done correctly. There can really only be one parser
> in use, for instance, so that can be stored at the document level, and even
> the element currently being expanded could be stored at that level (rather
> than using a flag on the element). But is the flexibility gain from doing
> things this way worth the added complexity, as opposed to my suggestion of a
> tweaked DOM with a special kind of expandable Element used only for the Body
> (well, actually two kinds of expandable Elements, the second to handle MTOM
> attachments)? I don't know.

I think it's worth it, because it solves the problem in a completely
generic way (i.e. without making assumptions about the structure of
the document). Also, Axiom 1.x has successfully proven that it is
perfectly possible to support deferred parsing/building on a
node-per-node basis. Of course there are some pieces in Axiom that are
very complex (see e.g. OMStAXWrapper/SwitchingWrapper class), but I
think that is more related to design questions than to the intrinsic
complexity of the approach used by Axiom. Simply this code has grown
over time and nobody took the time to break it down into more
manageable pieces.

I think that dropping deferred parsing/building on a node-per-node
basis would be a regression. In addition, this may have consequences
for Axis2 and may require changes. I think that instead of rewriting
parts of Axis2 to support a new (and less generic) model it is better
to invest that time into something that preserves the model (but that
may be a bit more complex).

>  - Dennis
>
> ---------------------------------------------------------------------
> 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 11:21, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>
>>>
>>> ...
>>>>
>>>>
>>>
>>> The nice thing about using a slightly-hacked and simplified DOM is that
>>> everything would be automatic - as it is with Axiom now, but with
>>> considerably less memory and processor overhead (because this approach
>>> would
>>> *only* defer building the DOM representation of the Body content, and
>>> would
>>> build the entire Body content as a DOM whenever anything within the Body
>>> was
>>> accessed - a lot of the memory and processor overhead of Axiom relates to
>>> the incremental one-element-at-a-time build process). And because it'd
>>> still
>>> implement the DOM interface (or at least a subset suitable for use by
>>> WSS4J)
>>> applications using WSS4J could choose to use this or continue to use any
>>> other DOM they want.
>>>
>>
>> Your statement assumes that the memory/processor overhead in Axiom is
>> caused by the deferred parsing/building support. I don't think that is
>> true. I think the reason is simply the way (the default
>> implementations of) Axiom stores the information. For example, storing
>> the attributes and namespace declarations of an element in hash maps
>> is probably suboptimal. In SOAP messages, the average number of
>> attributes (resp. namespace declarations) on elements having at least
>> one attribute (resp. namespace declaration) is probably less then 2.
>> Therefore the overhead of creating and maintaining a hash map is
>> probably not justified by any gain in access performance.
>>
>
> Yes, I can see that it'd be possible to implement a deferred
> parsing/building approach at the element level without much added memory or
> processing overhead, if done correctly. There can really only be one parser
> in use, for instance, so that can be stored at the document level, and even
> the element currently being expanded could be stored at that level (rather
> than using a flag on the element). But is the flexibility gain from doing
> things this way worth the added complexity, as opposed to my suggestion of a
> tweaked DOM with a special kind of expandable Element used only for the Body
> (well, actually two kinds of expandable Elements, the second to handle MTOM
> attachments)? I don't know.

I think it's worth it, because it solves the problem in a completely
generic way (i.e. without making assumptions about the structure of
the document). Also, Axiom 1.x has successfully proven that it is
perfectly possible to support deferred parsing/building on a
node-per-node basis. Of course there are some pieces in Axiom that are
very complex (see e.g. OMStAXWrapper/SwitchingWrapper class), but I
think that is more related to design questions than to the intrinsic
complexity of the approach used by Axiom. Simply this code has grown
over time and nobody took the time to break it down into more
manageable pieces.

I think that dropping deferred parsing/building on a node-per-node
basis would be a regression. In addition, this may have consequences
for Axis2 and may require changes. I think that instead of rewriting
parts of Axis2 to support a new (and less generic) model it is better
to invest that time into something that preserves the model (but that
may be a bit more complex).

>  - Dennis
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 11:21, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>
>>>
>>> ...
>>>>
>>>>
>>>
>>> The nice thing about using a slightly-hacked and simplified DOM is that
>>> everything would be automatic - as it is with Axiom now, but with
>>> considerably less memory and processor overhead (because this approach
>>> would
>>> *only* defer building the DOM representation of the Body content, and
>>> would
>>> build the entire Body content as a DOM whenever anything within the Body
>>> was
>>> accessed - a lot of the memory and processor overhead of Axiom relates to
>>> the incremental one-element-at-a-time build process). And because it'd
>>> still
>>> implement the DOM interface (or at least a subset suitable for use by
>>> WSS4J)
>>> applications using WSS4J could choose to use this or continue to use any
>>> other DOM they want.
>>>
>>
>> Your statement assumes that the memory/processor overhead in Axiom is
>> caused by the deferred parsing/building support. I don't think that is
>> true. I think the reason is simply the way (the default
>> implementations of) Axiom stores the information. For example, storing
>> the attributes and namespace declarations of an element in hash maps
>> is probably suboptimal. In SOAP messages, the average number of
>> attributes (resp. namespace declarations) on elements having at least
>> one attribute (resp. namespace declaration) is probably less then 2.
>> Therefore the overhead of creating and maintaining a hash map is
>> probably not justified by any gain in access performance.
>>
>
> Yes, I can see that it'd be possible to implement a deferred
> parsing/building approach at the element level without much added memory or
> processing overhead, if done correctly. There can really only be one parser
> in use, for instance, so that can be stored at the document level, and even
> the element currently being expanded could be stored at that level (rather
> than using a flag on the element). But is the flexibility gain from doing
> things this way worth the added complexity, as opposed to my suggestion of a
> tweaked DOM with a special kind of expandable Element used only for the Body
> (well, actually two kinds of expandable Elements, the second to handle MTOM
> attachments)? I don't know.

I think it's worth it, because it solves the problem in a completely
generic way (i.e. without making assumptions about the structure of
the document). Also, Axiom 1.x has successfully proven that it is
perfectly possible to support deferred parsing/building on a
node-per-node basis. Of course there are some pieces in Axiom that are
very complex (see e.g. OMStAXWrapper/SwitchingWrapper class), but I
think that is more related to design questions than to the intrinsic
complexity of the approach used by Axiom. Simply this code has grown
over time and nobody took the time to break it down into more
manageable pieces.

I think that dropping deferred parsing/building on a node-per-node
basis would be a regression. In addition, this may have consequences
for Axis2 and may require changes. I think that instead of rewriting
parts of Axis2 to support a new (and less generic) model it is better
to invest that time into something that preserves the model (but that
may be a bit more complex).

>  - Dennis
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 11:21, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>
>>>
>>> ...
>>>>
>>>>
>>>
>>> The nice thing about using a slightly-hacked and simplified DOM is that
>>> everything would be automatic - as it is with Axiom now, but with
>>> considerably less memory and processor overhead (because this approach
>>> would
>>> *only* defer building the DOM representation of the Body content, and
>>> would
>>> build the entire Body content as a DOM whenever anything within the Body
>>> was
>>> accessed - a lot of the memory and processor overhead of Axiom relates to
>>> the incremental one-element-at-a-time build process). And because it'd
>>> still
>>> implement the DOM interface (or at least a subset suitable for use by
>>> WSS4J)
>>> applications using WSS4J could choose to use this or continue to use any
>>> other DOM they want.
>>>
>>
>> Your statement assumes that the memory/processor overhead in Axiom is
>> caused by the deferred parsing/building support. I don't think that is
>> true. I think the reason is simply the way (the default
>> implementations of) Axiom stores the information. For example, storing
>> the attributes and namespace declarations of an element in hash maps
>> is probably suboptimal. In SOAP messages, the average number of
>> attributes (resp. namespace declarations) on elements having at least
>> one attribute (resp. namespace declaration) is probably less then 2.
>> Therefore the overhead of creating and maintaining a hash map is
>> probably not justified by any gain in access performance.
>>
>
> Yes, I can see that it'd be possible to implement a deferred
> parsing/building approach at the element level without much added memory or
> processing overhead, if done correctly. There can really only be one parser
> in use, for instance, so that can be stored at the document level, and even
> the element currently being expanded could be stored at that level (rather
> than using a flag on the element). But is the flexibility gain from doing
> things this way worth the added complexity, as opposed to my suggestion of a
> tweaked DOM with a special kind of expandable Element used only for the Body
> (well, actually two kinds of expandable Elements, the second to handle MTOM
> attachments)? I don't know.

I think it's worth it, because it solves the problem in a completely
generic way (i.e. without making assumptions about the structure of
the document). Also, Axiom 1.x has successfully proven that it is
perfectly possible to support deferred parsing/building on a
node-per-node basis. Of course there are some pieces in Axiom that are
very complex (see e.g. OMStAXWrapper/SwitchingWrapper class), but I
think that is more related to design questions than to the intrinsic
complexity of the approach used by Axiom. Simply this code has grown
over time and nobody took the time to break it down into more
manageable pieces.

I think that dropping deferred parsing/building on a node-per-node
basis would be a regression. In addition, this may have consequences
for Axis2 and may require changes. I think that instead of rewriting
parts of Axis2 to support a new (and less generic) model it is better
to invest that time into something that preserves the model (but that
may be a bit more complex).

>  - Dennis
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 11:21, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>
>>>
>>> ...
>>>>
>>>>
>>>
>>> The nice thing about using a slightly-hacked and simplified DOM is that
>>> everything would be automatic - as it is with Axiom now, but with
>>> considerably less memory and processor overhead (because this approach
>>> would
>>> *only* defer building the DOM representation of the Body content, and
>>> would
>>> build the entire Body content as a DOM whenever anything within the Body
>>> was
>>> accessed - a lot of the memory and processor overhead of Axiom relates to
>>> the incremental one-element-at-a-time build process). And because it'd
>>> still
>>> implement the DOM interface (or at least a subset suitable for use by
>>> WSS4J)
>>> applications using WSS4J could choose to use this or continue to use any
>>> other DOM they want.
>>>
>>
>> Your statement assumes that the memory/processor overhead in Axiom is
>> caused by the deferred parsing/building support. I don't think that is
>> true. I think the reason is simply the way (the default
>> implementations of) Axiom stores the information. For example, storing
>> the attributes and namespace declarations of an element in hash maps
>> is probably suboptimal. In SOAP messages, the average number of
>> attributes (resp. namespace declarations) on elements having at least
>> one attribute (resp. namespace declaration) is probably less then 2.
>> Therefore the overhead of creating and maintaining a hash map is
>> probably not justified by any gain in access performance.
>>
>
> Yes, I can see that it'd be possible to implement a deferred
> parsing/building approach at the element level without much added memory or
> processing overhead, if done correctly. There can really only be one parser
> in use, for instance, so that can be stored at the document level, and even
> the element currently being expanded could be stored at that level (rather
> than using a flag on the element). But is the flexibility gain from doing
> things this way worth the added complexity, as opposed to my suggestion of a
> tweaked DOM with a special kind of expandable Element used only for the Body
> (well, actually two kinds of expandable Elements, the second to handle MTOM
> attachments)? I don't know.

I think it's worth it, because it solves the problem in a completely
generic way (i.e. without making assumptions about the structure of
the document). Also, Axiom 1.x has successfully proven that it is
perfectly possible to support deferred parsing/building on a
node-per-node basis. Of course there are some pieces in Axiom that are
very complex (see e.g. OMStAXWrapper/SwitchingWrapper class), but I
think that is more related to design questions than to the intrinsic
complexity of the approach used by Axiom. Simply this code has grown
over time and nobody took the time to break it down into more
manageable pieces.

I think that dropping deferred parsing/building on a node-per-node
basis would be a regression. In addition, this may have consequences
for Axis2 and may require changes. I think that instead of rewriting
parts of Axis2 to support a new (and less generic) model it is better
to invest that time into something that preserves the model (but that
may be a bit more complex).

>  - Dennis
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 11:21, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>
>>>
>>> ...
>>>>
>>>>
>>>
>>> The nice thing about using a slightly-hacked and simplified DOM is that
>>> everything would be automatic - as it is with Axiom now, but with
>>> considerably less memory and processor overhead (because this approach
>>> would
>>> *only* defer building the DOM representation of the Body content, and
>>> would
>>> build the entire Body content as a DOM whenever anything within the Body
>>> was
>>> accessed - a lot of the memory and processor overhead of Axiom relates to
>>> the incremental one-element-at-a-time build process). And because it'd
>>> still
>>> implement the DOM interface (or at least a subset suitable for use by
>>> WSS4J)
>>> applications using WSS4J could choose to use this or continue to use any
>>> other DOM they want.
>>>
>>
>> Your statement assumes that the memory/processor overhead in Axiom is
>> caused by the deferred parsing/building support. I don't think that is
>> true. I think the reason is simply the way (the default
>> implementations of) Axiom stores the information. For example, storing
>> the attributes and namespace declarations of an element in hash maps
>> is probably suboptimal. In SOAP messages, the average number of
>> attributes (resp. namespace declarations) on elements having at least
>> one attribute (resp. namespace declaration) is probably less then 2.
>> Therefore the overhead of creating and maintaining a hash map is
>> probably not justified by any gain in access performance.
>>
>
> Yes, I can see that it'd be possible to implement a deferred
> parsing/building approach at the element level without much added memory or
> processing overhead, if done correctly. There can really only be one parser
> in use, for instance, so that can be stored at the document level, and even
> the element currently being expanded could be stored at that level (rather
> than using a flag on the element). But is the flexibility gain from doing
> things this way worth the added complexity, as opposed to my suggestion of a
> tweaked DOM with a special kind of expandable Element used only for the Body
> (well, actually two kinds of expandable Elements, the second to handle MTOM
> attachments)? I don't know.

I think it's worth it, because it solves the problem in a completely
generic way (i.e. without making assumptions about the structure of
the document). Also, Axiom 1.x has successfully proven that it is
perfectly possible to support deferred parsing/building on a
node-per-node basis. Of course there are some pieces in Axiom that are
very complex (see e.g. OMStAXWrapper/SwitchingWrapper class), but I
think that is more related to design questions than to the intrinsic
complexity of the approach used by Axiom. Simply this code has grown
over time and nobody took the time to break it down into more
manageable pieces.

I think that dropping deferred parsing/building on a node-per-node
basis would be a regression. In addition, this may have consequences
for Axis2 and may require changes. I think that instead of rewriting
parts of Axis2 to support a new (and less generic) model it is better
to invest that time into something that preserves the model (but that
may be a bit more complex).

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 11:21, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>
>>>
>>> ...
>>>>
>>>>
>>>
>>> The nice thing about using a slightly-hacked and simplified DOM is that
>>> everything would be automatic - as it is with Axiom now, but with
>>> considerably less memory and processor overhead (because this approach
>>> would
>>> *only* defer building the DOM representation of the Body content, and
>>> would
>>> build the entire Body content as a DOM whenever anything within the Body
>>> was
>>> accessed - a lot of the memory and processor overhead of Axiom relates to
>>> the incremental one-element-at-a-time build process). And because it'd
>>> still
>>> implement the DOM interface (or at least a subset suitable for use by
>>> WSS4J)
>>> applications using WSS4J could choose to use this or continue to use any
>>> other DOM they want.
>>>
>>
>> Your statement assumes that the memory/processor overhead in Axiom is
>> caused by the deferred parsing/building support. I don't think that is
>> true. I think the reason is simply the way (the default
>> implementations of) Axiom stores the information. For example, storing
>> the attributes and namespace declarations of an element in hash maps
>> is probably suboptimal. In SOAP messages, the average number of
>> attributes (resp. namespace declarations) on elements having at least
>> one attribute (resp. namespace declaration) is probably less then 2.
>> Therefore the overhead of creating and maintaining a hash map is
>> probably not justified by any gain in access performance.
>>
>
> Yes, I can see that it'd be possible to implement a deferred
> parsing/building approach at the element level without much added memory or
> processing overhead, if done correctly. There can really only be one parser
> in use, for instance, so that can be stored at the document level, and even
> the element currently being expanded could be stored at that level (rather
> than using a flag on the element). But is the flexibility gain from doing
> things this way worth the added complexity, as opposed to my suggestion of a
> tweaked DOM with a special kind of expandable Element used only for the Body
> (well, actually two kinds of expandable Elements, the second to handle MTOM
> attachments)? I don't know.

I think it's worth it, because it solves the problem in a completely
generic way (i.e. without making assumptions about the structure of
the document). Also, Axiom 1.x has successfully proven that it is
perfectly possible to support deferred parsing/building on a
node-per-node basis. Of course there are some pieces in Axiom that are
very complex (see e.g. OMStAXWrapper/SwitchingWrapper class), but I
think that is more related to design questions than to the intrinsic
complexity of the approach used by Axiom. Simply this code has grown
over time and nobody took the time to break it down into more
manageable pieces.

I think that dropping deferred parsing/building on a node-per-node
basis would be a regression. In addition, this may have consequences
for Axis2 and may require changes. I think that instead of rewriting
parts of Axis2 to support a new (and less generic) model it is better
to invest that time into something that preserves the model (but that
may be a bit more complex).

>  - Dennis
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
>> ...
>>>       
>> The nice thing about using a slightly-hacked and simplified DOM is that
>> everything would be automatic - as it is with Axiom now, but with
>> considerably less memory and processor overhead (because this approach would
>> *only* defer building the DOM representation of the Body content, and would
>> build the entire Body content as a DOM whenever anything within the Body was
>> accessed - a lot of the memory and processor overhead of Axiom relates to
>> the incremental one-element-at-a-time build process). And because it'd still
>> implement the DOM interface (or at least a subset suitable for use by WSS4J)
>> applications using WSS4J could choose to use this or continue to use any
>> other DOM they want.
>>     
>
> Your statement assumes that the memory/processor overhead in Axiom is
> caused by the deferred parsing/building support. I don't think that is
> true. I think the reason is simply the way (the default
> implementations of) Axiom stores the information. For example, storing
> the attributes and namespace declarations of an element in hash maps
> is probably suboptimal. In SOAP messages, the average number of
> attributes (resp. namespace declarations) on elements having at least
> one attribute (resp. namespace declaration) is probably less then 2.
> Therefore the overhead of creating and maintaining a hash map is
> probably not justified by any gain in access performance.
>   

Yes, I can see that it'd be possible to implement a deferred 
parsing/building approach at the element level without much added memory 
or processing overhead, if done correctly. There can really only be one 
parser in use, for instance, so that can be stored at the document 
level, and even the element currently being expanded could be stored at 
that level (rather than using a flag on the element). But is the 
flexibility gain from doing things this way worth the added complexity, 
as opposed to my suggestion of a tweaked DOM with a special kind of 
expandable Element used only for the Body (well, actually two kinds of 
expandable Elements, the second to handle MTOM attachments)? I don't know.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
>> ...
>>>       
>> The nice thing about using a slightly-hacked and simplified DOM is that
>> everything would be automatic - as it is with Axiom now, but with
>> considerably less memory and processor overhead (because this approach would
>> *only* defer building the DOM representation of the Body content, and would
>> build the entire Body content as a DOM whenever anything within the Body was
>> accessed - a lot of the memory and processor overhead of Axiom relates to
>> the incremental one-element-at-a-time build process). And because it'd still
>> implement the DOM interface (or at least a subset suitable for use by WSS4J)
>> applications using WSS4J could choose to use this or continue to use any
>> other DOM they want.
>>     
>
> Your statement assumes that the memory/processor overhead in Axiom is
> caused by the deferred parsing/building support. I don't think that is
> true. I think the reason is simply the way (the default
> implementations of) Axiom stores the information. For example, storing
> the attributes and namespace declarations of an element in hash maps
> is probably suboptimal. In SOAP messages, the average number of
> attributes (resp. namespace declarations) on elements having at least
> one attribute (resp. namespace declaration) is probably less then 2.
> Therefore the overhead of creating and maintaining a hash map is
> probably not justified by any gain in access performance.
>   

Yes, I can see that it'd be possible to implement a deferred 
parsing/building approach at the element level without much added memory 
or processing overhead, if done correctly. There can really only be one 
parser in use, for instance, so that can be stored at the document 
level, and even the element currently being expanded could be stored at 
that level (rather than using a flag on the element). But is the 
flexibility gain from doing things this way worth the added complexity, 
as opposed to my suggestion of a tweaked DOM with a special kind of 
expandable Element used only for the Body (well, actually two kinds of 
expandable Elements, the second to handle MTOM attachments)? I don't know.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
>> ...
>>>       
>> The nice thing about using a slightly-hacked and simplified DOM is that
>> everything would be automatic - as it is with Axiom now, but with
>> considerably less memory and processor overhead (because this approach would
>> *only* defer building the DOM representation of the Body content, and would
>> build the entire Body content as a DOM whenever anything within the Body was
>> accessed - a lot of the memory and processor overhead of Axiom relates to
>> the incremental one-element-at-a-time build process). And because it'd still
>> implement the DOM interface (or at least a subset suitable for use by WSS4J)
>> applications using WSS4J could choose to use this or continue to use any
>> other DOM they want.
>>     
>
> Your statement assumes that the memory/processor overhead in Axiom is
> caused by the deferred parsing/building support. I don't think that is
> true. I think the reason is simply the way (the default
> implementations of) Axiom stores the information. For example, storing
> the attributes and namespace declarations of an element in hash maps
> is probably suboptimal. In SOAP messages, the average number of
> attributes (resp. namespace declarations) on elements having at least
> one attribute (resp. namespace declaration) is probably less then 2.
> Therefore the overhead of creating and maintaining a hash map is
> probably not justified by any gain in access performance.
>   

Yes, I can see that it'd be possible to implement a deferred 
parsing/building approach at the element level without much added memory 
or processing overhead, if done correctly. There can really only be one 
parser in use, for instance, so that can be stored at the document 
level, and even the element currently being expanded could be stored at 
that level (rather than using a flag on the element). But is the 
flexibility gain from doing things this way worth the added complexity, 
as opposed to my suggestion of a tweaked DOM with a special kind of 
expandable Element used only for the Body (well, actually two kinds of 
expandable Elements, the second to handle MTOM attachments)? I don't know.

  - Dennis

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
>> ...
>>>       
>> The nice thing about using a slightly-hacked and simplified DOM is that
>> everything would be automatic - as it is with Axiom now, but with
>> considerably less memory and processor overhead (because this approach would
>> *only* defer building the DOM representation of the Body content, and would
>> build the entire Body content as a DOM whenever anything within the Body was
>> accessed - a lot of the memory and processor overhead of Axiom relates to
>> the incremental one-element-at-a-time build process). And because it'd still
>> implement the DOM interface (or at least a subset suitable for use by WSS4J)
>> applications using WSS4J could choose to use this or continue to use any
>> other DOM they want.
>>     
>
> Your statement assumes that the memory/processor overhead in Axiom is
> caused by the deferred parsing/building support. I don't think that is
> true. I think the reason is simply the way (the default
> implementations of) Axiom stores the information. For example, storing
> the attributes and namespace declarations of an element in hash maps
> is probably suboptimal. In SOAP messages, the average number of
> attributes (resp. namespace declarations) on elements having at least
> one attribute (resp. namespace declaration) is probably less then 2.
> Therefore the overhead of creating and maintaining a hash map is
> probably not justified by any gain in access performance.
>   

Yes, I can see that it'd be possible to implement a deferred 
parsing/building approach at the element level without much added memory 
or processing overhead, if done correctly. There can really only be one 
parser in use, for instance, so that can be stored at the document 
level, and even the element currently being expanded could be stored at 
that level (rather than using a flag on the element). But is the 
flexibility gain from doing things this way worth the added complexity, 
as opposed to my suggestion of a tweaked DOM with a special kind of 
expandable Element used only for the Body (well, actually two kinds of 
expandable Elements, the second to handle MTOM attachments)? I don't know.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
>> ...
>>>       
>> The nice thing about using a slightly-hacked and simplified DOM is that
>> everything would be automatic - as it is with Axiom now, but with
>> considerably less memory and processor overhead (because this approach would
>> *only* defer building the DOM representation of the Body content, and would
>> build the entire Body content as a DOM whenever anything within the Body was
>> accessed - a lot of the memory and processor overhead of Axiom relates to
>> the incremental one-element-at-a-time build process). And because it'd still
>> implement the DOM interface (or at least a subset suitable for use by WSS4J)
>> applications using WSS4J could choose to use this or continue to use any
>> other DOM they want.
>>     
>
> Your statement assumes that the memory/processor overhead in Axiom is
> caused by the deferred parsing/building support. I don't think that is
> true. I think the reason is simply the way (the default
> implementations of) Axiom stores the information. For example, storing
> the attributes and namespace declarations of an element in hash maps
> is probably suboptimal. In SOAP messages, the average number of
> attributes (resp. namespace declarations) on elements having at least
> one attribute (resp. namespace declaration) is probably less then 2.
> Therefore the overhead of creating and maintaining a hash map is
> probably not justified by any gain in access performance.
>   

Yes, I can see that it'd be possible to implement a deferred 
parsing/building approach at the element level without much added memory 
or processing overhead, if done correctly. There can really only be one 
parser in use, for instance, so that can be stored at the document 
level, and even the element currently being expanded could be stored at 
that level (rather than using a flag on the element). But is the 
flexibility gain from doing things this way worth the added complexity, 
as opposed to my suggestion of a tweaked DOM with a special kind of 
expandable Element used only for the Body (well, actually two kinds of 
expandable Elements, the second to handle MTOM attachments)? I don't know.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
>> ...
>>>       
>> The nice thing about using a slightly-hacked and simplified DOM is that
>> everything would be automatic - as it is with Axiom now, but with
>> considerably less memory and processor overhead (because this approach would
>> *only* defer building the DOM representation of the Body content, and would
>> build the entire Body content as a DOM whenever anything within the Body was
>> accessed - a lot of the memory and processor overhead of Axiom relates to
>> the incremental one-element-at-a-time build process). And because it'd still
>> implement the DOM interface (or at least a subset suitable for use by WSS4J)
>> applications using WSS4J could choose to use this or continue to use any
>> other DOM they want.
>>     
>
> Your statement assumes that the memory/processor overhead in Axiom is
> caused by the deferred parsing/building support. I don't think that is
> true. I think the reason is simply the way (the default
> implementations of) Axiom stores the information. For example, storing
> the attributes and namespace declarations of an element in hash maps
> is probably suboptimal. In SOAP messages, the average number of
> attributes (resp. namespace declarations) on elements having at least
> one attribute (resp. namespace declaration) is probably less then 2.
> Therefore the overhead of creating and maintaining a hash map is
> probably not justified by any gain in access performance.
>   

Yes, I can see that it'd be possible to implement a deferred 
parsing/building approach at the element level without much added memory 
or processing overhead, if done correctly. There can really only be one 
parser in use, for instance, so that can be stored at the document 
level, and even the element currently being expanded could be stored at 
that level (rather than using a flag on the element). But is the 
flexibility gain from doing things this way worth the added complexity, 
as opposed to my suggestion of a tweaked DOM with a special kind of 
expandable Element used only for the Body (well, actually two kinds of 
expandable Elements, the second to handle MTOM attachments)? I don't know.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
>> ...
>>>       
>> The nice thing about using a slightly-hacked and simplified DOM is that
>> everything would be automatic - as it is with Axiom now, but with
>> considerably less memory and processor overhead (because this approach would
>> *only* defer building the DOM representation of the Body content, and would
>> build the entire Body content as a DOM whenever anything within the Body was
>> accessed - a lot of the memory and processor overhead of Axiom relates to
>> the incremental one-element-at-a-time build process). And because it'd still
>> implement the DOM interface (or at least a subset suitable for use by WSS4J)
>> applications using WSS4J could choose to use this or continue to use any
>> other DOM they want.
>>     
>
> Your statement assumes that the memory/processor overhead in Axiom is
> caused by the deferred parsing/building support. I don't think that is
> true. I think the reason is simply the way (the default
> implementations of) Axiom stores the information. For example, storing
> the attributes and namespace declarations of an element in hash maps
> is probably suboptimal. In SOAP messages, the average number of
> attributes (resp. namespace declarations) on elements having at least
> one attribute (resp. namespace declaration) is probably less then 2.
> Therefore the overhead of creating and maintaining a hash map is
> probably not justified by any gain in access performance.
>   

Yes, I can see that it'd be possible to implement a deferred 
parsing/building approach at the element level without much added memory 
or processing overhead, if done correctly. There can really only be one 
parser in use, for instance, so that can be stored at the document 
level, and even the element currently being expanded could be stored at 
that level (rather than using a flag on the element). But is the 
flexibility gain from doing things this way worth the added complexity, 
as opposed to my suggestion of a tweaked DOM with a special kind of 
expandable Element used only for the Body (well, actually two kinds of 
expandable Elements, the second to handle MTOM attachments)? I don't know.

  - Dennis

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Daniel Kulp wrote:
>>
>> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>>  ...
>>
>>>
>>>  From what I've seen CXF always builds the DOM representation of the
>>> entire message and passes it to WSS4J anytime WS-Security is configured,
>>> just as Axis2 does (though Dan did add a check to disable response
>>> message WS-Security handling if only UsernameToken is used). The
>>> approach I'm suggesting would only build a DOM representation of the
>>> Body if the security handling actually signed or encrypted the Body (or
>>> any part of it).
>>>
>>
>> I've thought of trying something similar to this by utilizing some sort of
>> callback mechanism from WSS4J for finding the appropriate Element for a
>> particular wsu:Id.
>> The problem is that you cannot really 100% reliably figure out if we need
>> the body or not from the policy, especially on server side where there could
>> be different policies depending on the operation which we wouldn't know
>> until a bit later.
>> Thus, I'd like to be able to add something to WSS4J that it could use to
>> find elements when there is a ref rather than always using an xpath search.
>>   There could be something more optimized put in place (like a simple String
>> -> Element map for those elements already parsed) that could avoid the
>> xpaths and such.   However, it could also allow some delayed loading of the
>> Body.
>>
>
> The nice thing about using a slightly-hacked and simplified DOM is that
> everything would be automatic - as it is with Axiom now, but with
> considerably less memory and processor overhead (because this approach would
> *only* defer building the DOM representation of the Body content, and would
> build the entire Body content as a DOM whenever anything within the Body was
> accessed - a lot of the memory and processor overhead of Axiom relates to
> the incremental one-element-at-a-time build process). And because it'd still
> implement the DOM interface (or at least a subset suitable for use by WSS4J)
> applications using WSS4J could choose to use this or continue to use any
> other DOM they want.

Your statement assumes that the memory/processor overhead in Axiom is
caused by the deferred parsing/building support. I don't think that is
true. I think the reason is simply the way (the default
implementations of) Axiom stores the information. For example, storing
the attributes and namespace declarations of an element in hash maps
is probably suboptimal. In SOAP messages, the average number of
attributes (resp. namespace declarations) on elements having at least
one attribute (resp. namespace declaration) is probably less then 2.
Therefore the overhead of creating and maintaining a hash map is
probably not justified by any gain in access performance.

>  - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Daniel Kulp wrote:
>>
>> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>>  ...
>>
>>>
>>>  From what I've seen CXF always builds the DOM representation of the
>>> entire message and passes it to WSS4J anytime WS-Security is configured,
>>> just as Axis2 does (though Dan did add a check to disable response
>>> message WS-Security handling if only UsernameToken is used). The
>>> approach I'm suggesting would only build a DOM representation of the
>>> Body if the security handling actually signed or encrypted the Body (or
>>> any part of it).
>>>
>>
>> I've thought of trying something similar to this by utilizing some sort of
>> callback mechanism from WSS4J for finding the appropriate Element for a
>> particular wsu:Id.
>> The problem is that you cannot really 100% reliably figure out if we need
>> the body or not from the policy, especially on server side where there could
>> be different policies depending on the operation which we wouldn't know
>> until a bit later.
>> Thus, I'd like to be able to add something to WSS4J that it could use to
>> find elements when there is a ref rather than always using an xpath search.
>>   There could be something more optimized put in place (like a simple String
>> -> Element map for those elements already parsed) that could avoid the
>> xpaths and such.   However, it could also allow some delayed loading of the
>> Body.
>>
>
> The nice thing about using a slightly-hacked and simplified DOM is that
> everything would be automatic - as it is with Axiom now, but with
> considerably less memory and processor overhead (because this approach would
> *only* defer building the DOM representation of the Body content, and would
> build the entire Body content as a DOM whenever anything within the Body was
> accessed - a lot of the memory and processor overhead of Axiom relates to
> the incremental one-element-at-a-time build process). And because it'd still
> implement the DOM interface (or at least a subset suitable for use by WSS4J)
> applications using WSS4J could choose to use this or continue to use any
> other DOM they want.

Your statement assumes that the memory/processor overhead in Axiom is
caused by the deferred parsing/building support. I don't think that is
true. I think the reason is simply the way (the default
implementations of) Axiom stores the information. For example, storing
the attributes and namespace declarations of an element in hash maps
is probably suboptimal. In SOAP messages, the average number of
attributes (resp. namespace declarations) on elements having at least
one attribute (resp. namespace declaration) is probably less then 2.
Therefore the overhead of creating and maintaining a hash map is
probably not justified by any gain in access performance.

>  - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Daniel Kulp wrote:
>>
>> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>>  ...
>>
>>>
>>>  From what I've seen CXF always builds the DOM representation of the
>>> entire message and passes it to WSS4J anytime WS-Security is configured,
>>> just as Axis2 does (though Dan did add a check to disable response
>>> message WS-Security handling if only UsernameToken is used). The
>>> approach I'm suggesting would only build a DOM representation of the
>>> Body if the security handling actually signed or encrypted the Body (or
>>> any part of it).
>>>
>>
>> I've thought of trying something similar to this by utilizing some sort of
>> callback mechanism from WSS4J for finding the appropriate Element for a
>> particular wsu:Id.
>> The problem is that you cannot really 100% reliably figure out if we need
>> the body or not from the policy, especially on server side where there could
>> be different policies depending on the operation which we wouldn't know
>> until a bit later.
>> Thus, I'd like to be able to add something to WSS4J that it could use to
>> find elements when there is a ref rather than always using an xpath search.
>>   There could be something more optimized put in place (like a simple String
>> -> Element map for those elements already parsed) that could avoid the
>> xpaths and such.   However, it could also allow some delayed loading of the
>> Body.
>>
>
> The nice thing about using a slightly-hacked and simplified DOM is that
> everything would be automatic - as it is with Axiom now, but with
> considerably less memory and processor overhead (because this approach would
> *only* defer building the DOM representation of the Body content, and would
> build the entire Body content as a DOM whenever anything within the Body was
> accessed - a lot of the memory and processor overhead of Axiom relates to
> the incremental one-element-at-a-time build process). And because it'd still
> implement the DOM interface (or at least a subset suitable for use by WSS4J)
> applications using WSS4J could choose to use this or continue to use any
> other DOM they want.

Your statement assumes that the memory/processor overhead in Axiom is
caused by the deferred parsing/building support. I don't think that is
true. I think the reason is simply the way (the default
implementations of) Axiom stores the information. For example, storing
the attributes and namespace declarations of an element in hash maps
is probably suboptimal. In SOAP messages, the average number of
attributes (resp. namespace declarations) on elements having at least
one attribute (resp. namespace declaration) is probably less then 2.
Therefore the overhead of creating and maintaining a hash map is
probably not justified by any gain in access performance.

>  - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Daniel Kulp wrote:
>>
>> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>>  ...
>>
>>>
>>>  From what I've seen CXF always builds the DOM representation of the
>>> entire message and passes it to WSS4J anytime WS-Security is configured,
>>> just as Axis2 does (though Dan did add a check to disable response
>>> message WS-Security handling if only UsernameToken is used). The
>>> approach I'm suggesting would only build a DOM representation of the
>>> Body if the security handling actually signed or encrypted the Body (or
>>> any part of it).
>>>
>>
>> I've thought of trying something similar to this by utilizing some sort of
>> callback mechanism from WSS4J for finding the appropriate Element for a
>> particular wsu:Id.
>> The problem is that you cannot really 100% reliably figure out if we need
>> the body or not from the policy, especially on server side where there could
>> be different policies depending on the operation which we wouldn't know
>> until a bit later.
>> Thus, I'd like to be able to add something to WSS4J that it could use to
>> find elements when there is a ref rather than always using an xpath search.
>>   There could be something more optimized put in place (like a simple String
>> -> Element map for those elements already parsed) that could avoid the
>> xpaths and such.   However, it could also allow some delayed loading of the
>> Body.
>>
>
> The nice thing about using a slightly-hacked and simplified DOM is that
> everything would be automatic - as it is with Axiom now, but with
> considerably less memory and processor overhead (because this approach would
> *only* defer building the DOM representation of the Body content, and would
> build the entire Body content as a DOM whenever anything within the Body was
> accessed - a lot of the memory and processor overhead of Axiom relates to
> the incremental one-element-at-a-time build process). And because it'd still
> implement the DOM interface (or at least a subset suitable for use by WSS4J)
> applications using WSS4J could choose to use this or continue to use any
> other DOM they want.

Your statement assumes that the memory/processor overhead in Axiom is
caused by the deferred parsing/building support. I don't think that is
true. I think the reason is simply the way (the default
implementations of) Axiom stores the information. For example, storing
the attributes and namespace declarations of an element in hash maps
is probably suboptimal. In SOAP messages, the average number of
attributes (resp. namespace declarations) on elements having at least
one attribute (resp. namespace declaration) is probably less then 2.
Therefore the overhead of creating and maintaining a hash map is
probably not justified by any gain in access performance.

>  - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Daniel Kulp wrote:
>>
>> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>>  ...
>>
>>>
>>>  From what I've seen CXF always builds the DOM representation of the
>>> entire message and passes it to WSS4J anytime WS-Security is configured,
>>> just as Axis2 does (though Dan did add a check to disable response
>>> message WS-Security handling if only UsernameToken is used). The
>>> approach I'm suggesting would only build a DOM representation of the
>>> Body if the security handling actually signed or encrypted the Body (or
>>> any part of it).
>>>
>>
>> I've thought of trying something similar to this by utilizing some sort of
>> callback mechanism from WSS4J for finding the appropriate Element for a
>> particular wsu:Id.
>> The problem is that you cannot really 100% reliably figure out if we need
>> the body or not from the policy, especially on server side where there could
>> be different policies depending on the operation which we wouldn't know
>> until a bit later.
>> Thus, I'd like to be able to add something to WSS4J that it could use to
>> find elements when there is a ref rather than always using an xpath search.
>>   There could be something more optimized put in place (like a simple String
>> -> Element map for those elements already parsed) that could avoid the
>> xpaths and such.   However, it could also allow some delayed loading of the
>> Body.
>>
>
> The nice thing about using a slightly-hacked and simplified DOM is that
> everything would be automatic - as it is with Axiom now, but with
> considerably less memory and processor overhead (because this approach would
> *only* defer building the DOM representation of the Body content, and would
> build the entire Body content as a DOM whenever anything within the Body was
> accessed - a lot of the memory and processor overhead of Axiom relates to
> the incremental one-element-at-a-time build process). And because it'd still
> implement the DOM interface (or at least a subset suitable for use by WSS4J)
> applications using WSS4J could choose to use this or continue to use any
> other DOM they want.

Your statement assumes that the memory/processor overhead in Axiom is
caused by the deferred parsing/building support. I don't think that is
true. I think the reason is simply the way (the default
implementations of) Axiom stores the information. For example, storing
the attributes and namespace declarations of an element in hash maps
is probably suboptimal. In SOAP messages, the average number of
attributes (resp. namespace declarations) on elements having at least
one attribute (resp. namespace declaration) is probably less then 2.
Therefore the overhead of creating and maintaining a hash map is
probably not justified by any gain in access performance.

>  - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Daniel Kulp wrote:
>>
>> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>>  ...
>>
>>>
>>>  From what I've seen CXF always builds the DOM representation of the
>>> entire message and passes it to WSS4J anytime WS-Security is configured,
>>> just as Axis2 does (though Dan did add a check to disable response
>>> message WS-Security handling if only UsernameToken is used). The
>>> approach I'm suggesting would only build a DOM representation of the
>>> Body if the security handling actually signed or encrypted the Body (or
>>> any part of it).
>>>
>>
>> I've thought of trying something similar to this by utilizing some sort of
>> callback mechanism from WSS4J for finding the appropriate Element for a
>> particular wsu:Id.
>> The problem is that you cannot really 100% reliably figure out if we need
>> the body or not from the policy, especially on server side where there could
>> be different policies depending on the operation which we wouldn't know
>> until a bit later.
>> Thus, I'd like to be able to add something to WSS4J that it could use to
>> find elements when there is a ref rather than always using an xpath search.
>>   There could be something more optimized put in place (like a simple String
>> -> Element map for those elements already parsed) that could avoid the
>> xpaths and such.   However, it could also allow some delayed loading of the
>> Body.
>>
>
> The nice thing about using a slightly-hacked and simplified DOM is that
> everything would be automatic - as it is with Axiom now, but with
> considerably less memory and processor overhead (because this approach would
> *only* defer building the DOM representation of the Body content, and would
> build the entire Body content as a DOM whenever anything within the Body was
> accessed - a lot of the memory and processor overhead of Axiom relates to
> the incremental one-element-at-a-time build process). And because it'd still
> implement the DOM interface (or at least a subset suitable for use by WSS4J)
> applications using WSS4J could choose to use this or continue to use any
> other DOM they want.

Your statement assumes that the memory/processor overhead in Axiom is
caused by the deferred parsing/building support. I don't think that is
true. I think the reason is simply the way (the default
implementations of) Axiom stores the information. For example, storing
the attributes and namespace declarations of an element in hash maps
is probably suboptimal. In SOAP messages, the average number of
attributes (resp. namespace declarations) on elements having at least
one attribute (resp. namespace declaration) is probably less then 2.
Therefore the overhead of creating and maintaining a hash map is
probably not justified by any gain in access performance.

>  - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Daniel Kulp wrote:
>>
>> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>>  ...
>>
>>>
>>>  From what I've seen CXF always builds the DOM representation of the
>>> entire message and passes it to WSS4J anytime WS-Security is configured,
>>> just as Axis2 does (though Dan did add a check to disable response
>>> message WS-Security handling if only UsernameToken is used). The
>>> approach I'm suggesting would only build a DOM representation of the
>>> Body if the security handling actually signed or encrypted the Body (or
>>> any part of it).
>>>
>>
>> I've thought of trying something similar to this by utilizing some sort of
>> callback mechanism from WSS4J for finding the appropriate Element for a
>> particular wsu:Id.
>> The problem is that you cannot really 100% reliably figure out if we need
>> the body or not from the policy, especially on server side where there could
>> be different policies depending on the operation which we wouldn't know
>> until a bit later.
>> Thus, I'd like to be able to add something to WSS4J that it could use to
>> find elements when there is a ref rather than always using an xpath search.
>>   There could be something more optimized put in place (like a simple String
>> -> Element map for those elements already parsed) that could avoid the
>> xpaths and such.   However, it could also allow some delayed loading of the
>> Body.
>>
>
> The nice thing about using a slightly-hacked and simplified DOM is that
> everything would be automatic - as it is with Axiom now, but with
> considerably less memory and processor overhead (because this approach would
> *only* defer building the DOM representation of the Body content, and would
> build the entire Body content as a DOM whenever anything within the Body was
> accessed - a lot of the memory and processor overhead of Axiom relates to
> the incremental one-element-at-a-time build process). And because it'd still
> implement the DOM interface (or at least a subset suitable for use by WSS4J)
> applications using WSS4J could choose to use this or continue to use any
> other DOM they want.

Your statement assumes that the memory/processor overhead in Axiom is
caused by the deferred parsing/building support. I don't think that is
true. I think the reason is simply the way (the default
implementations of) Axiom stores the information. For example, storing
the attributes and namespace declarations of an element in hash maps
is probably suboptimal. In SOAP messages, the average number of
attributes (resp. namespace declarations) on elements having at least
one attribute (resp. namespace declaration) is probably less then 2.
Therefore the overhead of creating and maintaining a hash map is
probably not justified by any gain in access performance.

>  - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Daniel Kulp wrote:
> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>   
> ...
>   
>>  From what I've seen CXF always builds the DOM representation of the
>> entire message and passes it to WSS4J anytime WS-Security is configured,
>> just as Axis2 does (though Dan did add a check to disable response
>> message WS-Security handling if only UsernameToken is used). The
>> approach I'm suggesting would only build a DOM representation of the
>> Body if the security handling actually signed or encrypted the Body (or
>> any part of it).
>>     
>
> I've thought of trying something similar to this by utilizing some sort of 
> callback mechanism from WSS4J for finding the appropriate Element for a 
> particular wsu:Id.   
>
> The problem is that you cannot really 100% reliably figure out if we need the 
> body or not from the policy, especially on server side where there could be 
> different policies depending on the operation which we wouldn't know until a 
> bit later.  
>
> Thus, I'd like to be able to add something to WSS4J that it could use to find 
> elements when there is a ref rather than always using an xpath search.   There 
> could be something more optimized put in place (like a simple String -> 
> Element map for those elements already parsed) that could avoid the xpaths and 
> such.   However, it could also allow some delayed loading of the Body.
>   

The nice thing about using a slightly-hacked and simplified DOM is that 
everything would be automatic - as it is with Axiom now, but with 
considerably less memory and processor overhead (because this approach 
would *only* defer building the DOM representation of the Body content, 
and would build the entire Body content as a DOM whenever anything 
within the Body was accessed - a lot of the memory and processor 
overhead of Axiom relates to the incremental one-element-at-a-time build 
process). And because it'd still implement the DOM interface (or at 
least a subset suitable for use by WSS4J) applications using WSS4J could 
choose to use this or continue to use any other DOM they want.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Daniel Kulp wrote:
> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>   
> ...
>   
>>  From what I've seen CXF always builds the DOM representation of the
>> entire message and passes it to WSS4J anytime WS-Security is configured,
>> just as Axis2 does (though Dan did add a check to disable response
>> message WS-Security handling if only UsernameToken is used). The
>> approach I'm suggesting would only build a DOM representation of the
>> Body if the security handling actually signed or encrypted the Body (or
>> any part of it).
>>     
>
> I've thought of trying something similar to this by utilizing some sort of 
> callback mechanism from WSS4J for finding the appropriate Element for a 
> particular wsu:Id.   
>
> The problem is that you cannot really 100% reliably figure out if we need the 
> body or not from the policy, especially on server side where there could be 
> different policies depending on the operation which we wouldn't know until a 
> bit later.  
>
> Thus, I'd like to be able to add something to WSS4J that it could use to find 
> elements when there is a ref rather than always using an xpath search.   There 
> could be something more optimized put in place (like a simple String -> 
> Element map for those elements already parsed) that could avoid the xpaths and 
> such.   However, it could also allow some delayed loading of the Body.
>   

The nice thing about using a slightly-hacked and simplified DOM is that 
everything would be automatic - as it is with Axiom now, but with 
considerably less memory and processor overhead (because this approach 
would *only* defer building the DOM representation of the Body content, 
and would build the entire Body content as a DOM whenever anything 
within the Body was accessed - a lot of the memory and processor 
overhead of Axiom relates to the incremental one-element-at-a-time build 
process). And because it'd still implement the DOM interface (or at 
least a subset suitable for use by WSS4J) applications using WSS4J could 
choose to use this or continue to use any other DOM they want.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Daniel Kulp wrote:
> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>   
> ...
>   
>>  From what I've seen CXF always builds the DOM representation of the
>> entire message and passes it to WSS4J anytime WS-Security is configured,
>> just as Axis2 does (though Dan did add a check to disable response
>> message WS-Security handling if only UsernameToken is used). The
>> approach I'm suggesting would only build a DOM representation of the
>> Body if the security handling actually signed or encrypted the Body (or
>> any part of it).
>>     
>
> I've thought of trying something similar to this by utilizing some sort of 
> callback mechanism from WSS4J for finding the appropriate Element for a 
> particular wsu:Id.   
>
> The problem is that you cannot really 100% reliably figure out if we need the 
> body or not from the policy, especially on server side where there could be 
> different policies depending on the operation which we wouldn't know until a 
> bit later.  
>
> Thus, I'd like to be able to add something to WSS4J that it could use to find 
> elements when there is a ref rather than always using an xpath search.   There 
> could be something more optimized put in place (like a simple String -> 
> Element map for those elements already parsed) that could avoid the xpaths and 
> such.   However, it could also allow some delayed loading of the Body.
>   

The nice thing about using a slightly-hacked and simplified DOM is that 
everything would be automatic - as it is with Axiom now, but with 
considerably less memory and processor overhead (because this approach 
would *only* defer building the DOM representation of the Body content, 
and would build the entire Body content as a DOM whenever anything 
within the Body was accessed - a lot of the memory and processor 
overhead of Axiom relates to the incremental one-element-at-a-time build 
process). And because it'd still implement the DOM interface (or at 
least a subset suitable for use by WSS4J) applications using WSS4J could 
choose to use this or continue to use any other DOM they want.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Daniel Kulp wrote:
> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>   
> ...
>   
>>  From what I've seen CXF always builds the DOM representation of the
>> entire message and passes it to WSS4J anytime WS-Security is configured,
>> just as Axis2 does (though Dan did add a check to disable response
>> message WS-Security handling if only UsernameToken is used). The
>> approach I'm suggesting would only build a DOM representation of the
>> Body if the security handling actually signed or encrypted the Body (or
>> any part of it).
>>     
>
> I've thought of trying something similar to this by utilizing some sort of 
> callback mechanism from WSS4J for finding the appropriate Element for a 
> particular wsu:Id.   
>
> The problem is that you cannot really 100% reliably figure out if we need the 
> body or not from the policy, especially on server side where there could be 
> different policies depending on the operation which we wouldn't know until a 
> bit later.  
>
> Thus, I'd like to be able to add something to WSS4J that it could use to find 
> elements when there is a ref rather than always using an xpath search.   There 
> could be something more optimized put in place (like a simple String -> 
> Element map for those elements already parsed) that could avoid the xpaths and 
> such.   However, it could also allow some delayed loading of the Body.
>   

The nice thing about using a slightly-hacked and simplified DOM is that 
everything would be automatic - as it is with Axiom now, but with 
considerably less memory and processor overhead (because this approach 
would *only* defer building the DOM representation of the Body content, 
and would build the entire Body content as a DOM whenever anything 
within the Body was accessed - a lot of the memory and processor 
overhead of Axiom relates to the incremental one-element-at-a-time build 
process). And because it'd still implement the DOM interface (or at 
least a subset suitable for use by WSS4J) applications using WSS4J could 
choose to use this or continue to use any other DOM they want.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Daniel Kulp wrote:
> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>   
> ...
>   
>>  From what I've seen CXF always builds the DOM representation of the
>> entire message and passes it to WSS4J anytime WS-Security is configured,
>> just as Axis2 does (though Dan did add a check to disable response
>> message WS-Security handling if only UsernameToken is used). The
>> approach I'm suggesting would only build a DOM representation of the
>> Body if the security handling actually signed or encrypted the Body (or
>> any part of it).
>>     
>
> I've thought of trying something similar to this by utilizing some sort of 
> callback mechanism from WSS4J for finding the appropriate Element for a 
> particular wsu:Id.   
>
> The problem is that you cannot really 100% reliably figure out if we need the 
> body or not from the policy, especially on server side where there could be 
> different policies depending on the operation which we wouldn't know until a 
> bit later.  
>
> Thus, I'd like to be able to add something to WSS4J that it could use to find 
> elements when there is a ref rather than always using an xpath search.   There 
> could be something more optimized put in place (like a simple String -> 
> Element map for those elements already parsed) that could avoid the xpaths and 
> such.   However, it could also allow some delayed loading of the Body.
>   

The nice thing about using a slightly-hacked and simplified DOM is that 
everything would be automatic - as it is with Axiom now, but with 
considerably less memory and processor overhead (because this approach 
would *only* defer building the DOM representation of the Body content, 
and would build the entire Body content as a DOM whenever anything 
within the Body was accessed - a lot of the memory and processor 
overhead of Axiom relates to the incremental one-element-at-a-time build 
process). And because it'd still implement the DOM interface (or at 
least a subset suitable for use by WSS4J) applications using WSS4J could 
choose to use this or continue to use any other DOM they want.

  - Dennis

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Daniel Kulp wrote:
> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>   
> ...
>   
>>  From what I've seen CXF always builds the DOM representation of the
>> entire message and passes it to WSS4J anytime WS-Security is configured,
>> just as Axis2 does (though Dan did add a check to disable response
>> message WS-Security handling if only UsernameToken is used). The
>> approach I'm suggesting would only build a DOM representation of the
>> Body if the security handling actually signed or encrypted the Body (or
>> any part of it).
>>     
>
> I've thought of trying something similar to this by utilizing some sort of 
> callback mechanism from WSS4J for finding the appropriate Element for a 
> particular wsu:Id.   
>
> The problem is that you cannot really 100% reliably figure out if we need the 
> body or not from the policy, especially on server side where there could be 
> different policies depending on the operation which we wouldn't know until a 
> bit later.  
>
> Thus, I'd like to be able to add something to WSS4J that it could use to find 
> elements when there is a ref rather than always using an xpath search.   There 
> could be something more optimized put in place (like a simple String -> 
> Element map for those elements already parsed) that could avoid the xpaths and 
> such.   However, it could also allow some delayed loading of the Body.
>   

The nice thing about using a slightly-hacked and simplified DOM is that 
everything would be automatic - as it is with Axiom now, but with 
considerably less memory and processor overhead (because this approach 
would *only* defer building the DOM representation of the Body content, 
and would build the entire Body content as a DOM whenever anything 
within the Body was accessed - a lot of the memory and processor 
overhead of Axiom relates to the incremental one-element-at-a-time build 
process). And because it'd still implement the DOM interface (or at 
least a subset suitable for use by WSS4J) applications using WSS4J could 
choose to use this or continue to use any other DOM they want.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Daniel Kulp wrote:
> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>   
> ...
>   
>>  From what I've seen CXF always builds the DOM representation of the
>> entire message and passes it to WSS4J anytime WS-Security is configured,
>> just as Axis2 does (though Dan did add a check to disable response
>> message WS-Security handling if only UsernameToken is used). The
>> approach I'm suggesting would only build a DOM representation of the
>> Body if the security handling actually signed or encrypted the Body (or
>> any part of it).
>>     
>
> I've thought of trying something similar to this by utilizing some sort of 
> callback mechanism from WSS4J for finding the appropriate Element for a 
> particular wsu:Id.   
>
> The problem is that you cannot really 100% reliably figure out if we need the 
> body or not from the policy, especially on server side where there could be 
> different policies depending on the operation which we wouldn't know until a 
> bit later.  
>
> Thus, I'd like to be able to add something to WSS4J that it could use to find 
> elements when there is a ref rather than always using an xpath search.   There 
> could be something more optimized put in place (like a simple String -> 
> Element map for those elements already parsed) that could avoid the xpaths and 
> such.   However, it could also allow some delayed loading of the Body.
>   

The nice thing about using a slightly-hacked and simplified DOM is that 
everything would be automatic - as it is with Axiom now, but with 
considerably less memory and processor overhead (because this approach 
would *only* defer building the DOM representation of the Body content, 
and would build the entire Body content as a DOM whenever anything 
within the Body was accessed - a lot of the memory and processor 
overhead of Axiom relates to the incremental one-element-at-a-time build 
process). And because it'd still implement the DOM interface (or at 
least a subset suitable for use by WSS4J) applications using WSS4J could 
choose to use this or continue to use any other DOM they want.

  - Dennis

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

Re: Performance Comparison

[Daniel Kulp <dk...@apache.org>]

On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
> Andreas Veithen wrote:
> > On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >> 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.
> > 
> > Sounds pretty much like CXF...

:-)     Got a good chuckle out of that.   :-)


>  From what I've seen CXF always builds the DOM representation of the
> entire message and passes it to WSS4J anytime WS-Security is configured,
> just as Axis2 does (though Dan did add a check to disable response
> message WS-Security handling if only UsernameToken is used). The
> approach I'm suggesting would only build a DOM representation of the
> Body if the security handling actually signed or encrypted the Body (or
> any part of it).

I've thought of trying something similar to this by utilizing some sort of 
callback mechanism from WSS4J for finding the appropriate Element for a 
particular wsu:Id.   

The problem is that you cannot really 100% reliably figure out if we need the 
body or not from the policy, especially on server side where there could be 
different policies depending on the operation which we wouldn't know until a 
bit later.  

Thus, I'd like to be able to add something to WSS4J that it could use to find 
elements when there is a ref rather than always using an xpath search.   There 
could be something more optimized put in place (like a simple String -> 
Element map for those elements already parsed) that could avoid the xpaths and 
such.   However, it could also allow some delayed loading of the Body.

Anyway, it's some stuff I've been noodling on a bit for a while.  Not sure if 
I'll ever have time to actually do it.  :-(

Dan

> 
>   - Dennis
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Performance Comparison

[Daniel Kulp <dk...@apache.org>]

On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
> Andreas Veithen wrote:
> > On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >> 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.
> > 
> > Sounds pretty much like CXF...

:-)     Got a good chuckle out of that.   :-)


>  From what I've seen CXF always builds the DOM representation of the
> entire message and passes it to WSS4J anytime WS-Security is configured,
> just as Axis2 does (though Dan did add a check to disable response
> message WS-Security handling if only UsernameToken is used). The
> approach I'm suggesting would only build a DOM representation of the
> Body if the security handling actually signed or encrypted the Body (or
> any part of it).

I've thought of trying something similar to this by utilizing some sort of 
callback mechanism from WSS4J for finding the appropriate Element for a 
particular wsu:Id.   

The problem is that you cannot really 100% reliably figure out if we need the 
body or not from the policy, especially on server side where there could be 
different policies depending on the operation which we wouldn't know until a 
bit later.  

Thus, I'd like to be able to add something to WSS4J that it could use to find 
elements when there is a ref rather than always using an xpath search.   There 
could be something more optimized put in place (like a simple String -> 
Element map for those elements already parsed) that could avoid the xpaths and 
such.   However, it could also allow some delayed loading of the Body.

Anyway, it's some stuff I've been noodling on a bit for a while.  Not sure if 
I'll ever have time to actually do it.  :-(

Dan

> 
>   - Dennis
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

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

Re: Performance Comparison

[Saliya Ekanayake <es...@gmail.com>]

Just a note on Axiom based implementation of Rampart. As Ruchith have
pointed out the implementation is fairly supports the majority of use cases.
Obviously, it may need refinements, but a working implementation of XML-C14N
to SOAP security is there in this. An earlier version of Axiom based C14N is
there in the Axiom code at the moment.

Thank you,
Saliya

On Mon, May 3, 2010 at 6:57 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:

> Andreas Veithen wrote:
>
>> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>  ...
>>
>>
>>> 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.
>>>
>>>
>>
>> Sounds pretty much like CXF...
>>
>>
>
> From what I've seen CXF always builds the DOM representation of the entire
> message and passes it to WSS4J anytime WS-Security is configured, just as
> Axis2 does (though Dan did add a check to disable response message
> WS-Security handling if only UsernameToken is used). The approach I'm
> suggesting would only build a DOM representation of the Body if the security
> handling actually signed or encrypted the Body (or any part of it).
>
>  - Dennis
>



-- 
Saliya Ekanayake
http://www.esaliya.blogspot.com
http://www.esaliya.wordpress.com

Re: Performance Comparison

[Saliya Ekanayake <es...@gmail.com>]

Just a note on Axiom based implementation of Rampart. As Ruchith have
pointed out the implementation is fairly supports the majority of use cases.
Obviously, it may need refinements, but a working implementation of XML-C14N
to SOAP security is there in this. An earlier version of Axiom based C14N is
there in the Axiom code at the moment.

Thank you,
Saliya

On Mon, May 3, 2010 at 6:57 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:

> Andreas Veithen wrote:
>
>> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>  ...
>>
>>
>>> 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.
>>>
>>>
>>
>> Sounds pretty much like CXF...
>>
>>
>
> From what I've seen CXF always builds the DOM representation of the entire
> message and passes it to WSS4J anytime WS-Security is configured, just as
> Axis2 does (though Dan did add a check to disable response message
> WS-Security handling if only UsernameToken is used). The approach I'm
> suggesting would only build a DOM representation of the Body if the security
> handling actually signed or encrypted the Body (or any part of it).
>
>  - Dennis
>



-- 
Saliya Ekanayake
http://www.esaliya.blogspot.com
http://www.esaliya.wordpress.com

Re: Performance Comparison

[Saliya Ekanayake <es...@gmail.com>]

Just a note on Axiom based implementation of Rampart. As Ruchith have
pointed out the implementation is fairly supports the majority of use cases.
Obviously, it may need refinements, but a working implementation of XML-C14N
to SOAP security is there in this. An earlier version of Axiom based C14N is
there in the Axiom code at the moment.

Thank you,
Saliya

On Mon, May 3, 2010 at 6:57 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:

> Andreas Veithen wrote:
>
>> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>  ...
>>
>>
>>> 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.
>>>
>>>
>>
>> Sounds pretty much like CXF...
>>
>>
>
> From what I've seen CXF always builds the DOM representation of the entire
> message and passes it to WSS4J anytime WS-Security is configured, just as
> Axis2 does (though Dan did add a check to disable response message
> WS-Security handling if only UsernameToken is used). The approach I'm
> suggesting would only build a DOM representation of the Body if the security
> handling actually signed or encrypted the Body (or any part of it).
>
>  - Dennis
>



-- 
Saliya Ekanayake
http://www.esaliya.blogspot.com
http://www.esaliya.wordpress.com

Re: Performance Comparison

[Saliya Ekanayake <es...@gmail.com>]

Just a note on Axiom based implementation of Rampart. As Ruchith have
pointed out the implementation is fairly supports the majority of use cases.
Obviously, it may need refinements, but a working implementation of XML-C14N
to SOAP security is there in this. An earlier version of Axiom based C14N is
there in the Axiom code at the moment.

Thank you,
Saliya

On Mon, May 3, 2010 at 6:57 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:

> Andreas Veithen wrote:
>
>> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>  ...
>>
>>
>>> 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.
>>>
>>>
>>
>> Sounds pretty much like CXF...
>>
>>
>
> From what I've seen CXF always builds the DOM representation of the entire
> message and passes it to WSS4J anytime WS-Security is configured, just as
> Axis2 does (though Dan did add a check to disable response message
> WS-Security handling if only UsernameToken is used). The approach I'm
> suggesting would only build a DOM representation of the Body if the security
> handling actually signed or encrypted the Body (or any part of it).
>
>  - Dennis
>



-- 
Saliya Ekanayake
http://www.esaliya.blogspot.com
http://www.esaliya.wordpress.com

Re: Performance Comparison

[Saliya Ekanayake <es...@gmail.com>]

Just a note on Axiom based implementation of Rampart. As Ruchith have
pointed out the implementation is fairly supports the majority of use cases.
Obviously, it may need refinements, but a working implementation of XML-C14N
to SOAP security is there in this. An earlier version of Axiom based C14N is
there in the Axiom code at the moment.

Thank you,
Saliya

On Mon, May 3, 2010 at 6:57 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:

> Andreas Veithen wrote:
>
>> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>  ...
>>
>>
>>> 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.
>>>
>>>
>>
>> Sounds pretty much like CXF...
>>
>>
>
> From what I've seen CXF always builds the DOM representation of the entire
> message and passes it to WSS4J anytime WS-Security is configured, just as
> Axis2 does (though Dan did add a check to disable response message
> WS-Security handling if only UsernameToken is used). The approach I'm
> suggesting would only build a DOM representation of the Body if the security
> handling actually signed or encrypted the Body (or any part of it).
>
>  - Dennis
>



-- 
Saliya Ekanayake
http://www.esaliya.blogspot.com
http://www.esaliya.wordpress.com

Re: Performance Comparison

[Saliya Ekanayake <es...@gmail.com>]

Just a note on Axiom based implementation of Rampart. As Ruchith have
pointed out the implementation is fairly supports the majority of use cases.
Obviously, it may need refinements, but a working implementation of XML-C14N
to SOAP security is there in this. An earlier version of Axiom based C14N is
there in the Axiom code at the moment.

Thank you,
Saliya

On Mon, May 3, 2010 at 6:57 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:

> Andreas Veithen wrote:
>
>> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>  ...
>>
>>
>>> 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.
>>>
>>>
>>
>> Sounds pretty much like CXF...
>>
>>
>
> From what I've seen CXF always builds the DOM representation of the entire
> message and passes it to WSS4J anytime WS-Security is configured, just as
> Axis2 does (though Dan did add a check to disable response message
> WS-Security handling if only UsernameToken is used). The approach I'm
> suggesting would only build a DOM representation of the Body if the security
> handling actually signed or encrypted the Body (or any part of it).
>
>  - Dennis
>



-- 
Saliya Ekanayake
http://www.esaliya.blogspot.com
http://www.esaliya.wordpress.com

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
> ...
>>
>> 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.
>>     
>
> Sounds pretty much like CXF...
>   

 From what I've seen CXF always builds the DOM representation of the 
entire message and passes it to WSS4J anytime WS-Security is configured, 
just as Axis2 does (though Dan did add a check to disable response 
message WS-Security handling if only UsernameToken is used). The 
approach I'm suggesting would only build a DOM representation of the 
Body if the security handling actually signed or encrypted the Body (or 
any part of it).

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
> ...
>>
>> 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.
>>     
>
> Sounds pretty much like CXF...
>   

 From what I've seen CXF always builds the DOM representation of the 
entire message and passes it to WSS4J anytime WS-Security is configured, 
just as Axis2 does (though Dan did add a check to disable response 
message WS-Security handling if only UsernameToken is used). The 
approach I'm suggesting would only build a DOM representation of the 
Body if the security handling actually signed or encrypted the Body (or 
any part of it).

  - Dennis

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
> ...
>>
>> 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.
>>     
>
> Sounds pretty much like CXF...
>   

 From what I've seen CXF always builds the DOM representation of the 
entire message and passes it to WSS4J anytime WS-Security is configured, 
just as Axis2 does (though Dan did add a check to disable response 
message WS-Security handling if only UsernameToken is used). The 
approach I'm suggesting would only build a DOM representation of the 
Body if the security handling actually signed or encrypted the Body (or 
any part of it).

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
> ...
>>
>> 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.
>>     
>
> Sounds pretty much like CXF...
>   

 From what I've seen CXF always builds the DOM representation of the 
entire message and passes it to WSS4J anytime WS-Security is configured, 
just as Axis2 does (though Dan did add a check to disable response 
message WS-Security handling if only UsernameToken is used). The 
approach I'm suggesting would only build a DOM representation of the 
Body if the security handling actually signed or encrypted the Body (or 
any part of it).

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
> ...
>>
>> 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.
>>     
>
> Sounds pretty much like CXF...
>   

 From what I've seen CXF always builds the DOM representation of the 
entire message and passes it to WSS4J anytime WS-Security is configured, 
just as Axis2 does (though Dan did add a check to disable response 
message WS-Security handling if only UsernameToken is used). The 
approach I'm suggesting would only build a DOM representation of the 
Body if the security handling actually signed or encrypted the Body (or 
any part of it).

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
> ...
>>
>> 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.
>>     
>
> Sounds pretty much like CXF...
>   

 From what I've seen CXF always builds the DOM representation of the 
entire message and passes it to WSS4J anytime WS-Security is configured, 
just as Axis2 does (though Dan did add a check to disable response 
message WS-Security handling if only UsernameToken is used). The 
approach I'm suggesting would only build a DOM representation of the 
Body if the security handling actually signed or encrypted the Body (or 
any part of it).

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>   
> ...
>>
>> 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.
>>     
>
> Sounds pretty much like CXF...
>   

 From what I've seen CXF always builds the DOM representation of the 
entire message and passes it to WSS4J anytime WS-Security is configured, 
just as Axis2 does (though Dan did add a check to disable response 
message WS-Security handling if only UsernameToken is used). The 
approach I'm suggesting would only build a DOM representation of the 
Body if the security handling actually signed or encrypted the Body (or 
any part of it).

  - Dennis

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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.

Note that ADB (neither POJOs nor generated code) no longer provides (a
working) pull parser and always uses push, as the other data bindings.
This is BTW an issue in some cases:

http://people.apache.org/~veithen/axiom/userguide/ch05.html#d0e1102

> 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.

Sounds pretty much like CXF...

>
>  - Dennis
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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.

Note that ADB (neither POJOs nor generated code) no longer provides (a
working) pull parser and always uses push, as the other data bindings.
This is BTW an issue in some cases:

http://people.apache.org/~veithen/axiom/userguide/ch05.html#d0e1102

> 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.

Sounds pretty much like CXF...

>
>  - Dennis
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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.

Note that ADB (neither POJOs nor generated code) no longer provides (a
working) pull parser and always uses push, as the other data bindings.
This is BTW an issue in some cases:

http://people.apache.org/~veithen/axiom/userguide/ch05.html#d0e1102

> 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.

Sounds pretty much like CXF...

>
>  - Dennis
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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.

Note that ADB (neither POJOs nor generated code) no longer provides (a
working) pull parser and always uses push, as the other data bindings.
This is BTW an issue in some cases:

http://people.apache.org/~veithen/axiom/userguide/ch05.html#d0e1102

> 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.

Sounds pretty much like CXF...

>
>  - Dennis
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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.

Note that ADB (neither POJOs nor generated code) no longer provides (a
working) pull parser and always uses push, as the other data bindings.
This is BTW an issue in some cases:

http://people.apache.org/~veithen/axiom/userguide/ch05.html#d0e1102

> 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.

Sounds pretty much like CXF...

>
>  - Dennis
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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.

Note that ADB (neither POJOs nor generated code) no longer provides (a
working) pull parser and always uses push, as the other data bindings.
This is BTW an issue in some cases:

http://people.apache.org/~veithen/axiom/userguide/ch05.html#d0e1102

> 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.

Sounds pretty much like CXF...

>
>  - Dennis
>

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Andreas Veithen wrote:
>>
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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.

Note that ADB (neither POJOs nor generated code) no longer provides (a
working) pull parser and always uses push, as the other data bindings.
This is BTW an issue in some cases:

http://people.apache.org/~veithen/axiom/userguide/ch05.html#d0e1102

> 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.

Sounds pretty much like CXF...

>
>  - Dennis
>

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Wed, May 19, 2010 at 6:36 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
> hi,
>
> however replacing the following line
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
> with
>
> SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();
>
> causes some test case failures.
>
> Also we found this info message.
>
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#id-613"
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#My ticket Id"

What are the test failures?
The above lines shows the verified parts of signatures.

Thanks,
Ruchith

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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Wed, May 19, 2010 at 6:36 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
> hi,
>
> however replacing the following line
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
> with
>
> SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();
>
> causes some test case failures.
>
> Also we found this info message.
>
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#id-613"
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#My ticket Id"

What are the test failures?
The above lines shows the verified parts of signatures.

Thanks,
Ruchith

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Wed, May 19, 2010 at 6:36 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
> hi,
>
> however replacing the following line
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
> with
>
> SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();
>
> causes some test case failures.
>
> Also we found this info message.
>
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#id-613"
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#My ticket Id"

What are the test failures?
The above lines shows the verified parts of signatures.

Thanks,
Ruchith

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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Wed, May 19, 2010 at 6:36 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
> hi,
>
> however replacing the following line
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
> with
>
> SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();
>
> causes some test case failures.
>
> Also we found this info message.
>
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#id-613"
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#My ticket Id"

What are the test failures?
The above lines shows the verified parts of signatures.

Thanks,
Ruchith

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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Wed, May 19, 2010 at 6:36 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
> hi,
>
> however replacing the following line
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
> with
>
> SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();
>
> causes some test case failures.
>
> Also we found this info message.
>
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#id-613"
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#My ticket Id"

What are the test failures?
The above lines shows the verified parts of signatures.

Thanks,
Ruchith

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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Wed, May 19, 2010 at 6:36 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
> hi,
>
> however replacing the following line
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
> with
>
> SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();
>
> causes some test case failures.
>
> Also we found this info message.
>
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#id-613"
> May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
> INFO: Verification successful for URI "#My ticket Id"

What are the test failures?
The above lines shows the verified parts of signatures.

Thanks,
Ruchith

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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

hi,

however replacing the following line

SOAPEnvelope env =
Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);

with

SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();

causes some test case failures.

Also we found this info message.

May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
INFO: Verification successful for URI "#id-613"
May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
INFO: Verification successful for URI "#My ticket Id"

thanks,
Amila.





On Wed, May 19, 2010 at 5:23 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

> hi,
>
> We have started looking into rampart performance issues using the bench
> mark provided by Denis.
>
> We did some testing using the current axis2 and rampart trunks with the
> this[1] performance enhancement.
> In this case for small messages both cxf and Axis2 shows similar
> performance values while cxf shows better performance for larger messages.
>
> By looking at the rampart code I found these lines.
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
>         if(dotDebug){
>             t2 = System.currentTimeMillis();
>         }
>
>         //Convert back to llom since the inflow cannot use DOOM
>         msgCtx.setEnvelope(env);
>         Axis2Util.useDOOM(false);
>
> This shows it again builds OM elements which apparently invalidate the use
> of DOOM. I think the whole point of
> DOOM is to use it as a AXIOM as well.
>
> this is documented in rampart developer guide as well.
>
> "When Rampart is engaged and configured, the incoming SOAP messages are
> converted to DOOM. Since DOOM implements the DOM interface it is possible
> for WSS4J to process messages. After performing the security validations,
> before flushing the message down the message inflow, the DOOM SOAP message
> is converted back to OM. At the outgoing flow, the message is converted to
> DOOM and then the security functions are performed using WSS4J."
>
> Thoughts? have I miss something?
>
> thanks,
> Amila.
>
> [1]
> http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html
>
>
> On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com>
>> wrote:
>> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
>> > <an...@gmail.com> wrote:
>> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com>
>> wrote:
>> >>> Yes, I think it'd make much more sense to base a build-on-demand
>> document
>> >>> model on the DOM API than to try to modify all the WSS4J and related
>> code to
>> >>> use Axiom. Especially since Axiom is a mess and has had performance
>> issues
>> >>> from the beginning (including using way too much memory as the model
>> is
>> >>> expanded).
>> >>
>> >> 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/
>> >
>> > Just for curiosity, have you done any performance comparison with your
>> > implementation with any other implementation ?
>>
>> Not yet. BTW, do you know of any existing (performance) test suite
>> that tests WS-Security processing in isolation, i.e. without the need
>> for a full SOAP stack (my project is ready for integration with WSS4J,
>> but far from being ready to support Axis2)?
>>
>> > Sanka
>> >
>> >
>> >>
>> >>> Daniel Kulp wrote:
>> >>>>
>> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.
>> The
>> >>>> NodeList stuff isn't even threadsafe in Xerces.
>> >>>
>> >>> Actually, *no* access operations are threadsafe in Xerces. As far as
>> I'm
>> >>> concerned that's a really bad design for general purpose use,
>> ironically
>> >>> going back to the deferred node expansion feature that Xerces has on
>> by
>> >>> default. It's always irked me that I have to use a synchronization
>> lock
>> >>> around read-only operations with a (Xerces) DOM.
>> >>>
>> >>> That said, any form of build-on-demand document model is probably not
>> going
>> >>> to be threadsafe. But for our purposes in using it with web services
>> there's
>> >>> not much need for threadsafety.
>> >>>
>> >>>  - Dennis
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Sanka Samaranayake
>> >
>> > http://sankas.blogspot.com/
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>



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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

hi,

however replacing the following line

SOAPEnvelope env =
Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);

with

SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();

causes some test case failures.

Also we found this info message.

May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
INFO: Verification successful for URI "#id-613"
May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
INFO: Verification successful for URI "#My ticket Id"

thanks,
Amila.





On Wed, May 19, 2010 at 5:23 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

> hi,
>
> We have started looking into rampart performance issues using the bench
> mark provided by Denis.
>
> We did some testing using the current axis2 and rampart trunks with the
> this[1] performance enhancement.
> In this case for small messages both cxf and Axis2 shows similar
> performance values while cxf shows better performance for larger messages.
>
> By looking at the rampart code I found these lines.
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
>         if(dotDebug){
>             t2 = System.currentTimeMillis();
>         }
>
>         //Convert back to llom since the inflow cannot use DOOM
>         msgCtx.setEnvelope(env);
>         Axis2Util.useDOOM(false);
>
> This shows it again builds OM elements which apparently invalidate the use
> of DOOM. I think the whole point of
> DOOM is to use it as a AXIOM as well.
>
> this is documented in rampart developer guide as well.
>
> "When Rampart is engaged and configured, the incoming SOAP messages are
> converted to DOOM. Since DOOM implements the DOM interface it is possible
> for WSS4J to process messages. After performing the security validations,
> before flushing the message down the message inflow, the DOOM SOAP message
> is converted back to OM. At the outgoing flow, the message is converted to
> DOOM and then the security functions are performed using WSS4J."
>
> Thoughts? have I miss something?
>
> thanks,
> Amila.
>
> [1]
> http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html
>
>
> On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com>
>> wrote:
>> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
>> > <an...@gmail.com> wrote:
>> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com>
>> wrote:
>> >>> Yes, I think it'd make much more sense to base a build-on-demand
>> document
>> >>> model on the DOM API than to try to modify all the WSS4J and related
>> code to
>> >>> use Axiom. Especially since Axiom is a mess and has had performance
>> issues
>> >>> from the beginning (including using way too much memory as the model
>> is
>> >>> expanded).
>> >>
>> >> 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/
>> >
>> > Just for curiosity, have you done any performance comparison with your
>> > implementation with any other implementation ?
>>
>> Not yet. BTW, do you know of any existing (performance) test suite
>> that tests WS-Security processing in isolation, i.e. without the need
>> for a full SOAP stack (my project is ready for integration with WSS4J,
>> but far from being ready to support Axis2)?
>>
>> > Sanka
>> >
>> >
>> >>
>> >>> Daniel Kulp wrote:
>> >>>>
>> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.
>> The
>> >>>> NodeList stuff isn't even threadsafe in Xerces.
>> >>>
>> >>> Actually, *no* access operations are threadsafe in Xerces. As far as
>> I'm
>> >>> concerned that's a really bad design for general purpose use,
>> ironically
>> >>> going back to the deferred node expansion feature that Xerces has on
>> by
>> >>> default. It's always irked me that I have to use a synchronization
>> lock
>> >>> around read-only operations with a (Xerces) DOM.
>> >>>
>> >>> That said, any form of build-on-demand document model is probably not
>> going
>> >>> to be threadsafe. But for our purposes in using it with web services
>> there's
>> >>> not much need for threadsafety.
>> >>>
>> >>>  - Dennis
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Sanka Samaranayake
>> >
>> > http://sankas.blogspot.com/
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>



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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

hi,

however replacing the following line

SOAPEnvelope env =
Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);

with

SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();

causes some test case failures.

Also we found this info message.

May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
INFO: Verification successful for URI "#id-613"
May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
INFO: Verification successful for URI "#My ticket Id"

thanks,
Amila.





On Wed, May 19, 2010 at 5:23 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

> hi,
>
> We have started looking into rampart performance issues using the bench
> mark provided by Denis.
>
> We did some testing using the current axis2 and rampart trunks with the
> this[1] performance enhancement.
> In this case for small messages both cxf and Axis2 shows similar
> performance values while cxf shows better performance for larger messages.
>
> By looking at the rampart code I found these lines.
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
>         if(dotDebug){
>             t2 = System.currentTimeMillis();
>         }
>
>         //Convert back to llom since the inflow cannot use DOOM
>         msgCtx.setEnvelope(env);
>         Axis2Util.useDOOM(false);
>
> This shows it again builds OM elements which apparently invalidate the use
> of DOOM. I think the whole point of
> DOOM is to use it as a AXIOM as well.
>
> this is documented in rampart developer guide as well.
>
> "When Rampart is engaged and configured, the incoming SOAP messages are
> converted to DOOM. Since DOOM implements the DOM interface it is possible
> for WSS4J to process messages. After performing the security validations,
> before flushing the message down the message inflow, the DOOM SOAP message
> is converted back to OM. At the outgoing flow, the message is converted to
> DOOM and then the security functions are performed using WSS4J."
>
> Thoughts? have I miss something?
>
> thanks,
> Amila.
>
> [1]
> http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html
>
>
> On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com>
>> wrote:
>> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
>> > <an...@gmail.com> wrote:
>> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com>
>> wrote:
>> >>> Yes, I think it'd make much more sense to base a build-on-demand
>> document
>> >>> model on the DOM API than to try to modify all the WSS4J and related
>> code to
>> >>> use Axiom. Especially since Axiom is a mess and has had performance
>> issues
>> >>> from the beginning (including using way too much memory as the model
>> is
>> >>> expanded).
>> >>
>> >> 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/
>> >
>> > Just for curiosity, have you done any performance comparison with your
>> > implementation with any other implementation ?
>>
>> Not yet. BTW, do you know of any existing (performance) test suite
>> that tests WS-Security processing in isolation, i.e. without the need
>> for a full SOAP stack (my project is ready for integration with WSS4J,
>> but far from being ready to support Axis2)?
>>
>> > Sanka
>> >
>> >
>> >>
>> >>> Daniel Kulp wrote:
>> >>>>
>> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.
>> The
>> >>>> NodeList stuff isn't even threadsafe in Xerces.
>> >>>
>> >>> Actually, *no* access operations are threadsafe in Xerces. As far as
>> I'm
>> >>> concerned that's a really bad design for general purpose use,
>> ironically
>> >>> going back to the deferred node expansion feature that Xerces has on
>> by
>> >>> default. It's always irked me that I have to use a synchronization
>> lock
>> >>> around read-only operations with a (Xerces) DOM.
>> >>>
>> >>> That said, any form of build-on-demand document model is probably not
>> going
>> >>> to be threadsafe. But for our purposes in using it with web services
>> there's
>> >>> not much need for threadsafety.
>> >>>
>> >>>  - Dennis
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Sanka Samaranayake
>> >
>> > http://sankas.blogspot.com/
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>



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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

hi,

however replacing the following line

SOAPEnvelope env =
Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);

with

SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();

causes some test case failures.

Also we found this info message.

May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
INFO: Verification successful for URI "#id-613"
May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
INFO: Verification successful for URI "#My ticket Id"

thanks,
Amila.





On Wed, May 19, 2010 at 5:23 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

> hi,
>
> We have started looking into rampart performance issues using the bench
> mark provided by Denis.
>
> We did some testing using the current axis2 and rampart trunks with the
> this[1] performance enhancement.
> In this case for small messages both cxf and Axis2 shows similar
> performance values while cxf shows better performance for larger messages.
>
> By looking at the rampart code I found these lines.
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
>         if(dotDebug){
>             t2 = System.currentTimeMillis();
>         }
>
>         //Convert back to llom since the inflow cannot use DOOM
>         msgCtx.setEnvelope(env);
>         Axis2Util.useDOOM(false);
>
> This shows it again builds OM elements which apparently invalidate the use
> of DOOM. I think the whole point of
> DOOM is to use it as a AXIOM as well.
>
> this is documented in rampart developer guide as well.
>
> "When Rampart is engaged and configured, the incoming SOAP messages are
> converted to DOOM. Since DOOM implements the DOM interface it is possible
> for WSS4J to process messages. After performing the security validations,
> before flushing the message down the message inflow, the DOOM SOAP message
> is converted back to OM. At the outgoing flow, the message is converted to
> DOOM and then the security functions are performed using WSS4J."
>
> Thoughts? have I miss something?
>
> thanks,
> Amila.
>
> [1]
> http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html
>
>
> On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com>
>> wrote:
>> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
>> > <an...@gmail.com> wrote:
>> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com>
>> wrote:
>> >>> Yes, I think it'd make much more sense to base a build-on-demand
>> document
>> >>> model on the DOM API than to try to modify all the WSS4J and related
>> code to
>> >>> use Axiom. Especially since Axiom is a mess and has had performance
>> issues
>> >>> from the beginning (including using way too much memory as the model
>> is
>> >>> expanded).
>> >>
>> >> 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/
>> >
>> > Just for curiosity, have you done any performance comparison with your
>> > implementation with any other implementation ?
>>
>> Not yet. BTW, do you know of any existing (performance) test suite
>> that tests WS-Security processing in isolation, i.e. without the need
>> for a full SOAP stack (my project is ready for integration with WSS4J,
>> but far from being ready to support Axis2)?
>>
>> > Sanka
>> >
>> >
>> >>
>> >>> Daniel Kulp wrote:
>> >>>>
>> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.
>> The
>> >>>> NodeList stuff isn't even threadsafe in Xerces.
>> >>>
>> >>> Actually, *no* access operations are threadsafe in Xerces. As far as
>> I'm
>> >>> concerned that's a really bad design for general purpose use,
>> ironically
>> >>> going back to the deferred node expansion feature that Xerces has on
>> by
>> >>> default. It's always irked me that I have to use a synchronization
>> lock
>> >>> around read-only operations with a (Xerces) DOM.
>> >>>
>> >>> That said, any form of build-on-demand document model is probably not
>> going
>> >>> to be threadsafe. But for our purposes in using it with web services
>> there's
>> >>> not much need for threadsafety.
>> >>>
>> >>>  - Dennis
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Sanka Samaranayake
>> >
>> > http://sankas.blogspot.com/
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>



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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

hi,

however replacing the following line

SOAPEnvelope env =
Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);

with

SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();

causes some test case failures.

Also we found this info message.

May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
INFO: Verification successful for URI "#id-613"
May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify
INFO: Verification successful for URI "#My ticket Id"

thanks,
Amila.





On Wed, May 19, 2010 at 5:23 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

> hi,
>
> We have started looking into rampart performance issues using the bench
> mark provided by Denis.
>
> We did some testing using the current axis2 and rampart trunks with the
> this[1] performance enhancement.
> In this case for small messages both cxf and Axis2 shows similar
> performance values while cxf shows better performance for larger messages.
>
> By looking at the rampart code I found these lines.
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
>         if(dotDebug){
>             t2 = System.currentTimeMillis();
>         }
>
>         //Convert back to llom since the inflow cannot use DOOM
>         msgCtx.setEnvelope(env);
>         Axis2Util.useDOOM(false);
>
> This shows it again builds OM elements which apparently invalidate the use
> of DOOM. I think the whole point of
> DOOM is to use it as a AXIOM as well.
>
> this is documented in rampart developer guide as well.
>
> "When Rampart is engaged and configured, the incoming SOAP messages are
> converted to DOOM. Since DOOM implements the DOM interface it is possible
> for WSS4J to process messages. After performing the security validations,
> before flushing the message down the message inflow, the DOOM SOAP message
> is converted back to OM. At the outgoing flow, the message is converted to
> DOOM and then the security functions are performed using WSS4J."
>
> Thoughts? have I miss something?
>
> thanks,
> Amila.
>
> [1]
> http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html
>
>
> On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com>
>> wrote:
>> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
>> > <an...@gmail.com> wrote:
>> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com>
>> wrote:
>> >>> Yes, I think it'd make much more sense to base a build-on-demand
>> document
>> >>> model on the DOM API than to try to modify all the WSS4J and related
>> code to
>> >>> use Axiom. Especially since Axiom is a mess and has had performance
>> issues
>> >>> from the beginning (including using way too much memory as the model
>> is
>> >>> expanded).
>> >>
>> >> 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/
>> >
>> > Just for curiosity, have you done any performance comparison with your
>> > implementation with any other implementation ?
>>
>> Not yet. BTW, do you know of any existing (performance) test suite
>> that tests WS-Security processing in isolation, i.e. without the need
>> for a full SOAP stack (my project is ready for integration with WSS4J,
>> but far from being ready to support Axis2)?
>>
>> > Sanka
>> >
>> >
>> >>
>> >>> Daniel Kulp wrote:
>> >>>>
>> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.
>> The
>> >>>> NodeList stuff isn't even threadsafe in Xerces.
>> >>>
>> >>> Actually, *no* access operations are threadsafe in Xerces. As far as
>> I'm
>> >>> concerned that's a really bad design for general purpose use,
>> ironically
>> >>> going back to the deferred node expansion feature that Xerces has on
>> by
>> >>> default. It's always irked me that I have to use a synchronization
>> lock
>> >>> around read-only operations with a (Xerces) DOM.
>> >>>
>> >>> That said, any form of build-on-demand document model is probably not
>> going
>> >>> to be threadsafe. But for our purposes in using it with web services
>> there's
>> >>> not much need for threadsafety.
>> >>>
>> >>>  - Dennis
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Sanka Samaranayake
>> >
>> > http://sankas.blogspot.com/
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>



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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

hi,

We have started looking into rampart performance issues using the bench mark
provided by Denis.

We did some testing using the current axis2 and rampart trunks with the
this[1] performance enhancement.
In this case for small messages both cxf and Axis2 shows similar performance
values while cxf shows better performance for larger messages.

By looking at the rampart code I found these lines.

SOAPEnvelope env =
Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);

        if(dotDebug){
            t2 = System.currentTimeMillis();
        }

        //Convert back to llom since the inflow cannot use DOOM
        msgCtx.setEnvelope(env);
        Axis2Util.useDOOM(false);

This shows it again builds OM elements which apparently invalidate the use
of DOOM. I think the whole point of
DOOM is to use it as a AXIOM as well.

this is documented in rampart developer guide as well.

"When Rampart is engaged and configured, the incoming SOAP messages are
converted to DOOM. Since DOOM implements the DOM interface it is possible
for WSS4J to process messages. After performing the security validations,
before flushing the message down the message inflow, the DOOM SOAP message
is converted back to OM. At the outgoing flow, the message is converted to
DOOM and then the security functions are performed using WSS4J."

Thoughts? have I miss something?

thanks,
Amila.

[1]
http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html

On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen
<an...@gmail.com>wrote:

> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com> wrote:
> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> > <an...@gmail.com> wrote:
> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >>> Yes, I think it'd make much more sense to base a build-on-demand
> document
> >>> model on the DOM API than to try to modify all the WSS4J and related
> code to
> >>> use Axiom. Especially since Axiom is a mess and has had performance
> issues
> >>> from the beginning (including using way too much memory as the model is
> >>> expanded).
> >>
> >> 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/
> >
> > Just for curiosity, have you done any performance comparison with your
> > implementation with any other implementation ?
>
> Not yet. BTW, do you know of any existing (performance) test suite
> that tests WS-Security processing in isolation, i.e. without the need
> for a full SOAP stack (my project is ready for integration with WSS4J,
> but far from being ready to support Axis2)?
>
> > Sanka
> >
> >
> >>
> >>> Daniel Kulp wrote:
> >>>>
> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.
> The
> >>>> NodeList stuff isn't even threadsafe in Xerces.
> >>>
> >>> Actually, *no* access operations are threadsafe in Xerces. As far as
> I'm
> >>> concerned that's a really bad design for general purpose use,
> ironically
> >>> going back to the deferred node expansion feature that Xerces has on by
> >>> default. It's always irked me that I have to use a synchronization lock
> >>> around read-only operations with a (Xerces) DOM.
> >>>
> >>> That said, any form of build-on-demand document model is probably not
> going
> >>> to be threadsafe. But for our purposes in using it with web services
> there's
> >>> not much need for threadsafety.
> >>>
> >>>  - Dennis
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> >
> >
> >
> > --
> > Sanka Samaranayake
> >
> > http://sankas.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > 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
>
>


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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

hi,

We have started looking into rampart performance issues using the bench mark
provided by Denis.

We did some testing using the current axis2 and rampart trunks with the
this[1] performance enhancement.
In this case for small messages both cxf and Axis2 shows similar performance
values while cxf shows better performance for larger messages.

By looking at the rampart code I found these lines.

SOAPEnvelope env =
Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);

        if(dotDebug){
            t2 = System.currentTimeMillis();
        }

        //Convert back to llom since the inflow cannot use DOOM
        msgCtx.setEnvelope(env);
        Axis2Util.useDOOM(false);

This shows it again builds OM elements which apparently invalidate the use
of DOOM. I think the whole point of
DOOM is to use it as a AXIOM as well.

this is documented in rampart developer guide as well.

"When Rampart is engaged and configured, the incoming SOAP messages are
converted to DOOM. Since DOOM implements the DOM interface it is possible
for WSS4J to process messages. After performing the security validations,
before flushing the message down the message inflow, the DOOM SOAP message
is converted back to OM. At the outgoing flow, the message is converted to
DOOM and then the security functions are performed using WSS4J."

Thoughts? have I miss something?

thanks,
Amila.

[1]
http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html

On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen
<an...@gmail.com>wrote:

> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com> wrote:
> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> > <an...@gmail.com> wrote:
> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >>> Yes, I think it'd make much more sense to base a build-on-demand
> document
> >>> model on the DOM API than to try to modify all the WSS4J and related
> code to
> >>> use Axiom. Especially since Axiom is a mess and has had performance
> issues
> >>> from the beginning (including using way too much memory as the model is
> >>> expanded).
> >>
> >> 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/
> >
> > Just for curiosity, have you done any performance comparison with your
> > implementation with any other implementation ?
>
> Not yet. BTW, do you know of any existing (performance) test suite
> that tests WS-Security processing in isolation, i.e. without the need
> for a full SOAP stack (my project is ready for integration with WSS4J,
> but far from being ready to support Axis2)?
>
> > Sanka
> >
> >
> >>
> >>> Daniel Kulp wrote:
> >>>>
> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.
> The
> >>>> NodeList stuff isn't even threadsafe in Xerces.
> >>>
> >>> Actually, *no* access operations are threadsafe in Xerces. As far as
> I'm
> >>> concerned that's a really bad design for general purpose use,
> ironically
> >>> going back to the deferred node expansion feature that Xerces has on by
> >>> default. It's always irked me that I have to use a synchronization lock
> >>> around read-only operations with a (Xerces) DOM.
> >>>
> >>> That said, any form of build-on-demand document model is probably not
> going
> >>> to be threadsafe. But for our purposes in using it with web services
> there's
> >>> not much need for threadsafety.
> >>>
> >>>  - Dennis
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> >
> >
> >
> > --
> > Sanka Samaranayake
> >
> > http://sankas.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > 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
>
>


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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

hi,

We have started looking into rampart performance issues using the bench mark
provided by Denis.

We did some testing using the current axis2 and rampart trunks with the
this[1] performance enhancement.
In this case for small messages both cxf and Axis2 shows similar performance
values while cxf shows better performance for larger messages.

By looking at the rampart code I found these lines.

SOAPEnvelope env =
Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);

        if(dotDebug){
            t2 = System.currentTimeMillis();
        }

        //Convert back to llom since the inflow cannot use DOOM
        msgCtx.setEnvelope(env);
        Axis2Util.useDOOM(false);

This shows it again builds OM elements which apparently invalidate the use
of DOOM. I think the whole point of
DOOM is to use it as a AXIOM as well.

this is documented in rampart developer guide as well.

"When Rampart is engaged and configured, the incoming SOAP messages are
converted to DOOM. Since DOOM implements the DOM interface it is possible
for WSS4J to process messages. After performing the security validations,
before flushing the message down the message inflow, the DOOM SOAP message
is converted back to OM. At the outgoing flow, the message is converted to
DOOM and then the security functions are performed using WSS4J."

Thoughts? have I miss something?

thanks,
Amila.

[1]
http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html

On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen
<an...@gmail.com>wrote:

> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com> wrote:
> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> > <an...@gmail.com> wrote:
> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >>> Yes, I think it'd make much more sense to base a build-on-demand
> document
> >>> model on the DOM API than to try to modify all the WSS4J and related
> code to
> >>> use Axiom. Especially since Axiom is a mess and has had performance
> issues
> >>> from the beginning (including using way too much memory as the model is
> >>> expanded).
> >>
> >> 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/
> >
> > Just for curiosity, have you done any performance comparison with your
> > implementation with any other implementation ?
>
> Not yet. BTW, do you know of any existing (performance) test suite
> that tests WS-Security processing in isolation, i.e. without the need
> for a full SOAP stack (my project is ready for integration with WSS4J,
> but far from being ready to support Axis2)?
>
> > Sanka
> >
> >
> >>
> >>> Daniel Kulp wrote:
> >>>>
> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.
> The
> >>>> NodeList stuff isn't even threadsafe in Xerces.
> >>>
> >>> Actually, *no* access operations are threadsafe in Xerces. As far as
> I'm
> >>> concerned that's a really bad design for general purpose use,
> ironically
> >>> going back to the deferred node expansion feature that Xerces has on by
> >>> default. It's always irked me that I have to use a synchronization lock
> >>> around read-only operations with a (Xerces) DOM.
> >>>
> >>> That said, any form of build-on-demand document model is probably not
> going
> >>> to be threadsafe. But for our purposes in using it with web services
> there's
> >>> not much need for threadsafety.
> >>>
> >>>  - Dennis
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> >
> >
> >
> > --
> > Sanka Samaranayake
> >
> > http://sankas.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > 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
>
>


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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

hi,

We have started looking into rampart performance issues using the bench mark
provided by Denis.

We did some testing using the current axis2 and rampart trunks with the
this[1] performance enhancement.
In this case for small messages both cxf and Axis2 shows similar performance
values while cxf shows better performance for larger messages.

By looking at the rampart code I found these lines.

SOAPEnvelope env =
Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);

        if(dotDebug){
            t2 = System.currentTimeMillis();
        }

        //Convert back to llom since the inflow cannot use DOOM
        msgCtx.setEnvelope(env);
        Axis2Util.useDOOM(false);

This shows it again builds OM elements which apparently invalidate the use
of DOOM. I think the whole point of
DOOM is to use it as a AXIOM as well.

this is documented in rampart developer guide as well.

"When Rampart is engaged and configured, the incoming SOAP messages are
converted to DOOM. Since DOOM implements the DOM interface it is possible
for WSS4J to process messages. After performing the security validations,
before flushing the message down the message inflow, the DOOM SOAP message
is converted back to OM. At the outgoing flow, the message is converted to
DOOM and then the security functions are performed using WSS4J."

Thoughts? have I miss something?

thanks,
Amila.

[1]
http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html

On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen
<an...@gmail.com>wrote:

> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com> wrote:
> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> > <an...@gmail.com> wrote:
> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >>> Yes, I think it'd make much more sense to base a build-on-demand
> document
> >>> model on the DOM API than to try to modify all the WSS4J and related
> code to
> >>> use Axiom. Especially since Axiom is a mess and has had performance
> issues
> >>> from the beginning (including using way too much memory as the model is
> >>> expanded).
> >>
> >> 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/
> >
> > Just for curiosity, have you done any performance comparison with your
> > implementation with any other implementation ?
>
> Not yet. BTW, do you know of any existing (performance) test suite
> that tests WS-Security processing in isolation, i.e. without the need
> for a full SOAP stack (my project is ready for integration with WSS4J,
> but far from being ready to support Axis2)?
>
> > Sanka
> >
> >
> >>
> >>> Daniel Kulp wrote:
> >>>>
> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.
> The
> >>>> NodeList stuff isn't even threadsafe in Xerces.
> >>>
> >>> Actually, *no* access operations are threadsafe in Xerces. As far as
> I'm
> >>> concerned that's a really bad design for general purpose use,
> ironically
> >>> going back to the deferred node expansion feature that Xerces has on by
> >>> default. It's always irked me that I have to use a synchronization lock
> >>> around read-only operations with a (Xerces) DOM.
> >>>
> >>> That said, any form of build-on-demand document model is probably not
> going
> >>> to be threadsafe. But for our purposes in using it with web services
> there's
> >>> not much need for threadsafety.
> >>>
> >>>  - Dennis
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> >
> >
> >
> > --
> > Sanka Samaranayake
> >
> > http://sankas.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > 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
>
>


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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

hi,

We have started looking into rampart performance issues using the bench mark
provided by Denis.

We did some testing using the current axis2 and rampart trunks with the
this[1] performance enhancement.
In this case for small messages both cxf and Axis2 shows similar performance
values while cxf shows better performance for larger messages.

By looking at the rampart code I found these lines.

SOAPEnvelope env =
Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);

        if(dotDebug){
            t2 = System.currentTimeMillis();
        }

        //Convert back to llom since the inflow cannot use DOOM
        msgCtx.setEnvelope(env);
        Axis2Util.useDOOM(false);

This shows it again builds OM elements which apparently invalidate the use
of DOOM. I think the whole point of
DOOM is to use it as a AXIOM as well.

this is documented in rampart developer guide as well.

"When Rampart is engaged and configured, the incoming SOAP messages are
converted to DOOM. Since DOOM implements the DOM interface it is possible
for WSS4J to process messages. After performing the security validations,
before flushing the message down the message inflow, the DOOM SOAP message
is converted back to OM. At the outgoing flow, the message is converted to
DOOM and then the security functions are performed using WSS4J."

Thoughts? have I miss something?

thanks,
Amila.

[1]
http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html

On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen
<an...@gmail.com>wrote:

> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com> wrote:
> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> > <an...@gmail.com> wrote:
> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >>> Yes, I think it'd make much more sense to base a build-on-demand
> document
> >>> model on the DOM API than to try to modify all the WSS4J and related
> code to
> >>> use Axiom. Especially since Axiom is a mess and has had performance
> issues
> >>> from the beginning (including using way too much memory as the model is
> >>> expanded).
> >>
> >> 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/
> >
> > Just for curiosity, have you done any performance comparison with your
> > implementation with any other implementation ?
>
> Not yet. BTW, do you know of any existing (performance) test suite
> that tests WS-Security processing in isolation, i.e. without the need
> for a full SOAP stack (my project is ready for integration with WSS4J,
> but far from being ready to support Axis2)?
>
> > Sanka
> >
> >
> >>
> >>> Daniel Kulp wrote:
> >>>>
> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.
> The
> >>>> NodeList stuff isn't even threadsafe in Xerces.
> >>>
> >>> Actually, *no* access operations are threadsafe in Xerces. As far as
> I'm
> >>> concerned that's a really bad design for general purpose use,
> ironically
> >>> going back to the deferred node expansion feature that Xerces has on by
> >>> default. It's always irked me that I have to use a synchronization lock
> >>> around read-only operations with a (Xerces) DOM.
> >>>
> >>> That said, any form of build-on-demand document model is probably not
> going
> >>> to be threadsafe. But for our purposes in using it with web services
> there's
> >>> not much need for threadsafety.
> >>>
> >>>  - Dennis
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> >
> >
> >
> > --
> > Sanka Samaranayake
> >
> > http://sankas.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > 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
>
>


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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com> wrote:
> On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> <an...@gmail.com> wrote:
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>> Yes, I think it'd make much more sense to base a build-on-demand document
>>> model on the DOM API than to try to modify all the WSS4J and related code to
>>> use Axiom. Especially since Axiom is a mess and has had performance issues
>>> from the beginning (including using way too much memory as the model is
>>> expanded).
>>
>> 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/
>
> Just for curiosity, have you done any performance comparison with your
> implementation with any other implementation ?

Not yet. BTW, do you know of any existing (performance) test suite
that tests WS-Security processing in isolation, i.e. without the need
for a full SOAP stack (my project is ready for integration with WSS4J,
but far from being ready to support Axis2)?

> Sanka
>
>
>>
>>> Daniel Kulp wrote:
>>>>
>>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>>> NodeList stuff isn't even threadsafe in Xerces.
>>>
>>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>>> concerned that's a really bad design for general purpose use, ironically
>>> going back to the deferred node expansion feature that Xerces has on by
>>> default. It's always irked me that I have to use a synchronization lock
>>> around read-only operations with a (Xerces) DOM.
>>>
>>> That said, any form of build-on-demand document model is probably not going
>>> to be threadsafe. But for our purposes in using it with web services there's
>>> not much need for threadsafety.
>>>
>>>  - Dennis
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
>
> --
> Sanka Samaranayake
>
> http://sankas.blogspot.com/
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com> wrote:
> On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> <an...@gmail.com> wrote:
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>> Yes, I think it'd make much more sense to base a build-on-demand document
>>> model on the DOM API than to try to modify all the WSS4J and related code to
>>> use Axiom. Especially since Axiom is a mess and has had performance issues
>>> from the beginning (including using way too much memory as the model is
>>> expanded).
>>
>> 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/
>
> Just for curiosity, have you done any performance comparison with your
> implementation with any other implementation ?

Not yet. BTW, do you know of any existing (performance) test suite
that tests WS-Security processing in isolation, i.e. without the need
for a full SOAP stack (my project is ready for integration with WSS4J,
but far from being ready to support Axis2)?

> Sanka
>
>
>>
>>> Daniel Kulp wrote:
>>>>
>>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>>> NodeList stuff isn't even threadsafe in Xerces.
>>>
>>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>>> concerned that's a really bad design for general purpose use, ironically
>>> going back to the deferred node expansion feature that Xerces has on by
>>> default. It's always irked me that I have to use a synchronization lock
>>> around read-only operations with a (Xerces) DOM.
>>>
>>> That said, any form of build-on-demand document model is probably not going
>>> to be threadsafe. But for our purposes in using it with web services there's
>>> not much need for threadsafety.
>>>
>>>  - Dennis
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
>
> --
> Sanka Samaranayake
>
> http://sankas.blogspot.com/
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com> wrote:
> On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> <an...@gmail.com> wrote:
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>> Yes, I think it'd make much more sense to base a build-on-demand document
>>> model on the DOM API than to try to modify all the WSS4J and related code to
>>> use Axiom. Especially since Axiom is a mess and has had performance issues
>>> from the beginning (including using way too much memory as the model is
>>> expanded).
>>
>> 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/
>
> Just for curiosity, have you done any performance comparison with your
> implementation with any other implementation ?

Not yet. BTW, do you know of any existing (performance) test suite
that tests WS-Security processing in isolation, i.e. without the need
for a full SOAP stack (my project is ready for integration with WSS4J,
but far from being ready to support Axis2)?

> Sanka
>
>
>>
>>> Daniel Kulp wrote:
>>>>
>>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>>> NodeList stuff isn't even threadsafe in Xerces.
>>>
>>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>>> concerned that's a really bad design for general purpose use, ironically
>>> going back to the deferred node expansion feature that Xerces has on by
>>> default. It's always irked me that I have to use a synchronization lock
>>> around read-only operations with a (Xerces) DOM.
>>>
>>> That said, any form of build-on-demand document model is probably not going
>>> to be threadsafe. But for our purposes in using it with web services there's
>>> not much need for threadsafety.
>>>
>>>  - Dennis
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
>
> --
> Sanka Samaranayake
>
> http://sankas.blogspot.com/
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com> wrote:
> On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> <an...@gmail.com> wrote:
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>> Yes, I think it'd make much more sense to base a build-on-demand document
>>> model on the DOM API than to try to modify all the WSS4J and related code to
>>> use Axiom. Especially since Axiom is a mess and has had performance issues
>>> from the beginning (including using way too much memory as the model is
>>> expanded).
>>
>> 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/
>
> Just for curiosity, have you done any performance comparison with your
> implementation with any other implementation ?

Not yet. BTW, do you know of any existing (performance) test suite
that tests WS-Security processing in isolation, i.e. without the need
for a full SOAP stack (my project is ready for integration with WSS4J,
but far from being ready to support Axis2)?

> Sanka
>
>
>>
>>> Daniel Kulp wrote:
>>>>
>>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>>> NodeList stuff isn't even threadsafe in Xerces.
>>>
>>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>>> concerned that's a really bad design for general purpose use, ironically
>>> going back to the deferred node expansion feature that Xerces has on by
>>> default. It's always irked me that I have to use a synchronization lock
>>> around read-only operations with a (Xerces) DOM.
>>>
>>> That said, any form of build-on-demand document model is probably not going
>>> to be threadsafe. But for our purposes in using it with web services there's
>>> not much need for threadsafety.
>>>
>>>  - Dennis
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
>
> --
> Sanka Samaranayake
>
> http://sankas.blogspot.com/
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <ss...@gmail.com> wrote:
> On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> <an...@gmail.com> wrote:
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>> Yes, I think it'd make much more sense to base a build-on-demand document
>>> model on the DOM API than to try to modify all the WSS4J and related code to
>>> use Axiom. Especially since Axiom is a mess and has had performance issues
>>> from the beginning (including using way too much memory as the model is
>>> expanded).
>>
>> 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/
>
> Just for curiosity, have you done any performance comparison with your
> implementation with any other implementation ?

Not yet. BTW, do you know of any existing (performance) test suite
that tests WS-Security processing in isolation, i.e. without the need
for a full SOAP stack (my project is ready for integration with WSS4J,
but far from being ready to support Axis2)?

> Sanka
>
>
>>
>>> Daniel Kulp wrote:
>>>>
>>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>>> NodeList stuff isn't even threadsafe in Xerces.
>>>
>>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>>> concerned that's a really bad design for general purpose use, ironically
>>> going back to the deferred node expansion feature that Xerces has on by
>>> default. It's always irked me that I have to use a synchronization lock
>>> around read-only operations with a (Xerces) DOM.
>>>
>>> That said, any form of build-on-demand document model is probably not going
>>> to be threadsafe. But for our purposes in using it with web services there's
>>> not much need for threadsafety.
>>>
>>>  - Dennis
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
>
> --
> Sanka Samaranayake
>
> http://sankas.blogspot.com/
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Sanka Samaranayake <ss...@gmail.com>]

On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>> Yes, I think it'd make much more sense to base a build-on-demand document
>> model on the DOM API than to try to modify all the WSS4J and related code to
>> use Axiom. Especially since Axiom is a mess and has had performance issues
>> from the beginning (including using way too much memory as the model is
>> expanded).
>
> 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/

Just for curiosity, have you done any performance comparison with your
implementation with any other implementation ?

Sanka


>
>> Daniel Kulp wrote:
>>>
>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>> NodeList stuff isn't even threadsafe in Xerces.
>>
>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>> concerned that's a really bad design for general purpose use, ironically
>> going back to the deferred node expansion feature that Xerces has on by
>> default. It's always irked me that I have to use a synchronization lock
>> around read-only operations with a (Xerces) DOM.
>>
>> That said, any form of build-on-demand document model is probably not going
>> to be threadsafe. But for our purposes in using it with web services there's
>> not much need for threadsafety.
>>
>>  - Dennis
>>
>> ---------------------------------------------------------------------
>> 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
>
>



-- 
Sanka Samaranayake

http://sankas.blogspot.com/

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

Re: Performance Comparison

[Sanka Samaranayake <ss...@gmail.com>]

On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>> Yes, I think it'd make much more sense to base a build-on-demand document
>> model on the DOM API than to try to modify all the WSS4J and related code to
>> use Axiom. Especially since Axiom is a mess and has had performance issues
>> from the beginning (including using way too much memory as the model is
>> expanded).
>
> 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/

Just for curiosity, have you done any performance comparison with your
implementation with any other implementation ?

Sanka


>
>> Daniel Kulp wrote:
>>>
>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>> NodeList stuff isn't even threadsafe in Xerces.
>>
>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>> concerned that's a really bad design for general purpose use, ironically
>> going back to the deferred node expansion feature that Xerces has on by
>> default. It's always irked me that I have to use a synchronization lock
>> around read-only operations with a (Xerces) DOM.
>>
>> That said, any form of build-on-demand document model is probably not going
>> to be threadsafe. But for our purposes in using it with web services there's
>> not much need for threadsafety.
>>
>>  - Dennis
>>
>> ---------------------------------------------------------------------
>> 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
>
>



-- 
Sanka Samaranayake

http://sankas.blogspot.com/

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

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



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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

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



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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

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



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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Andreas Veithen wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@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

Re: Performance Comparison

[Sanka Samaranayake <ss...@gmail.com>]

On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>> Yes, I think it'd make much more sense to base a build-on-demand document
>> model on the DOM API than to try to modify all the WSS4J and related code to
>> use Axiom. Especially since Axiom is a mess and has had performance issues
>> from the beginning (including using way too much memory as the model is
>> expanded).
>
> 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/

Just for curiosity, have you done any performance comparison with your
implementation with any other implementation ?

Sanka


>
>> Daniel Kulp wrote:
>>>
>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>> NodeList stuff isn't even threadsafe in Xerces.
>>
>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>> concerned that's a really bad design for general purpose use, ironically
>> going back to the deferred node expansion feature that Xerces has on by
>> default. It's always irked me that I have to use a synchronization lock
>> around read-only operations with a (Xerces) DOM.
>>
>> That said, any form of build-on-demand document model is probably not going
>> to be threadsafe. But for our purposes in using it with web services there's
>> not much need for threadsafety.
>>
>>  - Dennis
>>
>> ---------------------------------------------------------------------
>> 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
>
>



-- 
Sanka Samaranayake

http://sankas.blogspot.com/

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

Re: Performance Comparison

[Sanka Samaranayake <ss...@gmail.com>]

On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>> Yes, I think it'd make much more sense to base a build-on-demand document
>> model on the DOM API than to try to modify all the WSS4J and related code to
>> use Axiom. Especially since Axiom is a mess and has had performance issues
>> from the beginning (including using way too much memory as the model is
>> expanded).
>
> 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/

Just for curiosity, have you done any performance comparison with your
implementation with any other implementation ?

Sanka


>
>> Daniel Kulp wrote:
>>>
>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>> NodeList stuff isn't even threadsafe in Xerces.
>>
>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>> concerned that's a really bad design for general purpose use, ironically
>> going back to the deferred node expansion feature that Xerces has on by
>> default. It's always irked me that I have to use a synchronization lock
>> around read-only operations with a (Xerces) DOM.
>>
>> That said, any form of build-on-demand document model is probably not going
>> to be threadsafe. But for our purposes in using it with web services there's
>> not much need for threadsafety.
>>
>>  - Dennis
>>
>> ---------------------------------------------------------------------
>> 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
>
>



-- 
Sanka Samaranayake

http://sankas.blogspot.com/

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

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



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

Re: Performance Comparison

[Sanka Samaranayake <ss...@gmail.com>]

On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>> Yes, I think it'd make much more sense to base a build-on-demand document
>> model on the DOM API than to try to modify all the WSS4J and related code to
>> use Axiom. Especially since Axiom is a mess and has had performance issues
>> from the beginning (including using way too much memory as the model is
>> expanded).
>
> 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/

Just for curiosity, have you done any performance comparison with your
implementation with any other implementation ?

Sanka


>
>> Daniel Kulp wrote:
>>>
>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>> NodeList stuff isn't even threadsafe in Xerces.
>>
>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>> concerned that's a really bad design for general purpose use, ironically
>> going back to the deferred node expansion feature that Xerces has on by
>> default. It's always irked me that I have to use a synchronization lock
>> around read-only operations with a (Xerces) DOM.
>>
>> That said, any form of build-on-demand document model is probably not going
>> to be threadsafe. But for our purposes in using it with web services there's
>> not much need for threadsafety.
>>
>>  - Dennis
>>
>> ---------------------------------------------------------------------
>> 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
>
>



-- 
Sanka Samaranayake

http://sankas.blogspot.com/

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

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



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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Yes, I think it'd make much more sense to base a build-on-demand document
> model on the DOM API than to try to modify all the WSS4J and related code to
> use Axiom. Especially since Axiom is a mess and has had performance issues
> from the beginning (including using way too much memory as the model is
> expanded).

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/

> Daniel Kulp wrote:
>>
>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>> NodeList stuff isn't even threadsafe in Xerces.
>
> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
> concerned that's a really bad design for general purpose use, ironically
> going back to the deferred node expansion feature that Xerces has on by
> default. It's always irked me that I have to use a synchronization lock
> around read-only operations with a (Xerces) DOM.
>
> That said, any form of build-on-demand document model is probably not going
> to be threadsafe. But for our purposes in using it with web services there's
> not much need for threadsafety.
>
>  - Dennis
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Yes, I think it'd make much more sense to base a build-on-demand document
> model on the DOM API than to try to modify all the WSS4J and related code to
> use Axiom. Especially since Axiom is a mess and has had performance issues
> from the beginning (including using way too much memory as the model is
> expanded).

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/

> Daniel Kulp wrote:
>>
>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>> NodeList stuff isn't even threadsafe in Xerces.
>
> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
> concerned that's a really bad design for general purpose use, ironically
> going back to the deferred node expansion feature that Xerces has on by
> default. It's always irked me that I have to use a synchronization lock
> around read-only operations with a (Xerces) DOM.
>
> That said, any form of build-on-demand document model is probably not going
> to be threadsafe. But for our purposes in using it with web services there's
> not much need for threadsafety.
>
>  - Dennis
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Yes, I think it'd make much more sense to base a build-on-demand document
> model on the DOM API than to try to modify all the WSS4J and related code to
> use Axiom. Especially since Axiom is a mess and has had performance issues
> from the beginning (including using way too much memory as the model is
> expanded).

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/

> Daniel Kulp wrote:
>>
>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>> NodeList stuff isn't even threadsafe in Xerces.
>
> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
> concerned that's a really bad design for general purpose use, ironically
> going back to the deferred node expansion feature that Xerces has on by
> default. It's always irked me that I have to use a synchronization lock
> around read-only operations with a (Xerces) DOM.
>
> That said, any form of build-on-demand document model is probably not going
> to be threadsafe. But for our purposes in using it with web services there's
> not much need for threadsafety.
>
>  - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Yes, I think it'd make much more sense to base a build-on-demand document
> model on the DOM API than to try to modify all the WSS4J and related code to
> use Axiom. Especially since Axiom is a mess and has had performance issues
> from the beginning (including using way too much memory as the model is
> expanded).

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/

> Daniel Kulp wrote:
>>
>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>> NodeList stuff isn't even threadsafe in Xerces.
>
> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
> concerned that's a really bad design for general purpose use, ironically
> going back to the deferred node expansion feature that Xerces has on by
> default. It's always irked me that I have to use a synchronization lock
> around read-only operations with a (Xerces) DOM.
>
> That said, any form of build-on-demand document model is probably not going
> to be threadsafe. But for our purposes in using it with web services there's
> not much need for threadsafety.
>
>  - Dennis
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Yes, I think it'd make much more sense to base a build-on-demand document
> model on the DOM API than to try to modify all the WSS4J and related code to
> use Axiom. Especially since Axiom is a mess and has had performance issues
> from the beginning (including using way too much memory as the model is
> expanded).

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/

> Daniel Kulp wrote:
>>
>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>> NodeList stuff isn't even threadsafe in Xerces.
>
> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
> concerned that's a really bad design for general purpose use, ironically
> going back to the deferred node expansion feature that Xerces has on by
> default. It's always irked me that I have to use a synchronization lock
> around read-only operations with a (Xerces) DOM.
>
> That said, any form of build-on-demand document model is probably not going
> to be threadsafe. But for our purposes in using it with web services there's
> not much need for threadsafety.
>
>  - Dennis
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Yes, I think it'd make much more sense to base a build-on-demand document
> model on the DOM API than to try to modify all the WSS4J and related code to
> use Axiom. Especially since Axiom is a mess and has had performance issues
> from the beginning (including using way too much memory as the model is
> expanded).

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/

> Daniel Kulp wrote:
>>
>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>> NodeList stuff isn't even threadsafe in Xerces.
>
> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
> concerned that's a really bad design for general purpose use, ironically
> going back to the deferred node expansion feature that Xerces has on by
> default. It's always irked me that I have to use a synchronization lock
> around read-only operations with a (Xerces) DOM.
>
> That said, any form of build-on-demand document model is probably not going
> to be threadsafe. But for our purposes in using it with web services there's
> not much need for threadsafety.
>
>  - Dennis
>
> ---------------------------------------------------------------------
> 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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Yes, I think it'd make much more sense to base a build-on-demand document
> model on the DOM API than to try to modify all the WSS4J and related code to
> use Axiom. Especially since Axiom is a mess and has had performance issues
> from the beginning (including using way too much memory as the model is
> expanded).

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/

> Daniel Kulp wrote:
>>
>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>> NodeList stuff isn't even threadsafe in Xerces.
>
> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
> concerned that's a really bad design for general purpose use, ironically
> going back to the deferred node expansion feature that Xerces has on by
> default. It's always irked me that I have to use a synchronization lock
> around read-only operations with a (Xerces) DOM.
>
> That said, any form of build-on-demand document model is probably not going
> to be threadsafe. But for our purposes in using it with web services there's
> not much need for threadsafety.
>
>  - Dennis
>
> ---------------------------------------------------------------------
> 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Yes, I think it'd make much more sense to base a build-on-demand 
document model on the DOM API than to try to modify all the WSS4J and 
related code to use Axiom. Especially since Axiom is a mess and has had 
performance issues from the beginning (including using way too much 
memory as the model is expanded).

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).

Daniel Kulp wrote:
>
> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The 
> NodeList stuff isn't even threadsafe in Xerces.

Actually, *no* access operations are threadsafe in Xerces. As far as I'm 
concerned that's a really bad design for general purpose use, ironically 
going back to the deferred node expansion feature that Xerces has on by 
default. It's always irked me that I have to use a synchronization lock 
around read-only operations with a (Xerces) DOM.

That said, any form of build-on-demand document model is probably not 
going to be threadsafe. But for our purposes in using it with web 
services there's not much need for threadsafety.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Yes, I think it'd make much more sense to base a build-on-demand 
document model on the DOM API than to try to modify all the WSS4J and 
related code to use Axiom. Especially since Axiom is a mess and has had 
performance issues from the beginning (including using way too much 
memory as the model is expanded).

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).

Daniel Kulp wrote:
>
> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The 
> NodeList stuff isn't even threadsafe in Xerces.

Actually, *no* access operations are threadsafe in Xerces. As far as I'm 
concerned that's a really bad design for general purpose use, ironically 
going back to the deferred node expansion feature that Xerces has on by 
default. It's always irked me that I have to use a synchronization lock 
around read-only operations with a (Xerces) DOM.

That said, any form of build-on-demand document model is probably not 
going to be threadsafe. But for our purposes in using it with web 
services there's not much need for threadsafety.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Yes, I think it'd make much more sense to base a build-on-demand 
document model on the DOM API than to try to modify all the WSS4J and 
related code to use Axiom. Especially since Axiom is a mess and has had 
performance issues from the beginning (including using way too much 
memory as the model is expanded).

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).

Daniel Kulp wrote:
>
> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The 
> NodeList stuff isn't even threadsafe in Xerces.

Actually, *no* access operations are threadsafe in Xerces. As far as I'm 
concerned that's a really bad design for general purpose use, ironically 
going back to the deferred node expansion feature that Xerces has on by 
default. It's always irked me that I have to use a synchronization lock 
around read-only operations with a (Xerces) DOM.

That said, any form of build-on-demand document model is probably not 
going to be threadsafe. But for our purposes in using it with web 
services there's not much need for threadsafety.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Yes, I think it'd make much more sense to base a build-on-demand 
document model on the DOM API than to try to modify all the WSS4J and 
related code to use Axiom. Especially since Axiom is a mess and has had 
performance issues from the beginning (including using way too much 
memory as the model is expanded).

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).

Daniel Kulp wrote:
>
> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The 
> NodeList stuff isn't even threadsafe in Xerces.

Actually, *no* access operations are threadsafe in Xerces. As far as I'm 
concerned that's a really bad design for general purpose use, ironically 
going back to the deferred node expansion feature that Xerces has on by 
default. It's always irked me that I have to use a synchronization lock 
around read-only operations with a (Xerces) DOM.

That said, any form of build-on-demand document model is probably not 
going to be threadsafe. But for our purposes in using it with web 
services there's not much need for threadsafety.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Yes, I think it'd make much more sense to base a build-on-demand 
document model on the DOM API than to try to modify all the WSS4J and 
related code to use Axiom. Especially since Axiom is a mess and has had 
performance issues from the beginning (including using way too much 
memory as the model is expanded).

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).

Daniel Kulp wrote:
>
> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The 
> NodeList stuff isn't even threadsafe in Xerces.

Actually, *no* access operations are threadsafe in Xerces. As far as I'm 
concerned that's a really bad design for general purpose use, ironically 
going back to the deferred node expansion feature that Xerces has on by 
default. It's always irked me that I have to use a synchronization lock 
around read-only operations with a (Xerces) DOM.

That said, any form of build-on-demand document model is probably not 
going to be threadsafe. But for our purposes in using it with web 
services there's not much need for threadsafety.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Yes, I think it'd make much more sense to base a build-on-demand 
document model on the DOM API than to try to modify all the WSS4J and 
related code to use Axiom. Especially since Axiom is a mess and has had 
performance issues from the beginning (including using way too much 
memory as the model is expanded).

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).

Daniel Kulp wrote:
>
> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The 
> NodeList stuff isn't even threadsafe in Xerces.

Actually, *no* access operations are threadsafe in Xerces. As far as I'm 
concerned that's a really bad design for general purpose use, ironically 
going back to the deferred node expansion feature that Xerces has on by 
default. It's always irked me that I have to use a synchronization lock 
around read-only operations with a (Xerces) DOM.

That said, any form of build-on-demand document model is probably not 
going to be threadsafe. But for our purposes in using it with web 
services there's not much need for threadsafety.

  - Dennis

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

Yes, I think it'd make much more sense to base a build-on-demand 
document model on the DOM API than to try to modify all the WSS4J and 
related code to use Axiom. Especially since Axiom is a mess and has had 
performance issues from the beginning (including using way too much 
memory as the model is expanded).

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).

Daniel Kulp wrote:
>
> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The 
> NodeList stuff isn't even threadsafe in Xerces.

Actually, *no* access operations are threadsafe in Xerces. As far as I'm 
concerned that's a really bad design for general purpose use, ironically 
going back to the deferred node expansion feature that Xerces has on by 
default. It's always irked me that I have to use a synchronization lock 
around read-only operations with a (Xerces) DOM.

That said, any form of build-on-demand document model is probably not 
going to be threadsafe. But for our purposes in using it with web 
services there's not much need for threadsafety.

  - Dennis

Re: Performance Comparison

[Daniel Kulp <dk...@apache.org>]

On Friday 30 April 2010 4:23:26 am Amila Suriarachchi wrote:
> 
> 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.
> 

The "normal" way to traverse a DOM doesn't use the NodeList thing.   The 
NodeList stuff isn't even threadsafe in Xerces.    NodeLists are also slower 
due to having to calc the number of children and such.

Normally, you call el.getFirstChild() and the child.getNextSibling() which 
could easily use deferred parsing.   If someone uses the NodeList things, then 
yes, you would need to pull everything in at once, but using normal 
traversals, you wouldn't.

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

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

Re: Performance Comparison

[Daniel Kulp <dk...@apache.org>]

On Friday 30 April 2010 4:23:26 am Amila Suriarachchi wrote:
> 
> 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.
> 

The "normal" way to traverse a DOM doesn't use the NodeList thing.   The 
NodeList stuff isn't even threadsafe in Xerces.    NodeLists are also slower 
due to having to calc the number of children and such.

Normally, you call el.getFirstChild() and the child.getNextSibling() which 
could easily use deferred parsing.   If someone uses the NodeList things, then 
yes, you would need to pull everything in at once, but using normal 
traversals, you wouldn't.

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

On Fri, Apr 30, 2010 at 3:53 AM, Andreas Veithen
<an...@gmail.com>wrote:

> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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 <ss...@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/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

On Fri, Apr 30, 2010 at 3:53 AM, Andreas Veithen
<an...@gmail.com>wrote:

> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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 <ss...@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/

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Thu, Apr 29, 2010 at 6:23 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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.

DOOM is certainly missing a lot of features. The reason it did not
completely implement DOM (especially DOM 3 APIs) was that, at the time
we developed it, we just wanted  this API to be minimal such that it
supported the barely minimum required to use WSS4j + XML-Sec. This was
practical at that time.

>
> 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.

Any suggestions? Because the DOOM API would be required to support
both behaviors.

> * 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.

Would this new implementation still require us to build the complete
DOM tree in memory when we sign and encrypt content (through WSS4J +
XML-Sec)? If so, wouldn't this lead us to the same issues that we face
now?

Thanks,
Ruchith

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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

On Fri, Apr 30, 2010 at 3:53 AM, Andreas Veithen
<an...@gmail.com>wrote:

> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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 <ss...@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/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

On Fri, Apr 30, 2010 at 3:53 AM, Andreas Veithen
<an...@gmail.com>wrote:

> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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 <ss...@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/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

On Fri, Apr 30, 2010 at 3:53 AM, Andreas Veithen
<an...@gmail.com>wrote:

> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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 <ss...@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/

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Thu, Apr 29, 2010 at 6:23 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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.

DOOM is certainly missing a lot of features. The reason it did not
completely implement DOM (especially DOM 3 APIs) was that, at the time
we developed it, we just wanted  this API to be minimal such that it
supported the barely minimum required to use WSS4j + XML-Sec. This was
practical at that time.

>
> 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.

Any suggestions? Because the DOOM API would be required to support
both behaviors.

> * 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.

Would this new implementation still require us to build the complete
DOM tree in memory when we sign and encrypt content (through WSS4J +
XML-Sec)? If so, wouldn't this lead us to the same issues that we face
now?

Thanks,
Ruchith

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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Thu, Apr 29, 2010 at 6:23 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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.

DOOM is certainly missing a lot of features. The reason it did not
completely implement DOM (especially DOM 3 APIs) was that, at the time
we developed it, we just wanted  this API to be minimal such that it
supported the barely minimum required to use WSS4j + XML-Sec. This was
practical at that time.

>
> 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.

Any suggestions? Because the DOOM API would be required to support
both behaviors.

> * 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.

Would this new implementation still require us to build the complete
DOM tree in memory when we sign and encrypt content (through WSS4J +
XML-Sec)? If so, wouldn't this lead us to the same issues that we face
now?

Thanks,
Ruchith

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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

On Fri, Apr 30, 2010 at 3:53 AM, Andreas Veithen
<an...@gmail.com>wrote:

> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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 <ss...@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/

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Thu, Apr 29, 2010 at 6:23 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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.

DOOM is certainly missing a lot of features. The reason it did not
completely implement DOM (especially DOM 3 APIs) was that, at the time
we developed it, we just wanted  this API to be minimal such that it
supported the barely minimum required to use WSS4j + XML-Sec. This was
practical at that time.

>
> 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.

Any suggestions? Because the DOOM API would be required to support
both behaviors.

> * 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.

Would this new implementation still require us to build the complete
DOM tree in memory when we sign and encrypt content (through WSS4J +
XML-Sec)? If so, wouldn't this lead us to the same issues that we face
now?

Thanks,
Ruchith

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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

On Thu, Apr 29, 2010 at 6:23 PM, Andreas Veithen
<an...@gmail.com> wrote:
> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> <ru...@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.

DOOM is certainly missing a lot of features. The reason it did not
completely implement DOM (especially DOM 3 APIs) was that, at the time
we developed it, we just wanted  this API to be minimal such that it
supported the barely minimum required to use WSS4j + XML-Sec. This was
practical at that time.

>
> 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.

Any suggestions? Because the DOOM API would be required to support
both behaviors.

> * 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.

Would this new implementation still require us to build the complete
DOM tree in memory when we sign and encrypt content (through WSS4J +
XML-Sec)? If so, wouldn't this lead us to the same issues that we face
now?

Thanks,
Ruchith

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
<ru...@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 <ss...@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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
<ru...@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 <ss...@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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
<ru...@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 <ss...@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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

I think it goes deeper than that. When I checked just the time spent in 
the Rampart/WSS4J code it didn't account for all the overhead. It looks 
to me like there are some stream to String or stream to OM conversions 
going on even outside of the Rampart handlers.

  - Dennis


Ruchith Fernando 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?
>
> Thanks,
> Ruchith
>
>
> On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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
>>
>>
>>     
>
>
>
>   

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
<ru...@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 <ss...@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
>
>

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
<ru...@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 <ss...@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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

I think it goes deeper than that. When I checked just the time spent in 
the Rampart/WSS4J code it didn't account for all the overhead. It looks 
to me like there are some stream to String or stream to OM conversions 
going on even outside of the Rampart handlers.

  - Dennis


Ruchith Fernando 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?
>
> Thanks,
> Ruchith
>
>
> On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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
>>
>>
>>     
>
>
>
>   

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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

As I have observed both Axis2 (adb, jaxbri) and CXF gives equal performance
(without security) which slightly varies with the performance bench mark
being used. And also both of them provides well enough performance for any
business application.

But this problem is with the rampart as Ruchith has explained.

thanks,
Amila.

On Thu, Apr 29, 2010 at 7:16 PM, 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?
>
> Thanks,
> Ruchith
>
>
> On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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/

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

I think it goes deeper than that. When I checked just the time spent in 
the Rampart/WSS4J code it didn't account for all the overhead. It looks 
to me like there are some stream to String or stream to OM conversions 
going on even outside of the Rampart handlers.

  - Dennis


Ruchith Fernando 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?
>
> Thanks,
> Ruchith
>
>
> On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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
>>
>>
>>     
>
>
>
>   

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

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

I think it goes deeper than that. When I checked just the time spent in 
the Rampart/WSS4J code it didn't account for all the overhead. It looks 
to me like there are some stream to String or stream to OM conversions 
going on even outside of the Rampart handlers.

  - Dennis


Ruchith Fernando 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?
>
> Thanks,
> Ruchith
>
>
> On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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
>>
>>
>>     
>
>
>
>   

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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
<ru...@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 <ss...@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

Re: Performance Comparison

[Andreas Veithen <an...@gmail.com>]

On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
<ru...@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 <ss...@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

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

As I have observed both Axis2 (adb, jaxbri) and CXF gives equal performance
(without security) which slightly varies with the performance bench mark
being used. And also both of them provides well enough performance for any
business application.

But this problem is with the rampart as Ruchith has explained.

thanks,
Amila.

On Thu, Apr 29, 2010 at 7:16 PM, 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?
>
> Thanks,
> Ruchith
>
>
> On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

As I have observed both Axis2 (adb, jaxbri) and CXF gives equal performance
(without security) which slightly varies with the performance bench mark
being used. And also both of them provides well enough performance for any
business application.

But this problem is with the rampart as Ruchith has explained.

thanks,
Amila.

On Thu, Apr 29, 2010 at 7:16 PM, 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?
>
> Thanks,
> Ruchith
>
>
> On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

As I have observed both Axis2 (adb, jaxbri) and CXF gives equal performance
(without security) which slightly varies with the performance bench mark
being used. And also both of them provides well enough performance for any
business application.

But this problem is with the rampart as Ruchith has explained.

thanks,
Amila.

On Thu, Apr 29, 2010 at 7:16 PM, 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?
>
> Thanks,
> Ruchith
>
>
> On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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/

Re: Performance Comparison

[Amila Suriarachchi <am...@gmail.com>]

As I have observed both Axis2 (adb, jaxbri) and CXF gives equal performance
(without security) which slightly varies with the performance bench mark
being used. And also both of them provides well enough performance for any
business application.

But this problem is with the rampart as Ruchith has explained.

thanks,
Amila.

On Thu, Apr 29, 2010 at 7:16 PM, 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?
>
> Thanks,
> Ruchith
>
>
> On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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/

Re: Performance Comparison

[Dennis Sosnoski <dm...@sosnoski.com>]

I think it goes deeper than that. When I checked just the time spent in 
the Rampart/WSS4J code it didn't account for all the overhead. It looks 
to me like there are some stream to String or stream to OM conversions 
going on even outside of the Rampart handlers.

  - Dennis


Ruchith Fernando 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?
>
> Thanks,
> Ruchith
>
>
> On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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
>>
>>
>>     
>
>
>
>   

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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

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?

Thanks,
Ruchith


On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

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?

Thanks,
Ruchith


On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

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?

Thanks,
Ruchith


On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

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?

Thanks,
Ruchith


On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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

Re: Performance Comparison

[Ruchith Fernando <ru...@gmail.com>]

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?

Thanks,
Ruchith


On Wed, Apr 28, 2010 at 6:54 PM, Sanka Samaranayake <ss...@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