At DEVOXX last year I was cringing when I heard a talk where they went into depth about how to make HTTP work as a SOA layer and kept telling myself ... but AMQP already solved all those issue, why re-invent that with HTTP with layers upon layers of complexity?

HTTP you've probably heard about, if you've never about AMQP, here's a short snippet from Wikipedia:

AMQP is a binary, application layer protocol, designed to efficiently support a wide variety of messaging applications and communication patterns. It provides flow controlled, message-oriented communication with message-delivery guarantees such as at-most-once (where each message is delivered once or never), at-least-once (where each message is certain to be delivered, but may do so multiple times) and exactly-once (where the message will always certainly arrive and do so only once), and authentication and/or encryption based on SASL and/or TLS. It assumes an underlying reliable transport layer protocol such as Transmission Control Protocol (TCP).

The AMQP specification is defined in several layers: (i) a type system, (ii) a symmetric, asynchronous protocol for the transfer of messages from one process to another, (iii) a standard, extensible message format and (iv) a set of standardised but extensible 'messaging capabilities.

And some more reading from the AMQP specifications themselves:

amqp.org/product/solve

amqp.org/product/overview

If you've used any of the two, what was your experience?

Answer

If you're building for large intranets and have close communication with developing parties on both sides, I'm sure AMQP is a great protocol/standard to use. If you're building for the web/cloud, it seems to me you're better of with the standard that is already in use, adopted and useable without extra effort on standard hardware: HTTP/REST

1 Beer1
Show all replies

For anything external-facing that people integrate into, sure, HTTP makes sense, but that doesn't stop you from using AMQP (or both) as I've seen some companies does.

If you replace the HTTP endpoint with an AMQP endpoint, you get everything you'd get with HTTP minus the unreliability of HTTP. The message you POSTed to your HTTP endpoint, you now simply publish to the AMQP endpoint.

With HTTP there IS extra effort you need to do, service discovery, overload protection, retry-if-fail in certain cases, load-balancing, etc whereas AMQP gives you all of the out of the box with much better throughput.

Reply to this…

(2 answers) Take me to the question