WebSphere Message Brokers
File: aq19800_
Writer: Terry Cowling

Reference topic

This build: July 31, 2007 21:35:46

Streams and neighboring brokers

In an WebSphere MQ 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 Message Broker broker is added to the network, it supports all the streams that are supported by its neighboring WebSphere MQ Publish/Subscribe brokers. This means that clients of the WebSphere Message 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 Message Broker broker.

The effects of adding a WebSphere Message Broker broker into a multi-stream WebSphere MQ 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 Message Broker broker, NEWBROKER, has been used to join WebSphere MQ Publish/Subscribe brokers, BROKERA, and BROKERB.

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 for every WebSphere 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 Message 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 Message Broker broker.

For example, the WebSphere 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 Message Broker broker for the other streams shown in the figure only if one of its WebSphere MQ 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 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 Message Broker broker for every stream that is supported by a WebSphere MQ Publish/Subscribe neighbor. If you do not do this, you might see the following results:
  • Messages sent from WebSphere MQ Publish/Subscribe brokers are put to the dead-letter queue (DLQ) of the WebSphere Message Broker broker if the stream queue does not exist on that broker.
  • Messages build up on stream queues on the WebSphere Message Broker broker if the stream queue exists but no message flow is deployed to service it.
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:35:46

aq19800_ This topic's URL is: