Is AMQP suitable as both an intra and inter-machine software bus?

Question

I'm trying to get my head around AMQP. It looks great for inter-machine (cluster, LAN, WAN) communication between applications but I'm not sure if it is suitable (in architectural, and current implementation terms) for use as a software bus within one machine.

Would it be worth pulling out a current high performance message passing framework to replace it with AMQP, or is this falling into the same trap as RPC by blurring the distinction between local and non-local communication?

I'm also wary of the performance impacts of using a WAN technology for intra-machine communications, although this may be more of an implementation concern than architecture.

War stories would be appreciated.

Answer 1

AMQP is not an RPC framework. It provides the building blocks to model things like shared queues, RPC, pubsub etc. but it does not mandate any specific way to use it.

If you want to partition your application (making it distributable on the way) and to wire it together with AMQP I think it's the right technology. There might be faster alternatives though but probably none as generic as AMQP.

Answer 2

AMQP is a specification so you'd be comparing apples with oranges really. There are not that many production ready AMQP providers out there really; none of the major messaging providers or vendors support AMQP at the time of writing (e.g. IBM, Tibco, Sonic, BEA, Oracle, SwiftMQ, MS, Apache ActiveMQ, openmq from Sun) - so all the available AMQP providers are pretty new.

So I'd recommend comparing whatever AMQP provider you are interested in with your message passing framework. There's no point ripping something out that is working fine just because of the way it reads & writes bytes to a socket :)

Answer 3

The AMQP standard is getting mature and solves some of the hairy problems that have plagued other messaging standards like JMS. To your question whether it's worth replacing an existing solution, I'd say it depends. I would be very skeptical, since presumably the system is already working, in production and highly performant.

If you have problems like:

• Interoperability is not working
• Can't scale out easily
• Performance isn't good enough
• The current messaging solution is expensive (to maintain)

You should investigate the work required and analyze the benefits more precisely. If you're already happy, replacing a messaging framework isn't going to return on investment.