Home

 

Streams

 

+

Search Tips   |   Advanced Search

 

Streams provide a way of separating the flow of information for different topics. A stream is implemented as a set of queues, one at each broker that supports the stream. Each queue has the same name (the name of the stream). The default stream set up between all the brokers in a network is called...

SYSTEM.BROKER.DEFAULT.STREAM

Streams can be created by an application or by the administrator. Stream names are case sensitive, and stream queues must be local queues (not alias queues). Stream names beginning with the characters 'SYSTEM.BROKER.' are reserved for WebSphere MQ use.

A broker has a separate thread for each stream that it supports. If multiple streams are used, the broker can process publications arriving at different stream queues in parallel. Other advantages of using streams are as follows:

• To provide a high level grouping of topics.

  Streams act as high-level qualifiers for topics. For instance, in the example shown in Figure 1, a separate stream might be set up for Sport. In this case, to get the soccer results we need to subscribe to the Soccer/Results topic specifying the 'Sport' stream. The other topics (Stock, Films, TV) remain on the default stream, unless other streams are set up for them.

  Note that wildcard characters are not used for stream names, and that wildcards do not span streams. For example, a subscriber to topic '*' on the 'Sport' stream does not receive publications published on other streams.

• To restrict the range of publications and subscriptions that a broker has to deal with.

  A given stream can be restricted to a subtree of a hierarchy or the stream can be split into separate hierarchies that are not connected (see Broker networks). For example, if broker 1 in Figure 4 does not support a stream supported by its children, brokers 2 and 3 each form the root of a separate hierarchy for that stream, and no subscriptions or publications flow between the two hierarchies.

• To provide access control.

  A broker has a stream queue for each stream that it supports. Normal WebSphere MQ access control techniques can be used to control whether a particular application is authorized to put messages onto this queue (publish to this stream), or to browse messages from the queue (subscribe to it). Although a subscribing application does not get messages from the broker's queue directly, the broker checks the subscriber's authorization to subscribe to the broker's queue when it registers the subscription. This authorization check takes place at the broker to which the application publishes or subscribes, not at other brokers to which the publication or subscription might be propagated.

  The administrator can change publishers' and subscribers' stream queue authorizations dynamically (using normal WebSphere MQ queue management facilities), although the changes might not take effect until the broker is restarted.

• To define a certain quality of service for broker-to-broker communication of publications.

  We can send information associated with one stream along different channels from those used for another stream. For example, a non-urgent stream might have its associated channels active only during the night.

• To allow different queue attributes (such as maximum message length) to be assigned for publications on different streams.

 

Home