How can I cache the marshalled SOAP XML generated by Apache CXF for a particular Java Object to improve performance?

Answer 1

Ok, not exactly the answer you are looking for, but anyway: The reason that REST is used in Webservices with high traffic (e.g. Google), is that REST is designed to be cacheable - whereas SOAP is just NOT designed to be cachable.

SOAP is basically based on (per HTTP definition) non-cacheable POST requests, and REST uses GET - which is easy to cache.

You would have to inspect the SOAP (POST) request before it goes to the actual Webservice - i.e. using a proxy. "Standard" proxies are usually unaware of SOAP syntax.

IBM's WebSphere Application Server though can do that:

http://tinyurl.com/n7hune

Regards, Olaf

Answer 2

There is no strict requirement in SOAP that you need to use a framework like CXF to handle the server or client SOAP endpoints. We just ran into client thread deadlocks when using an Axis 1.4-based SOAP client to talk to an Axis 1.1-based server, and fixed them by ditching Axis and making the requests in hand-written code. We had to lie to the Axis server by telling it we still had an Axis client, but felt no remorse! ;-)

Similarly, you should be able to bypass CXF and generate SOAP responses in your own handwritten java code. Then you can use a Map to cache your marshalled (unparsed, serialized) XML strings and eliminate this hotspot.

Strongly agree with Olaf on REST: if you fully leverage HTTP, then all this caching happens for free in all the intermediate caches between your server and your clients. That's certainly something to consider for new services.

Update: CXF has the notion of customizable interceptor chains. One type of outbound interceptor is for the MARSHAL phase, so it sounds like you could add this cache there without having to ditch CXF. Perhaps a CXF expert can verify that for us?

Answer 3

The Foo object is Marshalled from our Java object to the SOAP XML response using Apache CXF.
.. the single greatest consumer of CPU cycles. and since our Foo object isn't changing very often, remarshalling this object each time is unnecessary.

Does the client application need to know of changes in Foo instantly or as soon as possible?

Why not cache it on the consumer/client side? A design where you are calling the same web service method hundreds of times per second probably isn't the best.