IBM BPM, V8.0.1, All platforms > Install IBM BPM > Plan for IBM BPM > Plan the ND environment > Topologies of an ND environment

Remote Messaging topology pattern

The Remote Messaging topology pattern is an IBM-supplied topology pattern. In a Remote Messaging topology pattern, the deployment environment functions are divided between two separate clusters.

The Remote Messaging topology pattern provides a separate cluster for the messaging function. This topology pattern is suitable for scenarios involving asynchronous invocations, because the cluster can be scaled for this load. The components are divided between the two clusters.

For environments that must support numerous human tasks, long-running business processes, state machines, and asynchronous interactions, a Remote Messaging topology pattern has advantages over the Single Cluster topology pattern.

Separating the messaging infrastructure into a separate cluster removes the messaging overhead from the application target cluster. When you have a separate messaging infrastructure, you need less memory for the application target cluster members. This topology pattern also differs from the Single Cluster topology pattern in terms of the hardware required. Because there are two clusters with multiple cluster members, the hardware requirements are greater for distributed environments.

From an administrative perspective, the requirements for the Remote Messaging topology pattern are greater than the requirements for the Single Cluster topology pattern. Additional clusters and additional cluster members increase the administrative effort required. In addition, because you are distributing the messaging engines across the members of the messaging cluster, create and maintain policies.

In the Remote Messaging topology pattern, the supporting applications and the Common Event Interface (CEI) components are still part of the application target cluster. Thus, for environments that make extensive use of CEI, the Remote Messaging topology pattern might not be ideal either. For small to medium-sized businesses, or for businesses without extensive monitoring or auditing requirements, this topology pattern is generally suitable.

The scalability options for the Remote Messaging topology pattern are as straightforward as the options for the Single Cluster topology pattern. Because the messaging engines are subject to one of n policies (each messaging engine is active on only one server), adding additional members to the messaging cluster has little effect. When you use policies to spread the messaging engines across server members, you can divide the messaging burden across a maximum of three servers. (The SCA.SYSTEM and SCA.APPLICATION engines are active on the same server.) Thus, adding more than three cluster members to the messaging cluster has no effect on the processing capability of the messaging infrastructure. Scaling the application target cluster is relatively easy. If you need additional processing capability for your applications or for the supporting infrastructure, you can add additional nodes and members to the application target cluster.

In a two-cluster topology pattern, the messaging members run on the messaging cluster and all other all deployment environment functions and functional groups of components run on a the application deployment target cluster.

The application deployment target cluster hosts the following:

The messaging infrastructure cluster hosts the following:

Figure 1. Remote Messaging topology pattern

Topologies of an ND environment