Sent from my iPhone
On Jul 12, 2013, at 5:27 PM, Doug Hellmann <doug.hellm...@dreamhost.com> wrote: > > > > On Fri, Jul 12, 2013 at 5:40 PM, William Henry <whe...@redhat.com> wrote: >> 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. > > In this case I think we mean the Transport driver from within Oslo. So you > could not connect a ZMQ Transport on one end to an AMQP Transport on the > other. It will be an implementation detail of the AMQP Transport class to > decide whether it supports more than one version of AMQP, or if the different > versions are implemented as different Transports. > >> >> 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? > > The latter. Ack. Good. Fits very well into AMQP 1.0 then ;-) > >> >> 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). > > Too many of these terms are overloaded. :-) Yep. But topic pup/sub is certainly different to a queue. ;-) > > I'm not sure of the details of how "topic" and "address" are different in > AMQP 1.0. The word "address" implies to me that the message sender knows > where the message receiver is in some concrete sense. We don't want those > semantics in a lot of our use cases. If the "address" is abstract, then it > sounds like it works much as a topic does. Maybe you can expand on the > differences? Nope the address is essentially a namespace. The send knows not where it ends up. Hence in some applications it doesn't even know of its a topic or a queue an it could go to one or many depending. William > > Thanks, > Doug > > >> >> Please feel free to respond and critique my comments/suggestions. >> >> Best, >> William >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
