One of the most requested features for Spring-WS is a streaming message model. This means that - unlike with SAAJ, which is used under the covers right now - the content of the SOAP request is only read when needed. Especially with larger xml, this can improve performance drastically.
So I've implemented this feature based on AXIS2's Object Model (AXIOM). Despite the bad press AXIS2 seems to get in the blogs, the core AXIOM model is pretty decent, and shipped separately. And it supports SOAP 1.2 too. The only issue I had with AXIOM is that it forces you to use their custom DOM-like API, or StAX XMLStreamReaders. Clearly, this does not allow for much choice when handling the XML. And choice is what Spring is all about.
So I've written a wrapper for AXIOM, just like I did for SAAJ. The juicy AXIOM bits are completely hidden from behind the SoapMessage interface, which means that you change from SAAJ to AXIOM without any code changes. In fact, you only need to change the
in the appContext to
<bean id="messageContextFactory" class="org.springframework.ws.soap.saaj.SaajSoapMessageContextFactory"/>
Look in the airline-servlet.xml in the sample app to see how this is done. Using this Spring-WS wrapper, you can use any XML handling API you would like, including all the marshallers.
<bean id="messageContextFactory" class="org.springframework.ws.soap.axiom.AxiomSoapMessageContextFactory"/>
Note that using AXIOM (or StAX in general) only makes sense when you are not reading the entire payload in your endpoint. This means that using DOM, JDOM, DOM4J, and XOM are out. Instead, try using SAX or StAX.
The real issue I found with AXIOM relates to SOAP Faults when using SOAP 1.1. I've reported an issue for it here. It does not seem to occur during normal behavior, only when I run my extensive suit of SOAP test cases.
Another thing that needs to be done is attachment support for Axiom. I will implement that soon. After that, it's time to write some documentation, and do a release next week.