On 18/01/2008, Arnaud Simon <[EMAIL PROTECTED]> wrote:
>
>
> > 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.
Perhaps I misunderstand what you are saying, providing multiple
addressing via JNDI will not cause any vendor lock in except in the
format and functionality that is specified in the BindingURL (Again
this should be an AMQP specified format, which would remove that
problem) There would be zero requirement for non pure JMS code in the
client library as they would simply do:
Destination specialDestination =
(Destination)jndiContext.lookup("SpecialAMQPDestination");
That is pure JMS + JNDI no AMQP lock-in.
Perhaps the thing we are talking around is the fact AMQP haven't yet
standardised the notion of Destination. If we can work out a sensible
solution then that could be proposed, rolled in to the forthcoming
JMS-over-AMQP documentation and vendor lock-in vanishes.
> Arnaud
>
>
>
>
--
Martin Ritchie
