Caching SOAP Responses

Question

Our current application has to talk with a SAP PI layer, in the form of SOAP style services. Unfortunately, this services layer, does not implement any form of caching, leading to high response times, even for subsequent requests. We think we are down to two options to solve this problem. Note that these are HTTP POSTs.

• Cache the java response object that we create, after the first call.
• Cache the xml response, by introducing a caching proxy in-between. Invalidating and checking for cached responses seems more difficult here, because, it will involve peeking into request bodies.

We would like to know, if anyone has any experiences with either approaches, or when faced with a similar situation, how would you solve it

Answer 1

Before you run down the path of working out your caching mechanism, keep in mind what services and processes (SOA and BPM) are about. They're designed to abstract away the actual implementation of some sort of business functionality behind a standards-based interface.

When you say there are high response times, have you analysed what the source of the delay is?

• How much of your delay is network latency?
• How much is the integration stack reading and writing your SOAP requests and responses?
• Are there other overheads such as logging or persisting of your requests/responses (e.g. if using persistent messaging as your transport layer)?
• How how much is the delay in the actual processing of your request in SAP PI?

The services and processes you are invoking are meant to be treated as black boxes, i.e. you shouldn't have to know what happens behind the covers, only that it's performing the function you asked it to do.

However, if you implement caching, you are making the assumption that the services you are calling have no side effects such as updating data, keeping an audit trail, notifying other parties or systems of an event, etc. So even if you find a technical way of implementing your caching requirement, you might actually be undermining the service implementation. To your application it will look OK, but you could be impacting other systems or processes that you are not aware of.

If you are confident that you know what you are doing then by all means look at caching. Implementing it in your application by storing the response object would probably be fastest but would not be usable by other applications, so the performance benefit will be localised. If you go this approach, you may still want to consider building a mechanism for selective caching rather than applying to all.

Some ESBs and even XML gateways/appliances have caching capabilities. I know the IBM DataPower devices, for example, have document caching capabilities where you can control which services/URLs are cached, and what sort of time-to-live those cached copies have. This approach has the advantage of offering all consumers of the SAP services the same performance increases you're looking for.

Also keep in mind that caching will increase memory consumption, so if you don't approach it carefully you could cause your application, or the ESB or whatever you implement it with, to run out of memory. DataPower seemed to have the unfortunate habit of just resetting itself without telling anyone when we ran into this problem on a project! :)

Hope that helps.