Oracle Service Bus has a feature now for a while which gives us the option to switch on Result Caching on services.
Result Caching is based on Oracle Coherence, an in-memory data grid.
Basically what it does is cache the results from the calls to the business services. Which means on a second call to the service, OSB will first verify if the data, identified by a xpath-expression is in the cache. If it is, i will be retrieved from the cache, if it isn’t the call to the physical endpoint of the service will be made.
To be able to identify the data in the cache you need to configure the result caching on the business service, add the identifying ‘Cache Token Expression (XPath)’ and configure the expiration of the data item in the cache. This one can be handled by the default of the OSB, based on a duration or based on a XPath expression on the request/response message.
For a good overview read this part of the Administrators Guide.
For this scenario we re-used the almighty Hello World Webservice again.
- imported the wsdl + xsd resources in your osb project
- Create a new http business service based on the wsdl
- Create a new proxy service based on the business service
Our testscenario is ready, let’s get on.
To be able to verify if the result cache is getting used or not we need to enable Monitoring on our proxy and business service.
Either open them in the plain text editor and look for
<ser:monitoring isEnabled="true"> <ser:aggregationInterval>10</ser:aggregationInterval> </ser:monitoring>
Switch isEnabled to true.
Or enable the monitoring after deployment in the SBConsole.
Deploy the service.
By default we haven’t enabled the Result Cache. So when we would call the proxy service it will passthrough to the business service and do the ‘real’ call to the webservice.
When we repeat this, every time again, the proxy service will just do the ‘real’ call to the webservice over and over again.
Let’s setup a testcase in SoapUI to do a little loadtest against the proxy service interface
Double click the LoadTest 1, and check a few settings.
- Threads => 1
- Limit => 20 Total Runs
Our simple loadtest is ready. Based on 1 thread it will fire off 20 requests to our proxy service which eventually will invoke our Hello World business service.
Oracle Service Bus service statistics.
By enabling the Monitoring on our services Oracle Service Bus will collect and and gives us a Statistics overview in the console of the service.
Go to the Service Bus Console > Operations. Select the ‘Service Health’ tab at the top.
By default it will look a bit like this :
Both the proxy service and the business service received 20 messages, like we expected since we haven’t done anything yet with result caching.
We can enable the Result Caching on the business service either in Eclipse or in the Console.
Since we need to add some XPath expressions it’s easier to do it in Eclipse itself.
Open the business service and go to the ‘Message Handling’ tab.
- Enable Result Caching
- Add a ‘Cache Token Expression’ (used to see if the data is already in the cache)
- And optional add an Expiration Time
By enabling this configuration we setup the next situation.
Result Caching is active, when ever a request arrives through a proxy service to the business service result caching will get triggered. It retrieves that data by use of the XPath expression and check if it’s already or still availabe in the cache.
If the data isn’t available in the cache, the data will get stored in the cache and the real call to the webservice will be done.
If the data is available in the cache, the data will get retrieved from the cache and there won’t be any call to the webservice.
Eventually the retrieved data will be returned to the response pipe of the proxy service, back to the client caller.
Deploy the osb project and go back the SBConsole, to the Statistics.
First we need to reset the statistics to see the difference on the numbers between the situation in which we didn’t use the result caching.
Go back to the SoapUI project and start the loadtest again.
Again 20 messages arrived at the proxy service. On the first call the data won’t be in the cache so the ‘real’ call to the webservice will be done.
The next call will contain the same message payload (since we’re using the same message in our SoapUI test), so the XPath expression will evaluate to true, which means the data can be retrieved from the cache. And this continues till message #20.
So eventually from the 20 calls we made to the proxy service, only 1 will really do the webservice call at the backend, and the other 19 calls will retrieve data from the cache.
I hope it’s a bit clear now how the result caching works in the Oracle Service Bus, how to configure it and eventually how to be able to see if the cache is really active.