CODEWITHSUNDEEP
architecturemessage-queuedistributedamqp
Bwooce
Bwooce

Reputation: 2143

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

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.

Upvotes: 9

Views: 2193

Answers (6)

Rob Cowie
Rob Cowie

Reputation: 22619

As a basis for a reliable, extremely flexible (in terms of messaging patterns) it can be used for many messaging scenarios, both intra-machine (i.e inter-process) and inter-network. It can scale all the way from zero to huge, high-bandwidth, multi-network systems.

I am currently evaluating it for a small, but relatively complex near real-time system where we don't care how far the messages travel or who/what (within reason ;) is consuming them. If a consumer is sitting on the same machine so be it. I'd give it a go and see what you make of it. If you want to knock together a prototype system, use python and the Pika library.

Upvotes: 1

iwein
iwein

Reputation: 26161

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.

Upvotes: 1

Julien
Julien

Reputation: 7861

If you're primarily interested in performances in an intra-machine scenario, the question is less about AMQP (which is only a wire level protocol) than about which implementation you should try.

By removing the latency introduced by the network, you'll probably be a lot more sensitive to the raw performances of the various implementation. Therefore, I would look at products implemented in C++ such as Qpid or Zeromq.

Qpid can easily reach 400 000 messages/second (with messages of 1024 bytes) on some decent hardware (quad core). Zeromq will probably perform a lot better because you can have peer to peer channels whereas Qpid is using a broker architecture (which had a step).

Upvotes: 0

yawn
yawn

Reputation: 8214

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.

Upvotes: 3

Bob
Bob

Reputation: 569

AMQP looks more like a reliable transport middleware offering for SOA than something to be used internally.

Upvotes: 0

James Strachan
James Strachan

Reputation: 9198

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 :)

Upvotes: 2

Related Questions