Hi Paul,
I don't think that C14N support in Axiom is likely to be of much direct
benefit for performance. Axiom is slower and more memory-intensive than
standard DOM implementations when a document model needs to be build -
its advantage is that barring signing and such, most times you can get
away without the need for a document model - so I don't see that using
Axiom rather than a standard DOM is really going to help.
The exception would be cases where only some tokens in the header are
being signed, which is actually the case that started this discussion.
If the Axiom+Rampart+WSS4J combination is smart enough to only build the
Axiom DOM for the header tokens that are being signed, this should give
much better performance than when the entire message has to be converted
to a DOM.
I look forward to comparing the performance using Axiom C14N vs. using
standard DOM, and will give this a try as soon as it becomes an option
in the configuration.
- Dennis
Paul Fremantle wrote:
IMO
C14N (in the case of signature) and DOM are the main culprits for
performance as far as WSS4J is concerned, not PKC.
I believe that some students have built out C14N directly in Axiom and
are planning to contribute it to Axiom shortly. That should make a big
difference.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
