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 09:06:46 GMT

On Thu, 2008-01-17 at 09:05 +0000, Martin Ritchie wrote:
> Rajith ,
> 
> The BindingURL was writing (as it is java) from the JMS point of view.
> Hence destination is where you are publishing to in JMS. Now the
> reason the wiki does not match the code is because of a problem I
> realised after implementing the original spec. The URL cannot have a
> '#' in the middle as this will prevent the URI class from correctly
> parsing it. Hence the need to have the routing_key as an option.
> 
> I would also be very cautious about changing this format as it is used
> in a lot more places that the Java. I would suggest that if you do
> wish to change the format then changing the code so that it matches
> the wiki documentation would be the way to go. If you do that then a
> change will be needed to update the C++ and .NET as they both use this
> format to encode the replyTo field.

I think that AMQP should define the replyTo URL. If this is not already
the case we should then raise this issue with the AMQP list. 

> Really what should happen is that the BindingURL be used solely on the
> broker for parsing the bindings defined in the configuration file and
> either a simplified version or a new format be decided for replyTo
> encoding. We used to use Q|T+RoutingKey but that limited us in the
> java to only using the built in exchanges. Perhaps a subclass of
> BindingURL could be used to only present the values required to
> perform a reply.

To be honest we had troubles with the binding URL when trying to get the
JMS code inter-operate with c++ and python samples. For doing that we
needed to use the faneout exchange, to use a different binding key than
the queue name and to bind a queue with more than one binding key. 

This reminds me some discussion we recently had on the AMQP list about
how to decide whether a JMS topic exists and a way of solving that issue
would be to define AMQP alias for an exchange, routing-key(s) pair. It
could be a good idea to start thinking about this wider notion of AMQ
destination. However the issue is that AMQP destinations are not
matching the notion of JMS one. If we consider the current binding URL
scheme and what people want to achieve, a destination would be defined
by: an exchange name, an optional queue name, some optional binding keys
and options. This has however different semantics whether we use the
destination for consuming or for producing. What does that means
producing a message to a destination with several binding keys? That's
hard to say and I would say that it makes no sense. This is why I would
suggest that we do not allow using more than one binding key unless we
introduce a kind of "read only" notion. A "read only" destination would
only be used for consumption. 

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? 

Arnaud






Mime
View raw message