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 and Remote Support topology pattern

The Remote Messaging and Remote Support topology pattern is an IBM-supplied topology pattern. In a Remote Messaging and Remote Support topology pattern, the deployment environment functions are divided among three separate clusters.

With this three-cluster topology pattern components are divided among the messaging, support, and application deployment target clusters. For users of IBM BPM Standard, this topology pattern was the default and preferred topology. Now, for IBM BPM Standard the default and preferred topology is four clusters, with the additional web cluster hosting Business Space, Process Portal, and REST API services. For more information about the four-cluster topology, see Remote Messaging, Remote Support, and Web topology pattern.

When you create three clusters, each with its own functions and applications, you add an additional administrative burden. As you add clusters and cluster members, your performance tuning plan and the troubleshooting burden can expand greatly. Spreading messaging engines across the members of the messaging cluster also adds to the administrative burden associated with creating and maintaining policies.

From a scalability standpoint, the Remote Messaging and Remote Support topology pattern provides good flexibility. Because each of the distinct functions within IBM BPM is divided among the three clusters, you can pinpoint performance bottlenecks and adjust the cluster size fairly easily. If you need additional Common Event Interface (CEI) processing, you can simply add a node and cluster member to the support cluster. Similarly, if you need more processing capability for your business processes or human tasks, you can add additional nodes and members to the application target cluster. Because expanding the messaging infrastructure beyond three cluster members has no effect on processing capability, the scalability limitations of the Remote Messaging topology pattern also apply to the Remote Messaging and Remote Support topology pattern.

Because the application target cluster runs your business integration applications only, performance tuning and diagnostics are simpler than in the topology patterns where the application target cluster has additional responsibilities. The Remote Messaging and Remote Support topology pattern is also ideal for environments that make extensive use of CEI for monitoring and auditing (including environments with IBM Business Monitor). When you separate the support infrastructure into its own cluster, you have a dedicated set of cluster members for CEI and for supporting applications.

The application deployment target cluster hosts the following:

The messaging infrastructure cluster hosts the following:

The support infrastructure cluster hosts the following:

Figure 1. Remote Messaging and Remote Support topology pattern

In this topology you must also configure a routing server such as IBM HTTP Server, WebSphere Application Server proxy server, or a reverse proxy server to ensure that requests that are intended for Process Portal are directed to the correct cluster.


Resource allocation example

The following figure shows one way to use the Remote Messaging and Remote Support topology pattern to allocate resources. The figure shows three hosts. Host A has Server 1 and Server 3; Host B has Server 2, Server 4, and Server 5 and Host C has Server 6 and Server 7. Because the heaviest load for this installation is for application use, more resources for Server 1, Server 2, and Server 6 are allocated for the application deployment target cluster (Cluster 3) than for the other functions.

Important: Load balancing is not available for the default configuration Remote Messaging and Remote Support topology pattern. That configuration uses a single messaging engine bus, while the load balancing feature requires at least two messaging engine buses.

Figure 2. Resource allocation example

Topologies of an ND environment