On Friday 08 October 2010 7:23:55 am Andreas Veithen wrote:
> The other alternative is to leave WSS4J unchanged and to let the SAAJ
> implementation materialize the different parts of the object model on
> demand. I have a working PoC that does this. It currently implements
> an alternative SAAJInInterceptor that provides the following features:
>
> * It always puts a SOAPMessage into the Message object, but the
> SOAPPart (including the SOAP headers) is only instantiated on demand
> when the SOAPMessage is accessed.
> * The content of the SOAPBody is only materialized when is it actually
> accessed. In addition, deferred parsing and building of the nodes is
> supported for this part of the message. This means that WSS4J can
> start processing the body of the message before it has been received
> entirely.
> * If the body has not been accessed, the StAX events are passed
> through unchanged (e.g. to the interceptor that does the databinding
> stuff). If the body has been accessed through the SAAJ API, then a
> W3CDOMStreamReader is used to regenerate the StAX events.
>
> All this is completely transparent for the interceptors further down the
> chain.
Hmm.. that's kind of cool. More or less what Axiom should have been. ;-)
> Of course, this is impossible to achieve using a standard SAAJ
> implementation. Therefore the interceptor uses an alternative SAAJ
> implementation which I have written as part of a larger project called
> DDOM [1].
And I think this is where the issues may start popping up, but definitely
resolvable. If you look at the CXF survey, one of the MAJOR "areas of
improvement" for CXF was too many external dependencies. I'm kind of
reluctant to add more "required" deps. Thus, the security stuff would need
to work with the default SAAJ impl (in particular, the one built into the
JDK), but I could definitely see making something like this as an optional
"performance enhancment" type thing. Ideally, the existing SAAJ interceptor
would be smart enough to checkt he SAAJ impl being used and do the smart thing
depending on what it sees. If the DDOM stuff we need can be squashed/shaded
into a single jar that is just a drop in replacement of saaj-impl, that
concern could also be aleviated quite a bit as well.
That said, the callback method added to WSS4J has an additional use case that
Sergey and I have been noodling on outside of SOAP. One thing we're trying
to figure out how to do is leverage some of the WS-SecPol support to provide
message level security for XML REST payloads. With the callback, we MAY be
able to have separate XML sources for the security header and the actual
payload (think separate MIME containers) where we feed the security header
into WSS4J, and it calls back out to us to load the other parts as/if needed.
Very early in the "noodling in our heads" stages. :-)
> The implementation is still incomplete, but to give you an
> idea about its current status:
>
> * The underlying DOM implementation successfully passes the W3C DOM1
> and DOM2 test suites, except for features not relevant to SOAP
> processing (such as DTD information, entity references, etc.).
That's good. DTD handling with Stax really sucks. Good luck with that.
;-)
> It also
> successfully passes the most important parts of the DOM3 test suite.
> * When configured as SAAJ implementation in the CXF build (without the
> custom SAAJInInterceptor), it passes all unit tests up to the systests
> (It seems that this is primarily due to the fact that some of the
> systests use SAAJ to compose test messages).
Likely yes. Do you have a feeling as to whether those are issues in the CXF
tests or issues with DDOM?
I see in the code that it doesn't support attachments either. That would be
required for the JAX-WS TCK. (and likely for some of the systests as well)
That said, those should be fairly easy to handle since you have the
SoapMessage. The DDOM version could be MUCH more efficient by not
buffering the attachments unless they really are accessed. One of my
"issues" with the JAX-WS handlers is they require us to stop streaming
EVERYTHING and buffer it, even if the only thing the handler does is:
System.out.println("Hello World!");
this could be a huge help with that.
> * When configured as DOM implementation in the WSS4J build, it passes
> all unit tests except some of the tests related to SAML (because
> OpenSAML expects to get schema support from the DOM implementation
> available though JAXP).
> * I tested the implementation successfully with the scenarios
> developed by Dennis Sosnoski [2] (both by simply configuring DDOM as
> SAAJ implementation as well as using my alternative
> SAAJInInterceptor).
>
> The code for the custom SAAJInInterceptor is available here:
>
> http://ddom.googlecode.com/svn/trunk/modules/ddom-cxf/
>
> Note that besides the limitations mentioned above, there are currently
> some features missing in this SAAJInInterceptor implementation that
> needs to be mentioned, namely processing of SOAP faults and the
> ability to access attachments through the SAAJ API.
Ah. Yep. Didn't read far enough. :-)
> Some preconfigured CXF (2.3.0) clients and services (containing code
> from Dennis' article) are available here:
>
> http://ddom.googlecode.com/svn/trunk/perftests/
>
> Note that for the moment, they still use Sun's SAAJ implementation for
> outgoing messages. Therefore the interesting things happen in the
> response processing on the client side.
>
> I did some initial performance tests with the scenarios developed by
> Dennis and the results suggest that my SAAJ implementation performs
> slightly better than the one from Sun, resulting in a few percent
> points improvement in the "sign" and "signencr" scenarios. Note that
> the features of the custom SAAJInInterceptor are not relevant here
> because the body is accessed anyway in these scenarios. I think that
> the improvement primarily results from a reduced memory footprint.
> Maybe Dennis could volunteer as an "independent" performance tester to
> confirm this?
>
> BTW, while doing some profiling, I noticed that in the "signencr"
> scenario, CXF suffers from a flaw in Santuario's code, namely
> org.apache.xml.security.encryption.XMLCipher.Serializer#deserialize,
> which does some highly inefficient stuff. I think that by doing that
> part of the processing in a smarter way, it may be possible to perform
> better than Metro in the small-response case and to increase the gap
> with respect to Metro in the large-response case.
Yea. Colm is aware of a few places in both WSS4J and Santuario that could use
some work. He hasn't had time to work on it yet, but, if all goes well,
he'll have some time soon. ;-)
Dan
> Andreas
>
> PS: As noted between the lines by Daniel, optimizing the security
> processing for outgoing messages is much more difficult, at least in
> CXF. In principle, the Axis2 architecture would allow to achieve this
> more easily, but before this can be leveraged, there are some other
> performance issues in Axis2/Rampart that need to be fixed...
>
> [1] http://code.google.com/p/ddom/
> [2] http://www.ibm.com/developerworks/java/library/j-jws14/index.html
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
