Hi all, 

I've been reading through the Messaging Wiki and have some comments. Not 
criticisms, just comments and questions. 
I have found this to be a very useful document. Thanks. 

1. "There are multiple backend transport drivers which implement the API 
semantics using different messaging systems - e.g. RabbitMQ, Qpid, ZeroMQ. 
While both sides of a connection must use the same transport driver configured 
in the same way, the API avoids exposing details of transports so that code 
written using one transport should work with any other transport." 

The good news for AMQP 1.0 users is that technically "boths sides of the 
connection" do not have to use same transport driver. In pre-AMQP 1.0 days this 
was the case. But today interoperability between AMQP 1.0 implementations has 
been demonstrated. 

2. I notice under the RPC concepts section that you mention Exchanges as a 
container in which topics are scoped. Is this exchange a pre AMQP 1.0 artifact 
or just a general term for oslo.messaging that is loosely based on the pre-AMQP 
1.0 artifact called an Exchange? i.e. are you assuming that messaging 
implementations have something called an exchange? Or do you mean that 
messaging implementations can scope a topic and in oslo we call that scoping an 
exchange? 

3. Some messaging nomenclature: The way the wiki describes RPC " Invoke Method 
on One of Multiple Servers " is more like a queue than a topic. In messaging a 
queue is something that multiple consumers can attach to and one of them gets 
and services a message/request. A topic is where 1+ consumers are "connected" 
and each receives a the message and each can service it as it sees fit. In 
pre-AMQP 1.0 terms what this seems to describe is a direct exchange. And a 
direct excahnge can have multiple consumers listening to a queue on that 
exchange. (Remember that fanout is just a generalization of topic in that all 
consumers get all fanout messages - there are no sub-topics etc.) 

In AMQP 1.0 the addressing doesn't care or know about exchanges but it can 
support this queue type behavior on an address or topic type behavior on an 
address. 

I know this isn't about AMQP specifically but therefore this is even more 
important. Topics are pub/sub with multiple consumer/services responding to a 
single message. Queues are next consumer up gets the next message. 

(BTW I've seen this kind of confusion also in early versions of MCollective in 
Puppet.) 

It might be better to change some of the references to "topic" to "address". 
This would solve the problem. i.e. a use case where one of many servers 
listening on an address services a message/request. And later all of servers 
listening on an address service a message/request. Addressing also solves the 
one-to-one as the address is specific to the server (and the others don't have 
to receive and reject the message). 

Please feel free to respond and critique my comments/suggestions. 

Best, 
William 


_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to