So, there’s two things here...
One is that a given node may support only a subset of filter types that the container understands - this you can only discover at the point you attach to the
node with the link / look at the source capabilities.
The second issue is the total set of filter types a container understands. This is useful to know in the case where there are a number of filter types that
provide near equivalent functionality, and where the client library/application can make a choice about how to express the filter. To take an example we’ve discussed before, let’s talk about JMS selectors.
Andreas has proposed a filter type which is essentially a straight encoding of the JMS selector as defined in the JMS spec. This is obviously very convenient
for anyone providing a container which already has JMS functionality built in; however it isn’t a natural fit for someone building an AMQP container from scratch (the field names do not line up completely, there are properties that cannot be queried through
JMS, types with no equivalence, etc). Previously we have also seen defined a more universal encoding for filters where the parsing would be mostly on the client side and the filter would be encoded as something that looked much more like an abstract syntax
tree. Such a scheme would provide a strict superset of the filtering capabilities of the JMS syntax, but would not necessarily be something that all vendors would be looking to implement (as has previously been discussed/argued at length).
As a builder of a JMS client library I can detect at the point of connection whether a container that I am connecting to supports only JMS Strings, only the
AST encoded filters, or both. If there are open source implementations of the encoding of JMS selectors into these two different filter types, then it’s really not a huge burden on the client library provider to allow for either option. However it is burdensome
(and depending on your level of logging - may cause spurious errors) if when you come to creating a consumer you have to try all filter types on every node to find out which filter types a given container supports. By stating at the connection level which
filter types are supported you can quickly determine which types it will be worth trying, and in general allows for fail-fast where the server you are trying to connect to simply does not have the capabilities you need.
-- Rob
From: amqp@lists.oasis-open.org [mailto:amqp@lists.oasis-open.org]
On Behalf Of Raphael Cohn
Sent: Wednesday, April 11, 2012 6:33 PM
To: Andreas Mueller
Cc: Gordon Sim; Godfrey, Robert X; amqp@lists.oasis-open.org; amqp-ms@lists.oasis-open.org
Subject: [amqp] Re: [amqp-ms] Re: [amqp] Request to add filters to public registry
So if I expose one node to MQTT and AMQP, say, I'd like to expose it with a restricted filter-set (the links for it can only support filters that match MQTT's primitive globbing). However, the same implementation might expose the same or
other nodes over native AMQP, or other protocols, with a wider range of filters possible. And given that nothing prevents an implementation being nothing more than a scale-out proxy to behind the scenes 'things', there's nothing to say one impl == one running
broker which has all the features needed within it. Indeed, such facades are quite likely with intelligent global routing...
So connection level properties aren't so useful here. And they certainly don't allow partial implementation of filter kinds, particularly by clients.
Raphael Cohn
Chief Architect, StormMQ
Secretary, OASIS AMQP Standard
raphael.cohn@StormMQ.com
StormMQ Limited
UK Office:
Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom
Telephone: +44 845 3712 567
Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 07175657
StormMQ.com
On 11 April 2012 17:55, Andreas Mueller <am@iit.de> wrote:
I don't see that on the link level. A link requires a session requires a connection which is bound to an AMQP impl that supports a specific filter set.
Why are these connection capabilities and not link capabilities?
I can easy see having a solution that, for example, bridges STOMP or MQTT; consequently, the supported filter kinds on one link would differ, and clients could easily connect to such a broker without having to support the full gamut.
Raphael Cohn
Chief Architect, StormMQ
Secretary, OASIS AMQP Standard
raphael.cohn@StormMQ.com
StormMQ Limited
UK Office:
Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom
Telephone: +44 845 3712 567
Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 07175657
StormMQ.com
On 11 April 2012 16:19, Gordon Sim <gsim@redhat.com> wrote:
On 04/11/2012 04:00 PM, Godfrey, Robert X wrote:
I would like to propose add the following three filter types to the registries, along with an associated connection capability
<type class="composite" name="amqp-direct-filter" source="string" provides="filter">
<descriptor name="apache.org:amqp-direct-filter:string" code="0x0000468C:0x00000000"/>
</type>
<type class="restricted" name="amqp-topic-filter" source="string" provides="filter">
<descriptor name="apache.org:amqp-topic-filter:string" code="0x0000468C:0x00000001"/>
</type>
<type class="restricted" name="amqp-headers-filter" source="map" provides="filter">
<descriptor name="apache.org:amqp-headers-filter:map" code="0x0000468C:0x00000002"/>
</type>
The amqp-direct-filter string is used as an exact character match on the "subject" field of the properties section of a message.
The amqp-topic-filter string is used as a pattern match against the "subject" field using the syntax defined in AMQP v0-8, v0-9, v0-9-1 and v0-10
The amqp-headers-filter contains a map which matches against the application-properties map in the manner defined for arguments in binding to a headers exchange in AMQP v0-8, v0-9, v0-9-1 and v0-10
I would propose a connection capability of
APACHE.ORG:AMQP_EXCHANGE_BINDING_FILTERS
to denote the support of these filter types.
Obviously the intent here is to support legacy v0-x AMQP binding models behind an AMQP 1.0 front end where the consumer creates a receiving link from a node which represents an "exchange" in a legacy AMQP v0-x broker.
I agree with the intent. However I'm not so sure its a good idea (a) to use 'amqp' in 'vendor' extensions and (b) to use 'amqp' unqualified for legacy support for pre 1.0 concepts.
What about simply: subject-filter-exact, subject-filter-hierarchical and properties-match-filter? They would potentially be applicable even in implementations that were not based on the old pre-1.0 concepts.
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
|