On Fri, Jul 12, 2013 at 8:09 PM, William Henry <whe...@redhat.com> wrote:
> > > 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. > OK, that sounds like it would be part of the Transport's handling of a Target ( https://github.com/markmc/oslo.messaging/blob/master/oslo/messaging/target.py ). Doug > > 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
