OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: [amqp] Message filter syntax


Comments Inline

 

 

Von: Rob Godfrey <rgodfrey@redhat.com>
Gesendet: Friday, May 18, 2018 2:22 PM
An: Clemens Vasters <clemensv@microsoft.com>
Cc: oasis-amqp-list <amqp@lists.oasis-open.org>; amqp-bindmap@lists.oasis-open.org
Betreff: Re: [amqp] Message filter syntax

 

 

 

On 18 May 2018 at 12:55, Clemens Vasters <clemensv@microsoft.com> wrote:

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.”

I'm fine with all the above, but note that footer, message-annotations and delivery-annotations have no restriction on the types that may be used for the values used in the map (e.g. the value may be an array, list, map, or even a described type), do we exclude the ability to filter on values of complex type, or do we want to define syntax for this?.  There is also the case that theoretically the key in any of these sections can be a ulong, though that behaviour is reserved for use by AMQP definitions and we so far have not used that.

 

A further consideration is that AMQP does not make the same restrictions on the form of strings/symbols used in the keys of these (or the application properties) map.  In particular spaces and operator characters may be used, e.g. a valid key might be "foo > 100".  As such I think we need to define a way of quoting identifiers (as SQL does).

 

[Clemens Vasters] Yes, we will need to define a syntax to navigate into complex types, and we’ll have to pick up the quoted identifier rules from newer versions of SQL. There’s some 21st century renovation needed on the JMS baseline 😉

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”

We will also need to define type conversion here - we could appeal to the separate document we are writing for JSON types, though this may not align with JMS behaviour.

 

[Clemens Vasters] We certainly need some type inference rules for the text expressions in filters; date-time expressions in particular.  

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

 

 

--

_____________________________________________________________________________

Red Hat GmbH, 
www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]