This article describes an architectural pattern, implemented in the Oracle SOA Suite 11g, that is somewhat similar to the Oracle Database 11g Function Result Cache. It introduces a SOA Composite Application in the role of Result Cache. In its most simple form, the result cache is initialized – loaded with values -, used by other SOA applications that need the cached values, refreshed/reset when required and terminated. Through this ‘result cache’ – frequently used and not-so-frequently changed values that are published by (possibly remote, expensive or slow-reacting) web services or adapter services can be made available to local consumers in a simple, cheap and fast manner. We achieve this using the fast native SCA binding used for invoking in-container services exposed by fellow composite applications (that’s for speed) and the BPEL correlation mechanism (that’s for finding the result cache in the first place).

What the actual value of this pattern and implementation are is not yet entirely clear to me. Your feedback is appreciated. What I do know is that this article is also a good demonstration of using correlation and of applying some of the XML manipulation techniques available in BPEL processes.

In a single picture, here is what I created: one or more Composite Instances are initialized; each instance is a cache, identified through its name. Upon initialization, the cache is loaded with values – supposedly important, frequently reused, hard-to-get-by values. Composite applications that are interested in these cached values can retrieve them from the cache, by calling the exposed service and passing the name of the cache (here is where correlation kicks in) and passing the name of the cache entry. The BPEL process looks for the entry and returns the value when found or null and an appropriate message when not found.

Read the rest of this entry »