Streams and neighboring brokers

In a WebSphere® MQ Publish/Subscribe network, a broker does not have to 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 Event Broker broker joins the network, it supports all the streams of its neighboring WebSphere MQ Publish/Subscribe brokers. This means that clients of the WebSphere Event Broker broker can target publications for any stream supported by any of its WebSphere MQ 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 Event Broker broker.

The effects of adding a WebSphere Event Broker broker into a multi-stream WebSphere MQ Publish/Subscribe environment are illustrated in the following figure. The WebSphere Event Broker broker, NEWBROKER, has been used to join WebSphere MQ Publish/Subscribe brokers, BROKERA, and BROKERB.

A heterogeneous network

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 default stream queue SYSTEM.BROKER.DEFAULT.STREAM is always supported by every broker in a WebSphere MQ Publish/Subscribe network, and must be defined at every WebSphere Event Broker broker in a heterogeneous network. At each broker, you must define and deploy a message flow to service this queue.

When a WebSphere Event Broker broker is integrated into a WebSphere MQ Publish/Subscribe network, and links two or more WebSphere MQ 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 Event Broker broker.

For example, the WebSphere Event Broker broker NEWBROKER 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 Event Broker broker for other streams shown in the figure only if one of its WebSphere MQ Publish/Subscribe neighbors can send a message to one of these queues. A message is sent if one of the following events occurs:
  1. A subscription to a publication on one of these streams is registered by a client of the WebSphere Event Broker broker.
  2. A DeletePublication command for the stream is issued by a client anywhere within the broker network.
If you are unsure about whether the above cases might occur, create stream queues and message flows in the WebSphere Event Broker broker for every stream that is supported by a WebSphere MQ Publish/Subscribe neighbor. If you do not do this, the following might happen:
  • Messages sent from WebSphere MQ Publish/Subscribe brokers are put on the dead-letter queue (DLQ) of the WebSphere Event Broker broker if the stream queue does not exist on that broker.
  • Messages build up on stream queues on the WebSphere Event Broker broker if the stream queue exists but no message flow is deployed to service it.
Related tasks
Subscribing
Related reference
Streams
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. All Rights Reserved.
Last updated : 2009-01-07 15:41:07

aq19800_