[jira] [Created] (QPID-3949) [Java AMQP 1.0] Update JMS Filter implementations to use new proposed descriptors
Locked
[jira] [Created] (QPID-3949) [Java AMQP 1.0] Update JMS Filter implementations to use new proposed descriptors
 
|
[Java AMQP 1.0] Update JMS Filter implementations to use new proposed descriptors
--------------------------------------------------------------------------------- Key: QPID-3949 URL: https://issues.apache.org/jira/browse/QPID-3949 Project: Qpid Issue Type: Bug Components: Java Broker, Java Client Affects Versions: 0.17 Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.17 Update the Java AMQP 1.0 implementation to use the filter descriptors defined here: http://people.apache.org/~rgodfrey/amqp-1.0/apache-filters.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
AMQP 1.0 filter proposals
|
On 04/16/2012 09:42 AM, Rob Godfrey (Created) (JIRA) wrote:
> [Java AMQP 1.0] Update JMS Filter implementations to use new proposed descriptors > --------------------------------------------------------------------------------- > > Key: QPID-3949 > URL: https://issues.apache.org/jira/browse/QPID-3949 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Client > Affects Versions: 0.17 > Reporter: Rob Godfrey > Assignee: Rob Godfrey > Fix For: 0.17 > > > Update the Java AMQP 1.0 implementation to use the filter descriptors defined here: > > http://people.apache.org/~rgodfrey/amqp-1.0/apache-filters.xml Couple of comments on this proposal: (1) It seems like translating from JMS property names to something more generally applicable in AMQP in the JMS client would be from some perspectives at least most 'natural'. That way the knowledge of JMS names remains in the component directly concerned with implementing that specification. It could be as simple as a string replacement of JMS name by field name of corresponding AMQP 1.0 field name. In this case the name of the filter could also be made a little more generic. Likewise as specified there is no need to have 'jms' in the name of the no-local filter as it is useful and supported for other use cases as well. While I can see the desire to have a single capability for the two filters driven by JMS, there is also a view that tying them together is not necessary. You could support no-local but not the full selector filter. Perhaps we could have distinct capabilities for the filters and then have a more all-encompassing capability for a more complete JMS mapping? (2) I am leaning to the view that allowing lists in the 'legacy AMQP exchange binding' filters would be a simpler and more direct expression of the legacy support than the generic and/or/not combinators. Without modifying the actual capabilities of the different exchange types, only the 'or' would be valid and even in that case the actual list would need to consist only of the filters valid for the exchange type. For the topic and direct exchanges a list of keys gives - in my view - a more obvious indication of the actual capability. Given the JMS style selector filter, what would be the use case for the more generic combinators beyond simple 'or' lists for legacy exchanges? [I spotted a minor typo in the first paragraph of section 3: "a primitive notion of combing filters", should be 'combining']. None of these are major issues of course, but it seems worth a small amount of debate before nailing them down and getting them registered. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: AMQP 1.0 filter proposals
|
On 16 April 2012 12:03, Gordon Sim <[hidden email]> wrote:
> On 04/16/2012 09:42 AM, Rob Godfrey (Created) (JIRA) wrote: > >> [Java AMQP 1.0] Update JMS Filter implementations to use new proposed >> descriptors >> ------------------------------**------------------------------** >> --------------------- >> >> Key: QPID-3949 >> URL: https://issues.apache.org/**jira/browse/QPID-3949<https://issues.apache.org/jira/browse/QPID-3949> >> Project: Qpid >> Issue Type: Bug >> Components: Java Broker, Java Client >> Affects Versions: 0.17 >> Reporter: Rob Godfrey >> Assignee: Rob Godfrey >> Fix For: 0.17 >> >> >> Update the Java AMQP 1.0 implementation to use the filter descriptors >> defined here: >> >> http://people.apache.org/~**rgodfrey/amqp-1.0/apache-**filters.xml<http://people.apache.org/%7Ergodfrey/amqp-1.0/apache-filters.xml> >> > > Couple of comments on this proposal: > > (1) It seems like translating from JMS property names to something more > generally applicable in AMQP in the JMS client would be from some > perspectives at least most 'natural'. That way the knowledge of JMS names > remains in the component directly concerned with implementing that > specification. It could be as simple as a string replacement of JMS name by > field name of corresponding AMQP 1.0 field name. > > In this case the name of the filter could also be made a little more > generic. Likewise as specified there is no need to have 'jms' in the name > of the no-local filter as it is useful and supported for other use cases as > well. > > existing JMS implementation they do not wish to have to translate the filters from JMS to AMQP and then back again... For pure AMQP 1.0 implementations such as Qpid this obviously seems less natural. I think there is a good case to be made that we should define an SQL like query syntax which allows evaluation of all properties and annotations of an AMQP 1-0 message, however I think that is a separate task. > While I can see the desire to have a single capability for the two filters > driven by JMS, there is also a view that tying them together is not > necessary. You could support no-local but not the full selector filter. > Perhaps we could have distinct capabilities for the filters and then have a > more all-encompassing capability for a more complete JMS mapping? > > For the final JMS mapping I think that the most likely way forward is to specify that a server may offer one of a number of different filter types that have the expressive power as JMS filters, and that clients must be capable of using which filter syntax (from the approved list) the server supports. Discussions amongst the AMQP implementers have never been able to agree a single syntax that all can agree on based upon the different histories of their products. Putting the burden on the client is somewhat easier as we can produce an Apache licensed open source conversion function that given a JMS selector string will compile the necessary AMQP 1.0 filter expression. Since JMS clients must (by definition) be written in Java at some level this should be enough for anyone writing a JMS client. > (2) I am leaning to the view that allowing lists in the 'legacy AMQP > exchange binding' filters would be a simpler and more direct expression of > the legacy support than the generic and/or/not combinators. > > The and/or/not expressions will be required anyway and as such I am keen to add them now. The idea is generally that you should be able to combine different sorts of filters which may be very specific and not expressible easily in terms of property values (like no-local). > Without modifying the actual capabilities of the different exchange types, > only the 'or' would be valid and even in that case the actual list would > need to consist only of the filters valid for the exchange type. For the > topic and direct exchanges a list of keys gives - in my view - a more > obvious indication of the actual capability. > > As above I think the logical operations are a necessary set of filters, I'm reluctant to add an alternative way of achieving the same ends for a single use case. Moreover for the Java Broker you can currently qualify the binding-key filter with a secondary (JMS) selector in AMQP 0-9 and 0-10, so that your actual binding is ( binding-key1 AND selector1) OR (binding-key2 AND selector2) OR ... The proposal to just use lists of binding keys would not allow for this functionality. > Given the JMS style selector filter, what would be the use case for the > more generic combinators beyond simple 'or' lists for legacy exchanges? > Other implementers are very keen that selectors be specified in terms of an AST (so a client side selector might be encoded as something like and(equals(app-property("my-prop"), "my-value"), less-than(message-annotation("foo-size"), 42)) as opposed to a string "application-properties.my-prop = 'my-value' and message.annotation.foo-size < 42" > > [I spotted a minor typo in the first paragraph of section 3: "a primitive > notion of combing filters", should be 'combining']. > > Thanks - will fix that now. > None of these are major issues of course, but it seems worth a small > amount of debate before nailing them down and getting them registered. > > Agreed - that is why these are proposals only :-) -- Rob > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: [hidden email].**org<[hidden email]> > For additional commands, e-mail: [hidden email] > > |
Re: AMQP 1.0 filter proposals
|
|
On 04/16/2012 11:24 AM, Rob Godfrey wrote:
> On 16 April 2012 12:03, Gordon Sim<[hidden email]> wrote: > >> On 04/16/2012 09:42 AM, Rob Godfrey (Created) (JIRA) wrote: >> >>> [Java AMQP 1.0] Update JMS Filter implementations to use new proposed >>> descriptors >>> ------------------------------**------------------------------** >>> --------------------- >>> >>> Key: QPID-3949 >>> URL: https://issues.apache.org/**jira/browse/QPID-3949<https://issues.apache.org/jira/browse/QPID-3949> >>> Project: Qpid >>> Issue Type: Bug >>> Components: Java Broker, Java Client >>> Affects Versions: 0.17 >>> Reporter: Rob Godfrey >>> Assignee: Rob Godfrey >>> Fix For: 0.17 >>> >>> >>> Update the Java AMQP 1.0 implementation to use the filter descriptors >>> defined here: >>> >>> http://people.apache.org/~**rgodfrey/amqp-1.0/apache-**filters.xml<http://people.apache.org/%7Ergodfrey/amqp-1.0/apache-filters.xml> >>> >> >> Couple of comments on this proposal: >> >> (1) It seems like translating from JMS property names to something more >> generally applicable in AMQP in the JMS client would be from some >> perspectives at least most 'natural'. That way the knowledge of JMS names >> remains in the component directly concerned with implementing that >> specification. It could be as simple as a string replacement of JMS name by >> field name of corresponding AMQP 1.0 field name. >> >> In this case the name of the filter could also be made a little more >> generic. Likewise as specified there is no need to have 'jms' in the name >> of the no-local filter as it is useful and supported for other use cases as >> well. >> >> > The main driver here is that for people implementing AMQP 1.0 over an > existing JMS implementation they do not wish to have to translate the > filters from JMS to AMQP and then back again... The message properties themselves are 'translated' into the AMQP 1.0 equivalents and then back again when transferring the message. Translating the filter string for that same mapping seems reasonable to me. It doesn't seem particularly arduous either (unless I'm missing something); its just replacing one name with another. > For pure AMQP 1.0 > implementations such as Qpid this obviously seems less natural. I think > there is a good case to be made that we should define an SQL like query > syntax which allows evaluation of all properties and annotations of an AMQP > 1-0 message, however I think that is a separate task. I'd like a selector that makes sense to use from other clients. Ideally I'd like the underlying filter to be the same for such cases whether sent by a JMS client or any other. Forcing all components to adopt JMS naming seems (even) less desirable than having the JMS components translate to a more AMQP friendly naming scheme. >> While I can see the desire to have a single capability for the two filters >> driven by JMS, there is also a view that tying them together is not >> necessary. You could support no-local but not the full selector filter. >> Perhaps we could have distinct capabilities for the filters and then have a >> more all-encompassing capability for a more complete JMS mapping? >> >> > For the final JMS mapping I think that the most likely way forward is to > specify that a server may offer one of a number of different filter types > that have the expressive power as JMS filters, and that clients must be > capable of using which filter syntax (from the approved list) the server > supports. Discussions amongst the AMQP implementers have never been able > to agree a single syntax that all can agree on based upon the different > histories of their products. Putting the burden on the client is somewhat > easier as we can produce an Apache licensed open source conversion function > that given a JMS selector string will compile the necessary AMQP 1.0 filter > expression. Since JMS clients must (by definition) be written in Java at > some level this should be enough for anyone writing a JMS client. That certainly seems a useful, pragmatic approach for a JMS client *implementation* such as Qpid. It seems a little weak as a standard JMS mapping however, though clearly that point is for another list. (In passing, such a function would make translating to AMQP names in place of JMS names in the selector even less arduous). >> (2) I am leaning to the view that allowing lists in the 'legacy AMQP >> exchange binding' filters would be a simpler and more direct expression of >> the legacy support than the generic and/or/not combinators. >> >> > The and/or/not expressions will be required anyway and as such I am keen to > add them now. The idea is generally that you should be able to combine > different sorts of filters which may be very specific and not expressible > easily in terms of property values (like no-local). Point taken in general, but given you can define multiple filters for a given link (i.e. combine in the 'AND' sense) are there more concrete use-cases at present? I'm keen for registered extensions not to get too far ahead of implementations. Adding is generally easier than removing or modifying. A limited set of filters with wide support is better than a wider range of filters each with limited support. >> Without modifying the actual capabilities of the different exchange types, >> only the 'or' would be valid and even in that case the actual list would >> need to consist only of the filters valid for the exchange type. For the >> topic and direct exchanges a list of keys gives - in my view - a more >> obvious indication of the actual capability. >> >> > As above I think the logical operations are a necessary set of filters, I'm > reluctant to add an alternative way of achieving the same ends for a single > use case. I see it quite differently. The goal appears to me to be tactical and specific: defining filters that correspond to the routing behaviour defined for the standard exchange types in previous incarnations of the specification so that implementations (such as Qpid) based on those can support pub-sub patterns by exposing exchanges as nodes supporting the appropriate filter type. Within this scope, the question is whether to support multiple bindings from the same exchange for a given subscriber, and if so how best to do that. One approach, which I am suggesting, covers this through a minimal change to the legacy filter definitions. Another approach, as proposed by you, is to expand the scope to a more general filtering solution, adding general purpose boolean operators. I feel this goes further than is needed for a tactical solution while not going far enough for a strategic solution. I feel the requirements for the general solution are still too vague. I am not suggesting adding an alternative way; I am suggesting keeping a more limited scope for the tactical solution to the immediate goals. The code for existing exchange implementations is going to be distinct from any more general purpose implementation in the future anyway. > Moreover for the Java Broker you can currently qualify the > binding-key filter with a secondary (JMS) selector in AMQP 0-9 and 0-10, so > that your actual binding is ( binding-key1 AND selector1) OR (binding-key2 > AND selector2) OR ... The proposal to just use lists of binding keys would > not allow for this functionality. Expressing filtering capabilities of a node is more complex in the proposed approach; you need to define not simply what filters are supported but the valid ways in which they can be assembled. If the goal is exposing the standard exchange types in 1.0 that seems less desirable to me. It seems more likely to lead to a situation where implementation specific, under-specified combinations of the primitives emerge in an ad-hoc fashion. Of course we don't want to rule out use cases for no reason, but this case, as a Qpid specific extension, is at least different in scope. I'd also suspect it is of much narrower applicability. You could still have binding-key AND selector - through two separate filters on the source - which would cover what I understand to be the motivating use case for that feature i.e. a selector on a topic consumer in JMS. The only cases not covered are where you want to combine multiple such pairs. If there is a real need for that, I'd rather see it defined as a special legacy filter of its own. >> Given the JMS style selector filter, what would be the use case for the >> more generic combinators beyond simple 'or' lists for legacy exchanges? >> > > Other implementers are very keen that selectors be specified in terms of an > AST (so a client side selector might be encoded as something like > and(equals(app-property("my-prop"), "my-value"), > less-than(message-annotation("foo-size"), 42)) as opposed to a string > "application-properties.my-prop = 'my-value' and > message.annotation.foo-size< 42" Is there a reason for that? Having the parsing done on the broker seems somewhat simpler to me on the face of it. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
[jira] [Resolved] (QPID-3949) [Java AMQP 1.0] Update JMS Filter implementations to use new proposed descriptors
|
|
In reply to this post by JIRA jira@apache.org
[ https://issues.apache.org/jira/browse/QPID-3949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved QPID-3949. ------------------------------- Resolution: Fixed > [Java AMQP 1.0] Update JMS Filter implementations to use new proposed descriptors > --------------------------------------------------------------------------------- > > Key: QPID-3949 > URL: https://issues.apache.org/jira/browse/QPID-3949 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Client > Affects Versions: 0.17 > Reporter: Rob Godfrey > Assignee: Rob Godfrey > Fix For: 0.17 > > > Update the Java AMQP 1.0 implementation to use the filter descriptors defined here: > http://people.apache.org/~rgodfrey/amqp-1.0/apache-filters.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: AMQP 1.0 filter proposals
|
|
In reply to this post by Gordon Sim
I've put up a minor revision to the proposal on review board for anyone
interested: https://reviews.apache.org/r/4913/ This is essentially Rob's first proposal with a modification of the JMS filters to make them more easily applicable to other clients. It also drops the requirement for multiple bindings to legacy exchanges at this point - and hence the or (and other boolean) combinators - as we lack consensus on the solution to that at present and don't want to derail meeting the primary requirements. The intention is for both brokers and all clients to support these filters and indeed to have the filters registered with OASIS (under the apache.org namespace) for anyone else who is interested in supporting the same functionality. Comments welcome! --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Re: AMQP 1.0 filter proposals
|
|
On 04/27/2012 10:15 AM, Gordon Sim wrote:
> I've put up a minor revision to the proposal on review board for anyone > interested: > > https://reviews.apache.org/r/4913/ > > This is essentially Rob's first proposal with a modification of the JMS > filters to make them more easily applicable to other clients. It also > drops the requirement for multiple bindings to legacy exchanges at this > point - and hence the or (and other boolean) combinators - as we lack > consensus on the solution to that at present and don't want to derail > meeting the primary requirements. > > The intention is for both brokers and all clients to support these > filters and indeed to have the filters registered with OASIS (under the > apache.org namespace) for anyone else who is interested in supporting > the same functionality. > > Comments welcome! I've committed the patch above and would like to proceed to request OASIS to register these filters. Any last minute objections? --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
«
Return to Apache Qpid developers
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |