Message filter syntax

[Clemens Vasters <clemensv@microsoft.com>]

One of the obvious holes we need to plug is defining a filter syntax in the AMQP TC, so that AMQP BINDMAP has something to map to. We’ve also discussed that and Keith is on the list to write that up, but I haven’t seen a proposal as of yet.

 

Since that is critical for Microsoft to solve and have an implementable draft of, I’d like to suggest the following approach to speed things up – Keith, if you have a proposal in flight that’s diverging from the following, yours obviously takes precedence:

 

First, we pick up the JMS 2.0 Sec. 3.8.1.1 message selector syntax as the baseline since that appears to be what everyone is implementing already. I don’t think anyone loves the idea of writing new parsers from the ground up.

 

The major difference for AMQP will then be around how message headers and message properties are qualified.

 

In JMS, message properties are unqualified identifiers, and headers have fixed names or prefixes; literally:

 

• Message header field references are restricted to JMSDeliveryMode, JMSPriority, JMSMessageID, JMSTimestamp, JMSCorrelationID, and JMSType. JMSMessageID, JMSCorrelationID, and JMSType values may be null and if so are treated as a NULL value.
• Any name beginning with 'JMSX' is a JMS defined property name.
• Any name beginning with 'JMS_' is a provider-specific property name.
• Any name that does not begin with 'JMS' is an application-specific property name

 

I see that Artemis in its native model has a similar approach but uses ‘AMQ’ instead of ‘JMS’ as a prefix.

 

I would like to propose the following model for property references in AMQP 1.0 filters

 

• Properties from the “application-properties” section remain unqualified. They can be optionally qualified with “prop.”
• Properties from the “properties” section are qualified with “amqp.”
• Properties from the “message-annotations” section are qualified with “msg.”
• Properties from the “delivery-annotations” section are qualified with “dlv.”
• Properties from the “header” section are qualified with “header.”
• Properties from the “footer” section are qualified with “footer.”
• Vendor specific environment properties (like AMQ’s message size property) are qualified with “vnd.”

 

 

The naming may seem a bit arbitrary; since the expressions surface up in the programming experiences, I’m trying to use naming that doesn’t necessarily align with the exact naming in the AMQP spec, but with the user perspective.

 

“Their” properties should be unqualified or use the “prop” term. The predefined set of commonly used AMQP properties (message-id, user-id,to, subject, …) should show up as such, hence “amqp”.

 

Example: Price > 10 AND color = “blue” AND amqp.subject = “order”

 

 

Having those filters is obviously a prereq to defining a management gesture for durable subscriptions and for conditional receives (i.e. filtered links).