Streams and neighboring brokers

In an MQSeries Publish/Subscribe network a broker might not support the same set of streams as its neighbors. If a broker does not support a stream that is supported by one of its neighboring brokers, publications associated with that stream are not available to clients at that broker.

When a WebSphere Business Integration Message Broker broker is added to the network, it supports all the streams that are supported by its neighboring MQSeries Publish/Subscribe brokers. This means that clients of the WebSphere Business Integration Message Broker broker can target publications for any stream supported by any of its MQSeries Publish/Subscribe neighbors.

However, to make these publications available, you must define the stream queues, and define and deploy the message flows that support them, to the WebSphere Business Integration Message Broker broker.

The effects of adding a WebSphere Business Integration Message Broker broker into a multi-stream MQSeries Publish/Subscribe environment are shown in the following example:

A heterogeneous network. This figure shows a <ph conref='edvent.dita#edvent/mqsi'></ph> broker, NEWBROKER, placed between two <ph conref='edvent.dita#edvent/sdk'></ph> brokers, BROKERA, and BROKERB. It also lists the streams associated with each of the two <ph conref='edvent.dita#edvent/sdk'></ph> brokers.
The WebSphere Business Integration Message Broker broker, NEWBROKER, has been used to join MQSeries Publish/Subscribe brokers, BROKERA, and BROKERB.

The default stream queue SYSTEM.BROKER.DEFAULT.STREAM is always supported by every broker in a MQSeries Publish/Subscribe network, and must be defined for every WebSphere Business Integration Message Broker broker in a heterogeneous network. At each broker, you must also define and deploy a message flow to service this queue.

When a WebSphere Business Integration Message Broker broker is integrated into a MQSeries Publish/Subscribe network, and links two or more MQSeries Publish/Subscribe brokers that share common streams, you must define the common stream queues, and define and deploy the message flows that service them, to the WebSphere Business Integration Message Broker broker.

For example, the WebSphere Business Integration Message Broker broker NEWBROKER shown in the previous figure must have a stream queue defined for BULLETIN.STREAM. It must also have a message flow defined and deployed to provide a publication service for that queue.

You need to define stream queues and associated message flows to the WebSphere Business Integration Message Broker broker for the other streams shown in the figure only if one of its MQSeries Publish/Subscribe neighbors might send a message to one of these queues. A message is sent if one of the following events occur:
  1. A subscription to a publication on one of these streams is registered by a client of the WebSphere Business Integration Message Broker broker.
  2. A DeletePublication command for the stream is issued by a client anywhere within the broker network.
If you are not sure whether the above cases might occur, create stream queues and message flows in the WebSphere Business Integration Message Broker broker for every stream that is supported by a MQSeries Publish/Subscribe neighbor. If you do not do this, you might see the following results:
  • Messages sent from MQSeries Publish/Subscribe brokers are put to the dead-letter queue (DLQ) of the WebSphere Business Integration Message Broker broker if the stream queue does not exist on that broker.
  • Messages build up on stream queues on the WebSphere Business Integration Message Broker broker if the stream queue exists but no message flow is deployed to service it.