Deciding between the embedded global cache and an external WebSphere eXtreme Scale grid

Are you debating whether to use the embedded global cache or an external WebSphere eXtreme Scale grid (or both!) in your IBM Integration Bus solution? This article will help you understand the differences between the embedded global cache and usage of external grids with IBM Integration Bus, so that you can decide which approach best fits your solution.

IBM Integration Bus provides you with the ability to connect to an external WebSphere eXtreme Scale grid.
You are able to use the embedded global cache and external grids from the same integration flows, and can switch between them with minimal changes to your code.

This article explains some of the differences between the embedded grid and external grids, and some of the considerations when choosing one over the other:

1. Summary of the differences between the embedded global cache and an external grid.
2. Common reasons for choosing an external grid over the embedded one.
3. Comparison of functionality.
4. Details of fixed configuration settings for the embedded grid.
5. Summary.

Summary of the differences between the embedded global cache and an external grid

The embedded global cache is a WXS (WebSphere eXtreme Scale) grid, made up of WXS catalog and container servers (using WXS v8.5.0.3) hosted within integration servers.
This grid is designed and optimized for use within (and between) integration nodes. You are able to configure the topology of this grid, for instance how many catalogs/containers, and where they reside. But you are not able to modify the underlying WXS configuration of the grid. The embedded cache is supplied as part of IBM Integration Bus and no further installation is needed in order to use it.

By contrast, the external grid is not shipped with  IBM Integration Bus and must be obtained and installed separately from it. However with an external grid, you have complete control over the WXS configuration. Details of the kind of properties this encompasses are covered below.

Because the catalog and container servers for the embedded grid are hosted within integration server processes, they share their JVMs (Java Virtual Machines) with all other components running in the integration server. This includes IBM Integration Bus components, user added Java code, and data. As a result of this, the cache servers do not have control over their containing JVMs, and are not able to modify or restart the JVMs. This also means that the maximum JVM heap size is determined by the relevant integration server property. Moreover, the lifecycle of each cache server is inextricably tied to that of the integration server in which it resides.

With an external grid, you need to create, administer and manage the WXS server components outside of IBM Integration Bus. But this enables you to decouple the availability and management of your cache from IBM Integration Bus.

Note, because the level of WXS used for the embedded cache within IBM Integration Bus is currently 8.5.0.3, if you connect to a WXSv8.6 external grid, that grid must not have the “XIO” transport mechanism enabled.

For more information on connecting to external WXS grids go to: http://www-01.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/bc23791_.htm?cp=SSMKHH_10.0.0%2F1-10-6-5-0-3&lang=en

Common reasons for choosing an external grid over the embedded global cache

• You need to configure the grid for specific capabilities not supported by the embedded global cache.
• You have an architectural preference for the cached data not to be located in the integration servers themselves.
• You want to decouple the availability of the cache from that of the integration servers.
• You really need an enterprise cache, with multiple applications (other than IBM Integration Bus) accessing the data.
• You have (or want) sophisticated, or custom, tools to manage the cache.
• The cache needs to span multiple datacenters, for disaster recovery.

Comparison of functionality

The following table summarizes some of the common requirements when considering the embedded global cache or an external grid:

Requirement	Embedded global cache	External WXS grid
Cache available to IBM Integration Bus out of the box with minimal configuration	♦
Cache components hosted inside integration server processes	♦
Simple MbGlobalMap access to the cache	♦	♦
Same cached data can be accessed by multiple brokers	♦	♦
Connections managed by IBM Integration Bus	♦	♦
Resource statistics and activity log for cache interactions	♦	♦
Manage your cache components outside of IBM Integration Bus processes		♦
Configure number of partitions and number/type of replicas		♦
Configure multiple zones		♦
Define your own backing maps, both fixed and templates		♦
Configure your desired locking strategy, eviction strategy and copy mode		♦
Use plugins (for example eviction or loading)		♦
Transport Layer Security to, and within, the grid.		♦
Access to other configuration options via WXS objectgrid.xml and deployment.xml files		♦
Ability to configure Grid name, zones, quorum and heartbeat settings on the components		♦
Enterprise grid capability, used by multiple applications		♦
Administer and monitor your grid outside of IBM Integration Bus		♦
Multi-master replication to sync grids in different datacenters		♦

Details of fixed configuration settings for the embedded grid

In the table above, there are a number of configuration options that you can set on an external grid. Most of these are specified in the deployment.xml and objectgrid.xml configuration files for the grid. (Although some of them are specified on startup of the relevant catalog or container server.)

Most of these properties are fixed for the embedded global cache,  and the values cannot be changed. You cannot modify the underlying deployment.xml and objectgrid.xml configuration files for the global cache in a way that is supported by IBM.

At the time of writing , the following list provides details of how these properties are defined for the global cache:

Backing maps	One template, matches all map names – but “SYSTEM.BROKER.*” is reserved for future use.
Eviction strategy	Last Update Time (LUT). Default time to live is 0 (lives forever), but can be overridden via MbGlobalMapSessionPolicy.
Locking strategy	Pessimistic
Copy mode	Not specified, so the default setting is used – COPY_ON_READ_AND_COMMIT
Number of partitions	13
Replicas	Maximum 1 synchronous replica, no asynchronous replicas
Zones	1 zone only, WMBZone
Grid name	WMB
Development mode	Determined dynamically on startup. If the grid contains more than one catalog server, across more than one host, then development mode is switched off. This ensures that primary and replica shards for a given partition cannot be placed on the same host in a multi-broker topology (with multiple catalogs).
Quorum	False
Heartbeat interval	Typical
Number of containers	Can be configured. But, when using a cache policy, you get no more than 4 per integration node (broker).
Plugins	None used

Summary

The primary value of the embedded cache is that it is packaged with, and designed and optimized for, use within (and between) integration nodes of IBM Integration Bus. There is flexibility to change the topology of the grid as required but you are not able to modify the underlying WXS configuration of the grid. The life of the embedded cache is directly bound to the life of the integration nodes within which it resides.

When the facilities or default configuration provided by the embedded cache do not meet your needs, then there is the flexibility to use an external WXS cache, and to make the data in this cache available to both integration flows and other applications outside of IBM Integration Bus. This external cache must be acquired and provisioned independently. However once it is installed and configured then it is just as easily accessed in IBM Integration Bus integration flows as the embedded cache.