qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud Simon <asi...@redhat.com>
Subject Re: BindingURL format and AMQDestination class
Date Fri, 18 Jan 2008 10:17:21 GMT

> 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


View raw message