Bulding a Modular Application with Coherence

David Whitmarsh Independent Contractor Technical Architect Investment Banks

david.whitmarsh@sixwhits.com

1. Objective

Describe a modular architecture using Coherence

Applicable to static IoC approach (Spring) Aimed at dynamic modular approach (OSGi/Spring

DM)

2. Modularity

Spring, Maven, OSGi

Module Dependencies

Classpath dependencies Module imports a class/resource from another

module Instance dependencies

Class instance in one module calls method on a class instance in another.

Module with Spring/Maven

All classes/resources in dependent artifacts visible

Change module classes only by restart Object instances resolved during

ApplicationContext initialisation

Module with Spring DM/OSGi

Explicitly exported/imported packages visible Changing module classes reloads dependents Referenced object instances may change while

running

3. Vanilla Coherence

What support is there for modular design?

Principal Entities

Module Requirements

Distinct data service layers Each with own caches and ”DAO” instances Own data models, serialisers, CacheStores,

CacheLoaders Independently stopped/started/deployed

What Level?

We can build data access modules around: CacheFactoryBuilder

Classpath trickery, or embed entire Coherence jar inside module Separate grid node (or even grid) per service Static access ok

CacheFactory Distinct configuration files per service Must delegate dependencies (Serialisers, CacheStores) No static access methods

Service or Cache Single config across modules – coupling

4. Building Modules

Extending and Overriding Coherence default behaviour

Class Dependencies

Instance Dependencies

Distinct Services per Module

Ensure that an instance of Service is used only in a single CacheFactory

use STRATEGY_VALIDATION

Static Methods

DefaultCacheFactoryBuilder has an internal defaultCacheFactory

Static access Don't use CacheFactory.getCache or

DefaultCacheFactoryBuilder.getDefaultCacheFactory Use non-static CacheFactory.ensureCache

But Coherence itself uses getDefaultCacheFactory! Proxy service Incubation projects Cohql

Hacky Bit #1

Provide a ConfigurableCacheFactory implementation that delegates to the appropriate factory

Not all methods need sensible overrides EnsureService – API exists to map service to

factory EnsureCache – not so easy

Configuring CacheFactory

Configuration needs to come from config module (I disapprove of URL)

File resource in config module not on classpath for Coherence module (under OSGi)

Provide config as String or InputStream URL used as unique id for config, hence factory

Suppress load from URL and use as a simple id

IoC instance injection

Provide CacheStore, PofContext by injection XMLHelper only constructs new classes Configure a proxy to delegate to injected

instance In an OSGi environment implementations will

not be visible in Coherence module. Would prefer config mechanism to use a

reference – perhaps a <class-factory-scheme>?

Complete Module Config

As per example code Add destroy-method hook to stop factory,

remove services on module stop (OSGi) In OSGi, factories can be deployed, started and

stopped at any time. Use a separate config module to create a proxy

service factory

System Properties

Coherence substitutes system properties in config files

Apparently read in some static initialiser No way to inject config properties other than

setting system properties before they're read.

OSGi

Using an OSGi container

Add/Remove Services

Coherence module has no classpath dependencies on data models

Add, upgrade, remove services without interruption Rolling upgrade on only those services that need to

change

Dynamic Data Model 1

Dynamic Data Model 2

Dynamic Data Model 3

All handling of serialisation/persistence delegated via OSGi

New versions of data model and data model support deployed and old versions removed without changing cache config/CacheFactory instance

Evolvable objects updated in-place No rolling upgrade required