Dave Smith <[EMAIL PROTECTED]> writes: > I've looked at JMS and threw it out because of the Java > dependencies. My software is mostly Python and C++. I also looked at > (and used) CORBA, but it's too complex and the learning curve is > killer. What I really want is D-Bus, but currently D-Bus doesn't > support remote messaging[1] since it relies on Unix Domain Sockets.
So, I did a little more research on AMQP, and I'm not sure why you seemed to reject it out of hand over XMPP, which is not even designed for the sort of thing you're trying to do. What you seemed to be describing is called Message Oriented Middleware in 'enterprise' circles, and JMS is one example of it, though its fatal flaw is lack of interoperability. Which is precisely why JP Morgan created AMQP, which is an open protocol with several independant implementations (Apache QPid, LShift's RabbitMQ, and OpenAMQ). The standard hasn't been finalized yet, but it's pretty close. Here's some relevant description info from AMQP's site (https://jira.amqp.org/confluence/display/AMQP/About+AMQP): The AMQP Model The AMQP model explicitly defines a server's semantics because interoperability demands the same semantics for any server implementation. The model specifies a modular set of components and standard rules for connecting these components. There are three main types of components which are connected into processing chains in the server to create the desired functionality: * The "exchange" receives messages from publisher applications and routes these to "message queues", based on arbitrary criteria - usually message properties or content. * The "message queue" stores messages until they can be safely processed by a consuming client application (or multiple applications). * The "binding" defines the relationship between a message queue and an exchange and provides the message routing criteria. This model emulates the classic middleware concepts of store-and-forward queues and topic subscriptions. It also expresses less trivial concepts such as content-based routing, message queue forking, and on-demand message queues. In very gross terms, an AMQP server is analogous to an email server, with each exchange acting as a message transfer agent, and each message queue as a mailbox. The bindings define the routing tables in each transfer agent. Publishers send messages to individual transfer agents, which then route the messages into mailboxes. Consumers take messages from mailboxes, which creates a powerful and flexible model that is simple. The AMQP Wire-level Format The AMQP wire-level format is a binary framing with modern features: it is multi-channel, negotiated, asynchronous, secure, portable, neutral, and efficient. The AMQP wire-level format is split into two layers; a functional layer and a transport layer. The functional layer defines a set of commands (grouped into logical classes of functionality) that do useful work on behalf of the application. The transport layer that carries these methods from application to server, and back, and which handles channel multiplexing, framing, content encoding, heart-beating, data representation, and error handling. Both the transport layer & high-level layers are plugable, which allows evolution of the protocol and the adoption of emerging technologies. Implementations: Apache Qpid: http://cwiki.apache.org/qpid/ RabbitMQ: http://www.rabbitmq.com/ OpenAMQ: http://www.openamq.org/ ZeroMQ: http://www.zeromq.org/ ZeroMQ also has a nice whitepaper on AMQP: http://www.zeromq.org/whitepapers:amqp-analysis --Levi /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
