If using the axiom message factory with payload caching turned off, spring-ws currently supports streaming a request on the server-side and a response on the client-side without parsing the stream into an axiom tree. But responses on the server-side and requests on the client-side do get parsed into axiom trees. So turning off payload caching is non-symmetrical.
If this can be prevented, then spring-ws should be able to support large client requests and large server responses with much better performance. This also would even help with medium-sized messages in high volume scenarios.
The AxiomSoapBody's getPayloadResult() method currently creates a custom SAX Content Handler that effectively builds an axiom tree for the payload during transforms involving the payload result. The proposed enhancement is to basically have getPayloadResult() return a subclass of StreamResult feeding a ByteArrayOutputStream, and then in the AxiomSoapMessage's writeTo() method insert an Axiom OMSourcedEle as the payload, containing a custom OMDataSource built around the above ByteArrayOutputStream. This allows a 'placeholder' for the payload in the axiom tree containing the raw payload XML, and when writeTo() serializes the axiom message to the transport's output stream, the raw payload XML is written to the output stream without ever getting parsed. It is a little more involved than the above, but that describes the highlights.
If something like an interceptor, client-side callback, or logging code needs to access the contents of the payload, axiom will automatically parse the contents of the OMDataSource into a fully expanded Axiom tree. So this gives the flexibility of accessing the payload data if need be, but does not parse it into axiom nodes unless absolutely needed.
I am preparing a patch of contribution files that does the above. I mainly just need to wrap up the unit tests and do some performance testing, and then I will attach the patch.