Message VPN Bridges

Message VPN bridges can link two Message VPNs so that messages published to one Message VPN that match the topic subscriptions set for the bridge are also delivered to the linked Message VPN.

A Message VPN bridge allows for the delivery of Direct messages that match an explicit set of topic subscriptions from a remote Message VPN to a local Message VPN.

Guaranteed messages can also be delivered over Message VPN bridges when additional parameters are configured for the remote Message VPN.

You can use Message VPN bridges in these scenarios:

• Linking two Message VPNs with different names to enable Direct or Guaranteed messages published to one Message VPN to be delivered to the other Message VPN.
• Linking two Message VPNs with the same names on two separate event brokers to enable Guaranteed messages published to one Message VPN to be delivered to the other Message VPN.
• Linking two Message VPNs with the same names on two separate event brokers to enable Direct messages published to one Message VPN to be delivered to the other Message VPN.

A bridge can be uni-directional (messages pass over the bridge in only one direction) or bi-directional (messages pass over the bridge in both directions). The messages that pass in either direction may be different, depending on the remote topic subscriptions that are assigned to the bridge for each local Message VPN.

This section discusses the behavior, configuration, and use of Message VPN Bridges, including:

• Managing Access to Messages
• Establishing Message VPN Bridges
• Guaranteed Messaging Over Message VPN Bridges
• Uni-directional Versus Bi-directional Message VPN Bridges

If you are using Dynamic Message Routing (DMR), you can use DMR instead of a static Message VPN Bridge to deliver messages to a linked Message VPN. For more information, see DMR or a Message VPN Bridge?.

Managing Access to Messages

You can use Message VPN bridges to manage which messages pass from one Message VPN to another. When a Message VPN bridge links two Message VPNs, the topic subscriptions assigned to the bridge (or the bridge queue for Guaranteed messages) determine which messages are delivered from a remote Message VPN to the local Message VPN it is linked to.

Typical Message VPN Bridge Configuration

Establishing Message VPN Bridges

To establish a Message VPN bridge, you create the bridge in a local Message VPN, which automatically creates an internal client for the bridge. This client can establish a connection to a remote Message VPN. On the remote event broker, the Message VPN bridge functions like a client connection and login attempts to the remote event broker are authenticated in the same manner as other client connections. Control and data messages are sent between the local and remote Message VPNs through the client connection.

After you create a Message VPN bridge, you must configure the following parameters before the bridge can be enabled and messages can begin to be transferred:

• remote Message VPN and event broker—This is the remote Message VPN and event broker to receive messages from. The event broker is specified by either its name or “connect-via” address expressed as an IP address or DNS name. Multiple remote Message VPNs can also be specified in order of preference. These redundant remote Message VPNs provides some protection if the first remote Message VPN the bridge connects to becomes unavailable.
• remote Message VPN authentication scheme—the authentication scheme that the bridge uses to authenticate with the remote Message VPN. An authentication scheme is required for each remote Message VPN that is configured for the bridge.
  • basic authentication client username—the username used to authenticate with the remote Message VPN, if basic authentication is configured. An optional password can also be specified.
  • client certificate authentication certificate file—the certificate file used to authenticate with the remote Message VPN, if client certificate authentication is configured. If no certificate file is specified, the bridge will present the event broker’s server certificate for authentication.

By default, remote Message VPN bridge connections are not available to clients—you must first configure permissions in the client profile that is assigned to the client username. You can enable permissions to create bridge connections through the clientsʼ assigned client profile. For more information, see Creating a Client Profile.

• remote subscription topic—If you want to transfer Direct messages over the Message VPN bridge, configure one or more topic subscriptions for the bridge that will attract Direct messages published to the remote Message VPN. Topics are added to the top level of the bridge and apply across all hosts. The set of topics may be changed while the bridge is enabled.

• remote message spool queue—If you want to transfer Guaranteed messages over the Message VPN bridge, use this parameter to specify an existing durable queue (with an exclusive access type) on the remote Message VPN to which a consumer flow will connect. Topic subscriptions must be added to the queue to attract messages published to specific topics of interest.

Guaranteed Messaging Over Message VPN Bridges

To use a Message VPN bridge to transfer Guaranteed messages from a remote Message VPN to a local Message VPN, you require:

• a durable queue provisioned on the remote Message VPN
• a durable topic subscription added to that durable queue so that messages with a topic match can be spooled to the queue

Then, when you create the bridge on the local Message VPN, you must specify the following:

• the remote Message VPN to connect the bridge to
• the provisioned queue on the remote Message VPN

When the bridge is established, a consumer flow is bound to the queue. Then messages published to the remote Message VPN with matching topics can be transported over the bridge to the consuming event broker using the bound flow.

For clients to receive these messages, topic subscriptions must be added to the local Message VPN:

• For the Guaranteed messages received from the bridge to remain as Guaranteed messages (that is, retain their non-persistent or persistent delivery modes), a durable queue that has been assigned a matching topic subscription is required. In this case, the received messages are persisted because they are saved to the message spool.
• If the Guaranteed messages received from the bridge only match client topic subscriptions on the local Message VPN, the messages are converted to Direct messages and are not persisted.
• If there are no matching subscriptions on the local Message VPN, the event broker discards the messages.

For example, the Guaranteed message flow may work as follows:

• Event Broker 1 has a Message VPN bridge configured to establish a Guaranteed message flow to a durable queue on Event Broker 2

• The specified queue is configured on Event Broker 2 with a list of topics that are mapped to the queue.

• All messages published to any of the mapped topics are transported through the Guaranteed message flow over the Message VPN bridge to Event Broker 1

• After reaching Event Broker 1, the messages are delivered to all queues and topic endpoints with matching subscriptions.

Message VPN Bridge Configuration for Guaranteed Messaging

If you plan to establish multiple consumer flows to a remote Message VPN, we recommend creating separate durable message queues in the Message VPN for each of the inbound bridges that will receive Guaranteed messages.

Avoiding Loss of Guaranteed Messages with VPN Bridges

When properly configured, Guaranteed messages will not be lost when sent over a Message VPN bridge. The normal operational behavior is as follows:

• Guaranteed messages do not unspool from the remote Message VPN of a Message VPN bridge unless they can be spooled by all matching endpoints on the local Message VPN. When a Guaranteed message cannot be successfully spooled to all endpoints with matching subscriptions on the local Message VPN, the event broker periodically retransmits the message across the Message VPN bridge. Once the Guaranteed message is successfully spooled to all matching endpoints on the local Message VPN, then it is unspooled from the remote Message VPN.

• If a Guaranteed message is rejected by the local Message VPN when it is retransmitted across the bridge, no other Guaranteed messages can traverse the bridge. This can cause the bridge queue on the remote Message VPN to fill up. If the bridge queue reaches its quota, it will reject Guaranteed messages just published to the remote Message VPN. Direct messages, however, including those that are promoted on the local Message VPN, continue to traverse the bridge while in this state.

• Once the condition that prevents the Guaranteed messages to be spooled by the endpoints on the local Message VPN is cleared, Guaranteed messages begin to traverse the Message VPN bridge again. Once the bridge queue has dropped below quota, it starts accepting newly published Guaranteed messages again.

The correct configuration for this behavior requires the reject‑msg‑to‑sender‑on‑discard option to be enabled on the durable endpoints and for a matching durable subscription to be configured on the local Message VPN. By default, the reject-msg-to-sender-on-discard option is enabled on queues but is disabled on topic endpoints.

Although the reject-msg-to-sender-on-discard option only needs to be enabled on one matching endpoint in the local Message VPN to get the desired behavior, it is recommended that it be enabled on all endpoints in the local Message VPN.

The local Message VPN must also have a matching durable subscription for the Guaranteed message. If there are no endpoints with matching subscriptions, then the message is discarded as “No Eligible Destination” on the local Message VPN and the message is unspooled from the bridge queue on the remote Message VPN. This prevents the bridge consumer flow from being blocked by messages that have no destination on the local Message VPN.

If the Guaranteed messages received from the bridge match client topic subscriptions on the local Message VPN, the messages are converted to Direct messages and are not persisted.

Uni-directional Versus Bi-directional Message VPN Bridges

Subscriptions must be statically configured on a Message VPN bridge to attract Direct messages from a remote Message VPN. The diagram below shows a uni‑directional bridge that has been configured on Event Broker 1 so that messages from that remote Message VPN with matching topics can be transferred over the bridge from Event Broker 2 using a single TCP connection.

Uni-directional Message VPN Bridge

It is possible to extend the configuration shown above to create a bi-directional bridge between the two Message VPNs. A bi-directional bridge essentially creates a bridge link in the opposite direction of an existing uni-directional bridge; where the local Message VPN of the uni-directional bridge is the remote Message VPN that the new bridge links to, and the remote Message VPN that the uni-directional bridge links to is the local Message VPN of the new bridge link.

As shown in the figure below, by adding a bridge configuration on Event Broker 2 from Message VPN yellow to Message VPN blue on Event Broker 1, a bi-directional bridge is established, and a single TCP connection is used to transport all messages between the two Message VPNs.

The No Local Delivery property is automatically enabled for Message VPN bridges to prevent forwarding loops. This means that messages transferred across a Message VPN bridge to a remote Message VPN cannot then be sent back to the local Message VPN they originally came from to fulfill matching topic subscriptions again.

Bi-directional Message VPN Bridge

Establishing Bi-directional Bridge Links

Two uni-directional bridges cannot be established between the same two Message VPNs—a bi-directional bridge must be used. Therefore, before a local event broker attempts to establish a bridge to a remote event broker, it inspects the existing incoming bridges to see if there is a compatible bridge already established from the remote event broker that can be used. To be compatible, an existing bridge from the remote event broker must pass the following tests:

• the remote event broker name from the peer event broker must match the local event broker name
• the event broker name of the peer must match the specified remote event broker name
• the remote Message VPN of the peer must match the local Message VPN
• the Message VPN of the peer must match the specified remote Message VPN
• if TLS/SSL encryption is to be used, then TLS/SSL must be configured on both bridges (that is, an TLS/SSL bridge is not compatible with a non-TLS/SSL bridge)

If there is a compatible incoming bridge, then no new Message VPN bridge connection is required and an existing uni‑directional Message VPN bridge is transformed into a bi-directional Message VPN bridge. The login is performed with the existing connection.