如何缓存Apache CXF为特定Java对象生成的编组SOAP XML以提高性能？

Question

In my application, we have a webservice method called getFoo() which returns a Foo object. The . The Foo object is Marshalled from our Java object to the SOAP XML response using Apache CXF.

and since our Foo object isn't changing very often, remarshalling this object each time is unnecessary.

I briefly looked at the CXF docs and there is a Marshall interceptor which I could probably make use of. I could create a Map which could map Foo objects to the XML encoded version. But, then a few other issues come up like how do you remove objects from this Map once they are no longer needed etc. It'd be nice if there was built in support for somehow detecting changes to the object and re-marshalling... Nothing impossible, but didn't want to reinvent the wheel.

: Have made some progress by making a custom BareOutInterceptor and modifying the Interceptor chain to call the custom one. The custom adds some additional logic to only call the "writeParts(....)" method which performs the marshalling only the once for a given java object. Will post solution once finished. Also, I renamed the question.

Answer 1

Ok, not exactly the answer you are looking for, but anyway: The reason that REST is used in Webservices with high traffic (eg 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 - ie using a proxy. "Standard" proxies are usually unaware of SOAP syntax.

IBM's WebSphere Application Server though can do that

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.