Bulding a Modular Application with Coherence

1
Bulding a Modular Application with Coherence

• David Whitmarsh
• Independent Contractor
• Technical Architect
• Investment Banks
• david.whitmarsh_at_sixwhits.com

2
1. Objective

• Describe a modular architecture using Coherence
• Applicable to static IoC approach (Spring)
• Aimed at dynamic modular approach (OSGi/Spring DM)

3
2. Modularity

• Spring, Maven, OSGi

4
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.

5
Module with Spring/Maven

• All classes/resources in dependent artifacts
  visible
• Change module classes only by restart
• Object instances resolved during
  ApplicationContext initialisation

6
Module with Spring DM/OSGi

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

7
3. Vanilla Coherence

• What support is there for modular design?

8
Principal Entities
9
Module Requirements

• Distinct data service layers
• Each with own caches and DAO instances
• Own data models, serialisers, CacheStores,
  CacheLoaders
• Independently stopped/started/deployed

10
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

11
4. Building Modules

• Extending and Overriding Coherence default
  behaviour

12
Class Dependencies
13
Instance Dependencies
14
Distinct Services per Module

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

15
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

16
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

17
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

18
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 ltclass-factory-schemegt?

19
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

20
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.

21
OSGi

• Using an OSGi container

22
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

23
Dynamic Data Model 1
24
Dynamic Data Model 2
25
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