One of the architectural components we've noticed developers introduce into Coherence deployments is the requirement for short-lived applications that perform some kind of initialization or maintenance of a cluster, prior to an application officially starting to use a cluster. For example one or more of the following types of "setup/maintenance applications" are often seen along-side cluster deployments;
While these applications are usually relatively simple to create and run, the fact that they are often deployed and executed somewhat independently from a cluster itself means their deployment may suffer operationally in two ways;
Consequently the primary goals for the introduction of Extensible Environments into Coherence is to permit;
Taking inspiration from the work carried out by the Apache Ant project with antlibs, Coherence Common 1.6.0 introduced the concept of an Extensible Environment that provided developers with the ability to create and use their own custom XML Cache Configurations (as Namespaces) with in standard Coherence Cache Configuration files.
For example, by using an Extensible Environment developers may declare cache configurations for Coherence as follows;
<cache-config xmlns:run="class://RunNamespaceContentHandler"> <run:runnable classname="MyRunnable" every="10m"/> ... regular cache configuration ... </cache-config>
In this fictitious example, the XML namespace "run" is declared as part of the
cache-config element thus making the use of the "run" namespace and it's
corresponding elements (ie: the "run:runnable" element) valid for use within
the cache configuration file. How and what the "run:runnable" element does to
the Coherence Member is defined by the namespace content handler specified by
class://RunNamespaceContentHandler. The mechanics of this is
described in detail here Introduction to XML Cache Configuration Namespaces
and in the tutorial
In the above example the XML namespace "run" and it's associated XML namespace content handler "RunNamespaceHandler" are not shipped as part of Coherence itself. It, like other namespaces, may be developed, supported and deployed independently of Coherence itself and Oracle Engineering.
The following sections of this document provide background concerning the
Coherence Bootstrap Procedure, the concept of a Configurable Cache Factory,
the Default Configuration Cache Factory (built into Coherence itself) and the
ExtensibleEnvironment class, a new Cache Configuration Factory that provides
support for XML Namespaces within standard Coherence Cache Configuration files.
When an application first makes use of Coherence API, say for example performing
CacheFactory.getCache(...) call, if it hasn't done so already (due to say
auto-start declarations), Coherence will commence it's boot-strap procedure.
At the highest level this procedure simply involves locating and loading the Coherence Operational Configuration so that the components within Coherence have an appropriate configuration so that they may initialize themselves.
For example, the Coherence Operational Configuration determines how the internal logging is configured, what underlying services are available, how the cluster is established and maintained, how the cluster may be secured and so on.
One of the most important and perhaps interesting parts of the Coherence Operational Configuration, at least for the purposes of this discussion, is in specifying how Coherence should:
That is, like other bootstrap-requiring components mentioned above, the Coherence Operational Configuration additionally provides the ability to (re)define the central mechanism and behavior governing the interpretation of Coherence Cache Configuration files, including the instantiation of caches defined with in said files.
With in Coherence the programmatic interface used to define the said cache
configuration behavior is called the
ConfigurableCacheFactory and the
implementation used at runtime by Coherence is configured in the Coherence
Operational Configuration by the
While it may seem that the Coherence
CacheFactoryis responsible for constructing the caches used by our applications, this responsibility is internally delegated to the
ConfigurableCacheFactory. That is, for the most part the
CacheFactoryimplementation simply delegates it's semantics to other core classes, including the configured
For example, the
tangosol-coherence-override.xml file that ships as part of
Coherence Common specifies the use of the
ExtensibleEnvironment to manage
cache configurations as follows;
<coherence> <configurable-cache-factory-config> <class-name>com.oracle.coherence.environment.extensible.ExtensibleEnvironment</class-name> <init-params> <init-param> <param-type>java.lang.String</param-type> <param-value system-property="tangosol.coherence.cacheconfig">coherence-cache-config.xml</param-value> </init-param> </init-params> </configurable-cache-factory-config> </coherence>
Note that the above declaration specifies both default name for coherence cache configuration file ie:
coherence-cache-config.xmland the system-property that may be used to override the location and name of said configuration file.
Out of the box the default implementation of the
interface wired into the
coherence.jar is called the
When using Coherence Common we override this wiring by embedding a
tangosol-coherence-override.xmlfile (as outlined above) in the
coherence-common-x.y.z.jar, which forces the use of the
ExtensibleEnvironmentimplementation as the
ConfigurableCacheFactory. This only works however if the
coherence.jarin your application classpath.
The ability to configure and replace the
Coherence uses to instantiate caches is very useful concept. For the most part
it means developers have the ability to intercept, change, extend and override
the how cache configurations are presented to Coherence and while it seems
Coherence may already have more than enough configurability, being able to
completely replace how caches are configured has some significant advantages.
A good example of this is the
ExtensibleEnvironment class, which simply
pre-processes the XML it was provided through the Coherence Bootstrap Procedure
to recursively resolve any foreign XML namespace XML elements. In reality,
Coherence itself is oblivious to the fact that the cache configuration it
provided to the
ExtensibleEnvironment had been changed.
ExtensibleEnvironment has proved itself in three important ways. Firstly
it allowed developers, the Coherence Community to decompose large
configurations into smaller more manageable ones. Secondly it allowed developers,
and again the Coherence Community to create independent "libraries" that contained
their own cache configurations to be "contributed" into the configuration of a
larger enterprise system - which obviously simplified things a lot in large systems.
Lastly it demonstrated to developers that they too could customize Coherence behaviour even further through the use of simple changes in Operational Configuration.