Over the course of a complex service orchestration, it may be useful or necessary to query the same set of configuration data for an entity or process multiple times during and/or between executions. Where retrieving this configuration data involves interfacing with an external system or database, there can be reasonably significant I/O and network latency overheads associated which create bottlenecks in a service’s execution.
A popular technique for eliminating such bottlenecks is the concept of caching results, keeping a copy in memory paired with the key of the original request in case the same request is made again. The assumption of course is that configuration data changes infrequently enough to make these “old” results still valid for use for some time after the first query.
Oracle offers a distributed in-memory cache in a product called Coherence. Coherence features fast and reliable performance, redundancy across clustered servers, an intuitive API and many options for customising how it uses and retains information.
Coherence is also packaged as a component of the Oracle Weblogic server and its functionality is incorporated into Oracle Service Bus.
This recipe will walk you through caching the responses from a business service using OSB.
This recipe assumes you have already configured an OSB environment on which to deploy the service.
Although it is possible to develop for the Oracle Service Bus using only the Web Console interface, for a fully featured IDE (including support for version control, source code editing plug-ins, lower latency and independence of development environments) it is generally preferable to use the OSB Workshop perspective of the OEPE.
This recipe assumes the use of an existing OSB Configuration project within the OSB Workshop for development so ensure that you have installed and familiarised yourself with it prior to beginning.
Prior to beginning this recipe, it is assumed that you already have access to the service you wish to cache.
If you wish to follow along exactly with the “Fruit info” example in these instructions you will require an Oracle database and a copy of the JCA database adapter used in the example. You can obtain a copy of this, along with the database schema creation scripts from the following URL:
You will need to execute the database schema creation script, and then create a corresponding connection factory on your weblogic administration server identified by “jndi.cf.cookbook”.
In order to allow caching, the OSB weblogic server must be appropriately configured. Log into the OSB Administration Console and confirm the setting.
If it is not enabled, complete the following steps to enable it.
In order to cache results using OSB, the first thing you need to do is wrap the service you wish to cache using an OSB Business Service. If you’ve done this already, skip ahead to the next section "Configure the Business Service".
This is the key configuration step.
If you haven’t already done so, you will need to expose your Business Service via an OSB Proxy Service.
You’re done! You can now use the Proxy Service to access your cached business service operation.
Deploy and test your service. Then complete the following steps to confirm the caching behaviour.
The color in the database is “Green”, yet the service still returns “Red”. This is because the result was successfully cached.
As you have seen, caching using Coherence in OSB is very simple to activate and use. The following figure illustrates what is going on behind the scenes.
Because for most cases Coherence will be able to retrieve the result from the in-memory grid on the same application server, there will be no latency introduced by network or database I/O. This should greatly reduce the response time of your service, assuming frequent requests for the same data are made.
Your desired cache token key may not be as straight forward as selecting the contents of a single, predictably placed node.
It is worth noting that the Cache Token may be specified as any expression you like, using the XQuery functional programming language.
XQuery has a rich syntax for constructing queries, including the use of many system libraries with common functions such as numeric operations and string manipulation.
It might be that you can’t risk the cache becoming stale under certain circumstances. If that is the case, rather than using a time parameter to manage the lifetime of the cached responses, mark critical requests with an additional flag and select XQuery Expression in the expiration time options to test for the existence of this flag.
Thank you for your response.
That's really a nice work around.
I will test the same.
I was also thinking.. Do we have any options to reset the caching from api's based on our output parameter?
Thanks for your question Arpit.
In your case, the best strategy is likely to be simply correcting the bug in your PL/SQL procedure (as you have already done).
Caching works best in situations for which you expect consistency: the business service should be reasonably deterministic. If, for some reason, you expect your business service to regularly return "out of place" responses like the error you described then caching may not be appropriate in that situation.
Caching can still be applied if you want to though. My suggestion for working around that limitation would be:
- For Expiration Time, select "XQuery Expression"
-- select "Response".
-- Construct an XQuery which parses the returned payload and then returns either a constant integer representing seconds or a dayTimeDuration. If the result can't be parsed the way you expect, then you know something went wrong and return null instead. (null will stop the result from caching).
For more information, see also section 19.2.23 in the Oracle® Fusion Middleware Administrator's Guide for Oracle Service Bus
11g Release 1 (126.96.36.199.1)
I have a question in the same.
Let suppose i am calling a pl/sql procedure to get some output using a business service.
Due to some issue first time when i called i got some error message.
This value will be now stored in cache.
Now i have corrected my pl/sql procedure but again if i will call the business service.
It will try to get the data from cache and i will get a wrong result.
Can you please let me know what type of strategy we should use in these kind of situation?
|Subscribe to the Rubicon Red Blog|