Broker 10.5 | webMethods Broker Documentation | Administering webMethods Broker | Managing Cluster Gateways | Overview
Cluster Gateway Connections, Cluster Gateways, Cluster Gateway Pairs, and Cluster Gateway Brokers
Cluster Gateway Names
Connecting Multiple Clusters with Cluster Gateways
A cluster gateway enables two clusters to exchange documents. Unlike clusters, whose constituent Brokers automatically share their document types and client groups, a cluster gateway requires an administrator to explicitly specify which document types the clusters are permitted to send and receive. The client group information is not shared between two clusters. Only the Brokers within a cluster share the client group information.
Typically, you use a cluster gateway when you want to share documents between two different application domains or administrative domains. For example, in a configuration where one cluster handles documents related to employee records and another cluster handles documents related to IT resources, the IT cluster might need to receive certain documents related to employee start, exit, or transfer events. To enable these documents to travel to the IT cluster, you can link the clusters using a gateway.
Unlike a territory gateway, which allows only one connection between two territories, a cluster gateway allows multiple identical connections between two clusters. These multiple identical connections not only provide redundancy in the system to handle multi-publish scenarios, but they also facilitate support for failover mechanisms if a Broker or a cluster gateway connection in the gateway clusters fails.
To understand the concept of cluster gateways, suppose cluster C1 contains three Brokers: Broker A, Broker B, and Broker C, and cluster C2 has two Brokers: Broker X and Broker Y. The cluster gateway between cluster C1 and cluster C2 can have the following identical gateway connections:
*Broker A to Broker X
*Broker A to Broker Y
*Broker B to Broker X
*Broker B to Broker Y
*Broker C to Broker X
*Broker C to Broker Y
You designate one of the gateway connections from a local Broker (in the local cluster) to a remote Broker (in the remote cluster) as the primary connection. The primary connection is the default gateway connection that the local Broker (in the local cluster) uses for forwarding the messages to a remote cluster. If the primary connection fails, the next gateway connection in that local Broker takes over the task of forwarding the messages to the remote cluster. For example, in the above scenario, you designate "Broker A to Broker X" gateway connection as the primary connection. If the "Broker A to Broker X" connection fails, the "Broker A to Broker Y" connection takes over the task of transporting messages from Broker A across the gateway between cluster C1 and cluster C2.
You can also use a cluster gateway connection to link identical clusters that are geographically separated. For example, if you have a cluster that handles documents related to manufacturing operations in North America and you expand the application to operations in Asia, you might decide to create an identical cluster for the Asian region and then link the clusters using a gateway connection. In this case, you are using a cluster gateway to conserve wide-area network bandwidth by explicitly restricting what document types can flow across the network link.
When you use My webMethods to set or change permissions such as "Keep Alive Interval" and "Shared Document Types" on one gateway connection, the changes are applied to all the gateway connections. When you use Broker administration APIs to create and manage cluster gateways, make sure that all the cluster gateways have an identical set of permissions. Otherwise, the cluster gateway might behave inconsistently.