As evident by some prominent web applications PHP remains a popular choice when implementing the front-end of a web application. PHP’s lacks a bit, however, when it comes to implementing the backend of such applications. While some very nice frameworks are beginning to fill this gap, the Java ecosystem is often a better choice for implementing the backend of a PHP application.
Despite this, however, integrating PHP and Java isn’t a straightforward task. A robust PHP implementation for the JVM doesn’t exist. HTTP based protocols like SOAP and REST can work, but we usually want something reliable for messaging behind the firewall. JMS might seem like an obvious answer, but most brokers only support Java. Stopgaps like Stomp also exist but, it too, isn’t a reliable transport. What we really need is a reliable transport that works natively with PHP and Java.
Last month the AMQP working group, which includes big hitters such as Bank of America, Credit Suisse, JPMorgan Chase, Barclays, Goldman Sachs, Microsoft, Cisco, VMWare, Redhat, and Informatica finalised version 1.0 of the AMQP standard. It has been 5 years in the making, the market for messaging has changed a lot in that time.
What is AMQP?
“The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security.” – Wikipedia
The specifications are available on-line and several broker implementations exist, like the popular RabbitMQ and Apache Qpid. AMQP is built around a few easy to grasp concepts:
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.
Three months ago, I’ve introduced the newly created Erlang Transport for Mule 3 in this blog. To illustrate a usage scenario for this transport, which allows fast and seamless bi-directional communications between the JVM and the Erlang worlds, I presented an example where Mule was exposing a JSON over HTTP service for provisioning users in RabbitMQ.
At that time, the new configuration mechanism named Flow was not fully baked so I implemented the example “Mule 2 style“, which means that I used Services tied together with VM queues.
Now that Mule 3.0.0 is out, my challenge for today’s post was to redo the configuration “Mule 3 style“, i.e. using by Flows.
Though a veteran language and platform, Erlang has recently gained a lot of traction, as very visible web sites and open source projects decided to use it in order to leverage its intrinsic support for highly concurrent, fault tolerant and distributed applications. To name a few, let’s mention: Facebook Chat, Mochiweb, ejabberd, RabbitMQ, riak and CouchDB.
Without opting for Erlang as a development platform, companies may still be tempted to leverage an Erlang-built middleware: most of them offer public interfaces accessible over generic protocols, like HTTP, and are easy to integrate quickly and efficiently. That said advanced scenarios can require a tighter integration like, for example, creating a module for ejabberd that requires to call custom Java code or reaching server functions on RabbitMQ that are not accessible through AMQP.
This is when the Duke meets Erl. And this is when Mule ESB can help, thanks to the new and coming Erlang Transport for Mule 3. Read on for more information about the transport and a walk-through a simple use-case of RabbitMQ integration.