Typically, one of the basic tasks of managing a broker network is to partition the network so that certain queues and topics are restricted to a sub-domain, while messages on other queues and topics are allowed to cross domains. This kind of domain management can be achieved by applying filters at certain points in the network. Fuse Message Broker lets you define filters on network connectors and message selectors on consumers in order to control the flow of messages throughout the network.

The following characters can be used to define wildcard matches for topic names and queue names:

Wildcards are meant to be used with destination names that have a segmented structure, like a path name—for example, PRICE.STOCK.NASDAQ.IBM or PRICE.STOCK.NYSE.SUNW—where the segments are delimited by the . character. The following table shows some examples of destination wildcards and describes what names they would match.

It is possible to filter the messages that pass through a network connector by specifying destinations to include and destinations to exclude. The following child elements of networkConnector are used to filter dynamic destinations:

Example 8 shows a network connector that is configured to filter dynamic destinations. In this example, the connector transmits stock prices from any exchange except the NYSE and transmits orders to trade stocks for any exchange except the NYSE.

<networkConnectors>
    <networkConnector name="linkToBrokerB"
       uri="static:(tcp://localhost:61002)"
       networkTTL="3">
        <dynamicallyIncludedDestinations>
            <queue physicalName="TRADE.STOCK.>"/>
            <topic physicalName="PRICE.STOCK.>"/>
        </dynamicallyIncludedDestinations>
        <excludedDestinations>
            <queue physicalName="TRADE.STOCK.NYSE.*"/>
            <topic physicalName="PRICE.STOCK.NYSE.*"/>
        </excludedDestinations>
    </networkConnector>
</networkConnectors>

There is no need to filter statically propagated destinations, because destinations are only transmitted statically when they are listed explicitly in a staticallyIncludedDestinations element.

Fuse Message Broker supports standard JMS selectors, which enable consumers to filter messages from a particular destination by testing the contents of a message's JMS headers. When a consumer subscribes to a particular destination, the standard JMS API can be used to specify a selector (see javax.jms.Message for more details).

If your consumers use JMS selectors, you should be aware that some interaction can occur between JMS selectors and conduit subscriptions. In general, JMS selectors are always applied by the consumer's local broker (that is, the broker to which the consumer is directly connected). But if the conduit subscriptions option is enabled (which it is by default), JMS selector information is omitted from any conduit subscriptions transmitted to a remote broker. This implies that the remote broker (or brokers ) do not perform any filtering based on JMS selectors. There are certain scenarios where this behavior can cause problems.

For example, consider the broker network shown in Figure 17, where conduit subscription is enabled throughout the network. Both of the consumers, C1 and C2, subscribe to the same queue and they also define JMS selectors as follows: C1 selects messages for which the region header is equal to us; and C1 selects messages for which the region header is equal to emea.

Figure 17. Interaction between JMS Selector and Conduit Subscription

Now consider what happens when a producer, P, connects to broker A and starts sending messages to the queue. The consumer subscriptions, s1 and s2, automatically propagate to broker A. But because these subscriptions are both on the same queue and the conduit subscriptions option is enabled, broker A combines the subscriptions into a single conduit subscription, cs, which does not include any selector details. When P starts sending messages to the queue, broker A forwards the messages alternately to broker B and broker C, without checking whether the messages satisfy the relevant selectors. If you are particularly unlucky, you might find that all of the messages for region emea end up on broker B and all of the messages for region us end up on broker C. In this case, none of the messages could be consumed.