Versions of AMQP prior to 1.0 prescribed a model of Exchanges and Queues, where Queues were bound to Exchanges with a binding key whose meaning depended upon the type of the Exchange. In order to allow a consistent mechanism for addressing legacy AMQP Exchanges over AMQP 1.0 the following filter types are defined. Use of an Exchange as an address for a Source thus can be seen as equivalent to constructing exclusive queues bound to an Exchange in legacy AMQP versions.
Containers which support the filters that are defined in this section should advertise the
capability
The legacy-amqp-direct-binding filter consists of a described string value. The filter matches a message if and only if the described string value exactly matches the subject field of the Properties section of the message being evaluated. If the message has no Properties section, or if the subject field of the Properties section is not set, then the legacy-amqp-direct-binding filter does not match.
The legacy-amqp-topic-binding filter consists of a described string value. The value value described by the type is interpreted as a pattern to match against the subject field of the Properties section of the message being evaluated.
Thus the filter value "*.stock.#" would match the subjects "usd.stock" and "eur.stock.db" but not "stock.nasdaq".
If the message has no Properties section, or if the subject field of the Properties section is not set, then the legacy-amqp-topic-binding filter matches only if the value of the filter is a single "#".
The legacy-amqp-headers-binding filter consists of a described map value. The map value described by the type is interpreted as a pattern to match against the application-properties section of the message being evaluated. The map has the same restriction as the application-properties section, namely that the keys of this are restricted to be of type string (which excludes the possibility of a null key) and the values are restricted to be of simple types only, that is, excluding map, list, and array types.
The key "x-match" in the described map has special meaning. This key MUST map to the symbolic value "any" or the symbolic value "all" within the described map. All other keys which begin "x-" MUST be ignored by the source when evaluating. If the value for "x-match" is "all" then all other valid key-value pairs in the map MUST match with an entry with the same key in the application-properties section. If the value for "x-match" is "any" then the filter will accept the message if at least one key-value pair matches the equivalent key value pair in the application-properties section.
A key-value pair in the filter's map matches a key-value pair in the application-properties section if the keys are identical (including the same type), or if the value in the filter map for the key is null.
The Java Message Service defines two types of filtering of messages: firstly the ability to exclude from a subscription messages sent by the same connection, secondly a more general filtering syntax known as "selectors" based on an SQL like syntax.
AMQP filter extensions through which these two types of filtering may be achieved are defined below. Their use, though motivated by support for JMS, is not restricted to JMS.
A message will be accepted by the simple-no-local-filter if and only if the message was originally sent to the container of the source on a separate connection from that which is currently receiving from the source.
Containers which support this filter should advertise the
capability
The Java Message Service "selector" defines an SQL like syntax for filtering messages. The selector filters based on the values of "headers" and "properties". The selector-filter uses the selector as defined by JMS but with the names of JMS headers translated into their AMQP equivalents. The defined JMS headers can be mapped to equivalent fields within the AMQP message sections:
When encoding the selector string on the wire, these JMS header names should be translated to amqp.field_name where field_name is the appropriate AMQP 1.0 field named in the table above, with the hyphen replaced by an underscore. For example, the selector: "JMSCorrelationID = 'abc' AND color = 'blue' AND weight > 2500" would be transferred over the wire as: "amqp.correlation_id = 'abc' AND color = 'blue' AND weight > 2500"
The "properties" of the JMS message are equivalent to the AMQP application-properties section. Thus a reference to a property Foo in a message selector would be evaluated as the value associated with the key "Foo" (if present) in the application-properties section.
The operands of the JMS selector are defined in terms of the types available within JMS, When evaluated against the application properties section, the values within that section MUST be evaluated according to the following type mapping.
Containers which support this filter should advertise the
capability
<type |
Type | Encoding | Code | Category | Description |
---|---|---|---|---|