Destination Filtering

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 in order to control the flow of messages throughout the network.

Fuse Message Broker allows you to control the flow of messages in two ways:

Destination names are often segmented to denote how they are related. For example, an application may use the prefix PRICE.STOCK to denote all of the destinations that handle stock quotes. The application may then further segment the destination names such that all stock quotes from the New York Stock Exchange were prefixed with PRICE.STOCK.NYSE and stock quotes from NASDAQ used the prefix PRICE.STOCK.NASDAQ. Using wildcards would be a natural way to create filters for specific types of destinations.

Table 1 describes the characters can be used to define wildcard matches for destination names.

Table 2 shows some examples of destination wildcards and the names they would match.

The default behavior of a network connector is to allow messages for all destinations to pass. You can, however, configure a network connector to only allow messages for specific destinations to pass. If you use segmented destination names, you can use wildcards to filter groups of destinations.

You do this by adding a dynamicallyIncludedDestinations child to the network connector's networkConnector element. The included destinations are specified using queue and topic children. Example 4 shows configuration for a network connector that only passes messages destined for queues with names that match TRADE.STOCK.> and topics with names that match PRICE.STOCK.>.

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

Another way of partitioning a network and create filters is to explicitly specify a list destinations whose messages are not allowed to pass through a network connector. If you use segmented destination names, you can use wildcards to filter groups of destinations.

You do this by adding a excludedDestinations child to the network connector's networkConnector element. The excluded destinations are specified using queue and topic children. Example 5 shows configuration for a network connector that blocks messages destined for queues with names that match TRADE.STOCK.NYSE.* and topics with names that match PRICE.STOCK.NYSE.*.

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

You can combine inclusive and exclusive filtering to create complex network partitions. Example 6 shows a network connector that is configured to transmit 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>