> I would have said that a destination with several binding keys is just > a short hand notation for requesting multiple deliveries of the > message. Compare to SMTP (as AMQP is fond to do) multiple routingkeys > on a publish is simply many addresses in the To: field.
That's the only acceptable solution even if I don't like it very much as it is equivalent to creating several producers whereas for a consumer this is not strictly equivalent to creating several consumers. > > This being said, we are trying to define those binding URL schemes for > > writing pure JMS code that benefits from advanced AMQP features. The > > question may therefore be whether we wish to extend the JMS API with > > some officially supported new AMQPish features or if we want to ban that > > and assume that programmers will either use the JMS or the AMQP API? We > > already have extended the JMS API (see org.apache.qpid.jms) so why would > > we not do that for adding binding keys to a consumer? > > There should never be a question of using interfaces A or interfaces B > that will never work. In Java JMS _IS_ the interfaces used, the only > option is to extend it but that should only be for the 1% use cases. > Vendor lockin is something AMQP is working to avoid. So in the Java > space we should attempt to be pure JMS. The AMQP features can be > worked in via config such as JNDI or broker side queue configurations. I fully agree with that. However if you use JNDI to define a multiple addresses queue instead of using the standard JMS way of crating several producers you'll end up with a code that is lock with a specific AMQP JMS implementation. Whenever we allow binding destinations that have non standard JMS semantics we introduce vendor lockin. This is why I am wondering whether this should be explicit or hidden within a config file. Arnaud
