此内容没有您所选择的语言版本。

Chapter 4. Destination Filtering


Abstract

One reason to create a network of brokers is to partition message destinations to sub-domains of the network. Red Hat JBoss A-MQ can apply filters to destination names to prevent messages for a destination from passing through a network connector.

Overview

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. Red Hat JBoss A-MQ lets you define filters on network connectors in order to control the flow of messages throughout the network.
JBoss A-MQ allows you to control the flow of messages in two ways:
  • specifying which destinations' messages can pass through a connector
  • excluding messages for specific destinations from passing through a connector

Destination wildcards

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 4.1, “Destination Name Wildcards” describes the characters can be used to define wildcard matches for destination names.
Expand
Table 4.1. Destination Name Wildcards
WildcardDescription
.Separates segments in a path name.
*Matches any single segment in a path name.
>Matches any number of segments in a path name.
Table 4.2, “Example Destination Wildcards” shows some examples of destination wildcards and the names they would match.
Expand
Table 4.2. Example Destination Wildcards
Destination wildcardWhat it matches
PRICE.>Any price for any product on any exchange.
PRICE.STOCK.>Any price for a stock on any exchange.
PRICE.STOCK.NASDAQ.*Any stock price on NASDAQ.
PRICE.STOCK.*.IBMAny IBM stock price on any exchange.

Filtering destinations by inclusion

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.1, “Network Connector Using Inclusive Filtering” 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.>.

Example 4.1. Network Connector Using Inclusive Filtering

<networkConnectors>
    <networkConnector name="linkToBrokerB"
       uri="static:(tcp://localhost:61002)"
       networkTTL="3">
        <dynamicallyIncludedDestinations>
            <queue physicalName="TRADE.STOCK.>"/>
            <topic physicalName="PRICE.STOCK.>"/>
        </dynamicallyIncludedDestinations>
    </networkConnector>
</networkConnectors>
Copy to Clipboard Toggle word wrap
Important
Once you add the dynamicallyIncludedDestinations to a network connector's configuration, the network connector will only pass messages for the specified destinations.

Filtering destinations by exclusion

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 4.2, “Network Connector Using Exclusive Filtering” 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.*.

Example 4.2. Network Connector Using Exclusive Filtering

<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>
Copy to Clipboard Toggle word wrap

Combining inclusive and exclusive filters

You can combine inclusive and exclusive filtering to create complex network partitions. Example 4.3, “Combining Exclusive and Inclusive Filters” 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.

Example 4.3. Combining Exclusive and Inclusive Filters

<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>
Copy to Clipboard Toggle word wrap
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat