1. Bulding a Modular Application with Coherence David Whitmarsh Independent Contractor Technical Architect Investment Banks david.whitmarsh@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_VALIDA TION

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 ?

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