SOA Suite 12c: First steps with the Coherence Adapter to create cross instance state memory

1

One of the new adapters shipped with SOA Suite 12c is the Coherence Adapter. This JCA adapter makes it easy for a Service Bus business service or a SOA composite application to interact with a Coherence memory grid. Fully declaratively and with very little trouble, data can be put on a Coherence grid (aka cache) and read from that cache. The cache is accessed like a big map: using a key, an object is saved to and retrieved from the cache. The cache is accessible across service executions and process instances, as well as across cluster nodes.

A Coherence Cache is typically used to reuse results: values that have been calculated before at potentially some [considerable]cost to the back end system. By reusing them, the results are obtained much faster and without any load on the enterprise resources that would otherwise have to reproduce them. Using values from the cache may actually mean saving money in the case that calculating the result involves invoking paid for services.

Coherence provides replicated and distributed (partitioned) data management and caching services on top of a reliable, highly scalable peer-to-peer clustering protocol. The Coherence Adapter is a JCA 1.5-compliant resource adapter for Oracle Coherence. Objects in the cache can either be of XML or POJO (Plain Old Java Object) type. The Coherence adapter enables you to perform useful coherence operations such as adding an item to a Coherence cache, obtaining an item from a Coherence cache, removing an item and querying from a Coherence cache.

In this article, I will show a simple example of creating a SOA composite application that uses the Coherence Adapter to speed up a process more than 100 times (although admittedly this could only happen because I first made it extremely slow).

Create new SOA Composite:

image

Create BPEL component with simple synchronous interface, exposed as SOAP Web Service. Input is string, output is string:

image

Create a second BPEL process based on the same WSDL:

image

Wire the first BPEL Process to the second. This second process will create the hello world greeting – but it will do so quite slowly.

image

Edit the second, slow process. It waits for 5 seconds, then it assigns a greeting value to the output variable:

image

The first process will call this second process. After 5 seconds, it will receive the greeting, which it can then return itself:

image

Deploy and run:

image

And run from the automatically opened HTTP Analyzer

image

With the following call log (just over 5 seconds):

image

With the following flow trace:

image

No matter how often we make the call, the response time stays over  5 seconds, even if the response is the same each time. Enter: the cross instance memory, implemented using Coherence and accessed using the Coherence Adapter.

Coherence Adapter as shared memory

Open the composite editor. Drag the Coherence Adapter from the component palette to the References swimlane.

image

The Adapter Configuration wizard appears.

image

Set the name of the adapter binding to WriteToCache. Press Next.

image

Set or select the JNDI name of the Coherence connection to eis/Coherence/Local. This name corresponds with one of the connections configured in the Coherence Adapter deployment in the Integrated WebLogic Server. Press Next.

image

Select Put as the operation type.

In step 4 of the wizard, set Cache Type to XML. Set the Cache Name to adapter-local. This cache is preconfigured – ready to use for straightforward situations where no special configuration is required.

image

Uncheck the checkbox for auto generating the key. Set the Key Type to String and leave the Key field empty. Accept the default for time to live. Press Next.

 

A popup appears with a message, instructing us on setting the value for the key at run time using the JCA header property jca.coherence.Key. Acknowledge the message and continue.

image

Select element processResponse from the HelloSlowWorld.xsd as the schema element [for objects to retrieve from the cache].

image

Click Next and click Finish.

image

The Coherence Adapter reference (for reading stuff from the cache) is created.

 

image

Drag a second Coherence Adapter to the References lane, to create the Adapter binding to write data to the cache.

image

Press Next.

image

Select Put as the operation type.

In step 4 of the wizard, set Cache Type to XML. Set the Cache Name to adapter-local. This cache is preconfigured – ready to use for straightforward situations where no special configuration is required.

Uncheck the checkbox for auto generating the key. Set the Key Type to String and leave the Key field empty. Accept the default for time to live. Press Next.

image

 

A popup appears with a message, instructing us on setting the value for the key at run time using the JCA header property jca.coherence.Key. Acknowledge the message and continue.

image

image

image

Refactoring: Rename Adapter Binding

I have just realized that I have mistyped the name of the second adapter binding: Retreive instead of Retrieve. In 11g that would have given me a headache (or I would probably have recreated the adapter binding, afraid to not be able to correctly manually edit all occurrences of the string Retreive). In 12c, we can easily refactor many things, including the names of Reference Bindings. Simply right click the adapter binding:

image

select Rename from the dropdown menu and specify the new name:

image

Press OK, and you’re done – or rather, I am:

image

Leveraging the Coherence cache from the BPEL process

Wire the first BPEL process – HelloSlowWorld – to the WriteResultToCache adapter binding.

image

and wire the BPEL process to the other adapter binding:

image

Open BPEL Process HelloSlowWorld. Add Invoke activities: one immediately after the Receive (to invoke the RetrieveFromCache partner binding) and one after the invoke to the SlowGreeter

image

Wire the first invoke to the RetrieveResultFromCache partner link. Confgure the activity – create local input and output variables:

image

Note that we will not actually use the input variable – because the key value we need to pass to the partner link and indirectly the Coherence Adapter binding is passed using a header property.

Open the Properties tab in the Invoke editor. Click on the green plus icon to add a property to pass. Select property jca.coherence.Key from the dropdown list. Select the input element in the payload part of the $inputVariable as the value for the property; the name passed into the service is used as the cache key:

image

Click OK (twice) to complete the configuration of the Invoke activity.

Wire the second Invoke activity to the SaveResultToCache partner link. Configure this activity – also creating two local variables.

image

Open the Properties tab in the Invoke editor. Click on the green plus icon to add a property to pass. Select property jca.coherence.Key from the dropdown list. Specify the following expression to derive the value for the Key property – the same as for the previous invoke activity:

image

Click on OK (twice) to complete the definition of the invoke activity.

Now we add some logic to the BPEL process.

Add an IF activity. It will test whether the cache contained the object under the given key. If it does, then we are done: the output variable has been set. If it does not, we have to execute the invoke to the SlowGreeter followed by the invoke to the WriteResultToCache partnerlink.

image

The IF condition is defined as follows:

image

We also need to add assign variables, to assign the result from retrieve from cache to the outputVariable

image

and from the invoke to SlowGreeter to the input variable used in the invoke to WriteResultToCache:

image

Deploy the SOA composite and Test it

After deploying the SOA composite to the Integrated WLS, we can again make a test call from the HTTP Analyzer tool.

image

It looks the same, the result is the same and the time it took to produce the result is the same as well. However, when we check the flow trace, we can see that this time a little bit more went on behind the scenes:

image

The composite did not just use the SlowGreeter to create the response. It also first checked the cache – in veil as it turned out – and then after obtaining the result from the SlowGreeter, it also put the result onto the cache. That last action does not benefit this instance of the composite of course, but it will help speed up future instances that have to deal with the same input and the same SlowGreeter.

The BPEL Audit Flow reveals exactly what happened – no surprises there: invoke the get-from-cache. If not found, then invoke SlowGreeter and subsequently pass result to put-on-cache.

image

The next call to the service for the same input has a much faster response and a different flow trace:

image

This time, the result could be found in the cache, so no additional processing is required and SlowGreeter does not have be invoked.

image

Share.

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director for Fusion Middleware. Consultant, trainer and instructor on diverse areas including Oracle Database (SQL & PLSQL), Service Oriented Architecture, BPM, ADF, Java in various shapes and forms and many other things. Author of the Oracle Press book: Oracle SOA Suite 11g Handbook. Frequent presenter on conferences such as JavaOne, Oracle OpenWorld, ODTUG Kaleidoscope, Devoxx and OBUG. Presenter for Oracle University Celebrity specials.

1 Comment

Leave a Reply