Caching Service Responses with OSB
February 13, 2012
Originally posted by James Goddard
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.
Oracle Service Bus 11g
This recipe assumes you have already configured an OSB environment on which to deploy the service.
Oracle Enterprise Pack for Eclipse
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”.
How to do it...
Check the server configuration
In order to allow caching, the OSB weblogic server must be appropriately configured. Log into the OSB Administration Console and confirm the setting.
- Direct a web browser to http://localhost:7001/sbconsole/
- Log in using a system administrator account (by default, weblogic).
- Select Global Settings from the Operations menu.
- Confirm that Enable Result Caching is check (by default, it should be).
If it is not enabled, complete the following steps to enable it.
- Click the Create button in the top left. Check the Enable Result Caching option and then click Update.
- Click the Activate button, type a Description of the change and then click Submit.
Create the Business Service
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".
- If you don't have one already, create a new OSB Configuration Project.
- Create a new OSB Project.
- Add a subfolder for the business service and create a new OSB Business Service, configured to wrap the service you wish to cache the responses from. For example, for the provided "FruitInfo" example:
- Import all the files from the “Database Adapter” folder provided into a subfolder called fruitinfo_db.
- Right-click on the fruitinfo_db.jca adapter definition and select Generate Service.
- Accept the defaults and click OK.
Configure the Business Service
This is the key configuration step.
- Open your Business Service file for editing (the .biz file).
- Select the Message Handling tab.
- Expand the Advanced Settings.
- Check the Supported box next to Result Caching.
- Select the Duration radio button to indicate that cached results should expire after a set duration.
- Key in the amount of time you’d like for the Duration. (In this example we’ve chosen 5 minutes to make it easy to test).
- Click on the <Expression> link next to Cache Token Expression.
- From the variable structures on the right, locate the appropriate request operation and drag the key field from your request over into the text field on the left.
- Manually add /text() to the end of the expression to ensure that the contents of the node are used as the cache key.
- Select OK and then save all changes.
Expose using a Proxy Service
If you haven’t already done so, you will need to expose your Business Service via an OSB Proxy Service.
- Right click on the OSB Project and select New-> Proxy Service giving it an appropriate name. This will be the external facing service which wraps your cached service. Open the service for editing. For the simplest implementation you can pass the payload straight through by re-using the WSDL from the business service.
- Select WSDL Web Service as the Service Type.
- In the resulting dialog browse to the WSDL of the business service and select its port.
- Click OK.
- When prompted to change the transport configuration, select No to retain the HTTP transport.
- Select the Message Flow tab.
- Drag a Route Node across into the flow.
- Drag a Routing Action into the Route Node.
- Select the Routing Action to bring up the Properties tab.
- Click Browse next to Service.
- In the resulting dialog, navigate to the business service which encapsulates the caching mechanism.
- Click OK.
- Ensure that the correct operation is invoked in the Properties tab.
- Save all changes.
You’re done! You can now use the Proxy Service to access your cached business service operation.
Testing and confirming the Cache
Deploy and test your service. Then complete the following steps to confirm the caching behaviour.
- Navigate to the OSB Console at http://localhost:7001/sbconsole and login.
- Select Project Explorer from the main menu on the left.
- Navigate to the OSB Project you just created.
- Click on the Debug symbol to test the Proxy Service.
- In the resulting window, select the cached operation. Note that the other operations will not correctly route.
- Modify the payload to specify the key for your request. In this example we chose “Apple”.
- Call the service by clicking Execute.
- Confirm the response.
- Now modify the state of your reference data. E.g. in our example we will modify the database entry for “Apple” to have color “Green”.
- Re-run the same Proxy Service test and note the response.
The color in the database is “Green”, yet the service still returns “Red”. This is because the result was successfully cached.
- Wait for the cached result to expire and then call the proxy service again with the same test to confirm that it will eventually refresh the result.
How it works...
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.
More complex cache tokens
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.
Clear the cache explicitly
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.