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
<[email protected]>wrote:
> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <[email protected]> wrote:
> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> > <[email protected]> wrote:
> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <[email protected]> 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: [email protected]
> >>> For additional commands, e-mail: [email protected]
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> >>
> >
> >
> >
> > --
> > Sanka Samaranayake
> >
> > http://sankas.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
