On 02/28/2012 04:30 AM, Rajith Attapattu wrote:
As per the discussion on QPID-792, I'm moving the discussion onto the
dev list under.
I have attempted to summarise the current behaviour and some of the
comments expressed by Rob and Robbie.
Currently the clients (C++, python and JMS) resolves an address (with
the 0-10 protocol) as follows.
1. If the name resolves to a queue, we treat it as a Queue
2. If the name resolves to an exchange, we treat is a Topic
3. If it doesn't resolve to either, we treat it as a Queue.
I think you have to keep separate the messaging API (as implemented by
e.g. c++ and python), from the JMS API. Even if we want to keep them as
consistent as possible, the APIs have some important differences (e.g.
address string v. Destination).
In the messaging API, the purpose of 'resolving' the name is to infer
how to form the AMQP 0-10 commands to send and receiver from it[1].
If you create a receiver for a given node, the underlying steps in AMQP
0-10 are determined by what (if anything) the name refers to. If it
refers to an exchange, then the creation of a receiver implies the
creation of a 'subscription queue' which is bound to that exchange. If
it refers to a queue, we simply subscribe to that queue. In both cases
the steps involved can be customised (e.g. to request a non-acquiring
subscription in the latter case).
Likewise for creating a sender, implementations of the messaging API
determine what the node referred to actually is. If it is a queue then
messages from that sender will be sent to the default exchange with the
queue name used as the routing key; if it is an exchange then messages
will be sent to that named exchange (with any subject used as the
routing key).
You can sidestep the automatic resolution by specifying the node type
explicitly in the address. If that doesn't match reality you will get an
error.
In JMS on the other, the Topic and Queue subclasses of Destination are
explicit entities in the API. The type of the object is (or can be)
similar to the explicit node type in an address of the messaging API: a
constraint on what the node referred to is expected to be.
[...]
Rob, further states that we could utilize the queue and topic
qualifiers that is currently present in our JNDI mechanism.
"I don't think the queue/topic distinction even needs to go into the
address - it should only needs to be defined some way in the JNDI
source
e.g. in a properties file then things that begin
queue.<NAME>=<address string>
would be queues, and
topic.<NAME>=<address string>
would be topics"
This sounds perfectly reasonable to me.
--Gordon.
[1] The programming guide has a section that is probably muddier than it
needs to be on some of this, at least for some sections of the audience.
[2] In passing, the file based JNDI properties is in my view not always
ideal. Having tooling to automatically populate a JNDI tree based on
what queues, exchanges etc actually exist on a broker would I think be
interesting providing this process could be customised/manually overridden.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
