Use IBM ACE Global Cache to Externalize Configurations and Simplify Deployment

Introduction

With more and more distributed and containerized deployment, how to externalize configuration and environment parameters in application components is always a hot topic. This article would investigate the same issue for IBM ACE deployment and introduce some directions and approaches.

Traditionally, IBM WMB (the grand parent of IBM IIB and IBM ACE), 2 mechanisms are being used.

1. use Baroverride to change runtime parameters and configuration. A still very common used approach even in ACE v12 today.
2. use User Defined Properties at design time with default values and possible Baroverride at deployment time.

The obvious catches are that :

1. Need separate overriding properties files for different environments like dev, qa and production. Lots of effort to maintain so different configuration files and error prone during the overriding processes. (Surprising with all kinds of automation, this is still the very frequent problems hit during production cutover for a lot of projects.)
2. Downtime for re-deployment for any configuration changes, which also usually involves manual process.

In one of my past projects, an insurance company used IBM WMB as gateway for all quotation intakes. The company wanted to have a almost 7x24 non-stop gateway and responsive for any configuration changes. Down the road, I consolidated the requirements into a framework as introduced here.

With more and more distributed and containerized deployment, how to externalize configuration and environment parameters in application components is always a hot topic. This article would investigate the same issue for IBM ACE deployment and introduce some directions and approach.

On high level, 3 common mechanisms for configuration externalizaiton can be employed in IBM ACE.

1. OS environment variables. Similar to how image/container deployed in Kubernetes cluster.
2. IBM ACE User Defined Policy (Configurable Services for IIB v10 in the old days)
3. Global Cache (the Framework discussed here)

Framework

First, the Component Diagram.

and then the Sequence Diagram.

The framework provides couple features:

• externalize User Defined Properties or Flow Properties and thus prevent the need of Bar Overrides.
• allow dynamic endpoints like Queues, Topic, REST and SOAP Endpoints, Kafka Topics for different environments.
• immediate changes on the properties at runtime without restart and re-deploy Applications by refreshing the cache.
• Properties can be loaded from either database and git repositories.
• both repositories support encryption and decryption for sensitive information.
• both repositories are able to detect duplicated keys.
• git repository supports and merge multiple paths and files with YAML and CONF formats. (i.e. So, each application can have its own yaml file.)
• allow single bar file being reused in all environment from dev to prod. (For some corporates with very tight security, the Bar file built for UAT is sealed and deployed to production, i.e. no further baroverride allowed after UAT.)