Messaging systems used to be found only in big enterprises or in the financial sector. Who else needed the reliability and scalability offered by such systems? But times have changed: public web sites have grown to sizes that dwarf some of the most advanced corporate systems. And as these web sites have grown, the need for timely decoupling their subsystems in order to scale has increased to.
This lead an entirely different breed of developers to want messaging systems too. They wanted something simple, fast and proven. And it needed to work with their languages of choice too: PHP, Ruby, Python, anything but the usual suspects of the enterprise world.
In such context, AMQP (the Advanced Message Queuing Protocol) was poised to succeed, as it defines a truly inter-operable platform-agnostic messaging protocol.
We’re happy to announce that the AMQP Transport for Mule 3.1 is now available! With this transport in hand, developers will be able to perform complex integration tasks while benefiting from the combined powers of Mule ESB and AMQP.
The on-line user guide is the best source of information about this feature-laden transport. Here is a summary of the super capacities of the AMQP transport:
- Inbound message receiving via subscription to existing or declared exchanges and queues.
- Outbound message publication to existing or declared exchanges.
- Outbound request-response pattern supported via temporary reply queues.
- Synchronous Message requesting with time-out.
- Passive or active-only exchange and queue declarations.
- Support for connection fallback accross a list of AMQP hosts.
- Support of all AMQP’s message properties, including custom headers.
- Support of reply to (publishing replies to the default exchange).
- Support of automatic, Mule-driven and manual message acknowledgment.
- Support of manual message rejection.
- Support of the default exchange semantics in outbound endpoints.
- Support of mandatory and immediate publish parameters and handling of returned (undelivered) messages.
- Support of prefetch size and count “quality of service” settings.
- Support of noLocal and exclusive consumers.
At this point a “w00t!” would be de rigueur but instead we’ll look at a few configuration examples.
Show me teh codez
This first example demonstrates a bridge between an inbound AMQP queue and an outbound HTTP destination:
If it looks like a lot of configuration, bear in mind that it is because we re-declare both the exchange and the queue we’re connecting to (a common AMQP pattern). We could also decide to only consume existing queues, like in the following example:
Notice how, as a result of the message massager component invocation, we decide to acknowledge or reject an AMQP message delivery: that’s because the Mule AMQP transport allows you to manually ack or nack messages with specific configuration elements.
Now let’s look at a final example that illustrates outbound message sending, the dynamic definition of a routing key and the handling of returned messages when delivery fails (as it can be the case when mandatory delivery is required):
Note that it is also possible to define a global handler for returned messages.
As always, your feedback will be very welcome.