Streams and topics
Queued publish/subscribe has the concept of a publication stream that does not exist in the integrated publish/subscribe model. In queued publish/subscribe, streams provide a way of separating the flow of information for different topics. In IBM® WebSphere® MQ Version 6.0, a stream is implemented as a queue, defined at each broker that supports the stream. Each queue has the same name (the name of the stream). From IBM WebSphere MQ Version 7.0 onwards, a stream is implemented as a top-level topic that can be mapped to a different topic identifier administratively.
The default stream SYSTEM.BROKER.DEFAULT.STREAM
is set up automatically for all brokers and queue managers on a
network, and no additional configuration is required to use the default stream.
Think of the default stream as an unnamed default topic space. Topics
published to the default stream are immediately available to all connected Version 6.0 brokers, and all queue managers
from Version 7.0 onwards, with queued
publish/subscribe enabled. Named streams are like separate, named,
topic spaces. The named stream must be defined on each broker where
it is used.
When you define a topic, the topic is available to Version 6.0 publish/subscribe brokers, and to publishers and subscribers running on a later version of IBM WebSphere MQ, with no special configuration.
If the publishers and subscribers are on different queue managers, then after the brokers are connected in the same broker hierarchy, no further configuration is required for the publications, and subscriptions to flow between them. The same interoperability works in reverse, too.
Named streams
A solution designer, working
with the queued publish/subscribe programming model, might decide
to place all sports publications into a named stream called
Sport
. In Version 6.0 a stream
is often replicated automatically onto other brokers that use the
model queue, SYSTEM.BROKER.MODEL.STREAM
. However,
for the stream to be available to a queue manager that runs on Version 7.0 onwards with queued publish/subscribe
enabled, the stream must be added manually.
If you migrate a
queue manager from Version 6.0, running
the command strmqbrk migrates Version 6.0 named streams to topics. The stream
Sport
is mapped to the topic Sport
. This
is not applicable to z/OS®.
Queued publish/subscribe applications that subscribe to Soccer/Results
on stream Sport
work without change. Integrated
publish/subscribe applications that subscribe to the topic
Sport
using MQSUB, and supplying the
topic string Soccer/Results
receive the same publications
too.
When the topic Soccer/Result
is created
by strmqbrk, it is defined as a child of the topic
Sport
, with the topic string Sport
. A subscription
to Soccer/Results
is realized as a subscription to
Sport/Soccer/Results
, and so publications to the
Sport
stream are mapped to different place in topic space
to publications to a different stream, such as Business
.
- You continue to maintain publish/subscribe applications on version 6 queue managers, which interoperate with newly written publish/subscribe applications running on later queue managers.
- You continue to develop your queued publish/subscribe applications that are running on later version queue managers, rather than migrate the applications to the integrated publish/subscribe MQI interface.
- The default mapping of streams to topics leads to a "collision" in topic space, and publications on a stream have the same topic string as publications from elsewhere.
Authorities
By default, at the root of the
topic tree there are multiple topic objects: SYSTEM.BASE.TOPIC,
SYSTEM.BROKER.DEFAULT.STREAM
, and SYSTEM.BROKER.DEFAULT.SUBPOINT
. Authorities (for example, for publishing or subscribing) are determined
by the authorities on the SYSTEM.BASE.TOPIC
; any
authorities on SYSTEM.BROKER.DEFAULT.STREAM
or
SYSTEM.BROKER.DEFAULT.SUBPOINT
are ignored. If either of
SYSTEM.BROKER.DEFAULT.STREAM
or SYSTEM.BROKER.DEFAULT.SUBPOINT
are deleted and re-created with a non-empty topic string, authorities
defined on those objects are used in the same way as a normal topic object.
Mapping between streams and topics
A queued publish/subscribe stream is
mimicked in Version 7.0 onwards by creating
a queue, and giving it the same name as the stream. Sometimes the
queue is called the stream queue, because that is how it appears to
queued publish/subscribe applications. The queue is identified to
the publish/subscribe engine by adding it to the special namelist
called SYSTEM.QPUBSUB.QUEUE.NAMELIST
. You can add
as many streams as you need, by adding additional special queues to
the namelist. Finally you need to add topics, with the same names
as the streams, and the same topic strings as the stream name, so
you can publish and subscribe to the topics.
However, in exceptional circumstances, you can give the topics corresponding to the streams any topic strings you choose when you define the topics. The purpose of the topic string is to give the topic a unique name in the topic space. Typically the stream name serves that purpose perfectly. Sometimes, a stream name and an existing topic name collide. To resolve the problem, can choose another topic string for the topic associated with the stream. Choose any topic string, ensuring it is unique.
The topic string defined in the topic definition is prefixed in the normal way to the topic string provided by publishers and subscribers using the MQOPEN or MQSUB MQI calls. Applications referring to topics using topic objects are not affected by the choice of prefix topic string - which is why you can choose any topic string that keeps the publications unique in the topic space.
The remapping of different streams onto different topics relies on the prefixes used for the topic strings being unique, to separate one set of topics completely from another. You must define a universal topic naming convention that is rigidly adhered to for the mapping to work. In Version 7.0, if topic strings collided you might use streams to separate the topic spaces. From Version 7.0 onwards, you use the prefixing mechanism to remap a topic string to another place in topic space.
Example
In Figure 1, topic
'Sport'
has the topic string 'xyz'
resulting
in publications that originate from stream 'Sport'
being prefixed with the string 'xyz'
in the version
7 queue manager topic space. Publishing or subscribing in version
7 to the topic 'Sport'
prefixes 'xyz'
to the topic string. If the publication flows to a version 6 subscriber,
the prefix 'xyz'
is removed from the publication
and it is placed in the 'Sport'
stream. Conversely,
when a publication flows from version 6 to version 7, from the
'Sport'
stream to the 'Sport'
topic, the
prefix 'xyz'
is added to the topic string.