Giving PHP a Backend

March 12 2012

3 comments 0

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.

PHP Interoperability with AMQP

AMQP is such a protocol.  Defined down to the wire format, native AMQP clients exist for most popular platforms, including PHP.  As previously blogged, Mule has direct support for AMQP via the AMQP transport.  This will allow a PHP front end app application to send and receive messages from Mule servers.

Decoupling the front-end of a web application from the backend with asynchronous messaging is a common architectural approach.  It insulates user facing code from the jungle of external systems that a typical enterprise is forced to integrate with.   Let’s consider such a case:  integration with a  complex order submission process.

Order Submission and Decoupling Middleware

Order submission is typically a very sensitive feature for most e-commerce applications.   It can also be complex.  Such a process typically need to do things like process credit cards, keep track of inventory, calculate tax and shipping and possibly perform fraud detection.  Some of these tasks might be run locally but often will use third-party providers that are prone to going down, changing their API’s or being swapped out for a better or cheaper provider.

Good architecture would dictate that the UI of such an application would be as isolated from the above as possible.  This shields front-end developers from having to deal with the complexity of the integration and, using decoupling middleware, offers resiliency in the UI when these remote services aren’t available or change.

Let’s see how we can accomplish this with Mule and PHP using AMQP.  Let’s first take a look at what the Mule flow looks like:

In this flow we’re consuming an AMQP message keyed with “order.submit” from the “orders-exchange.”  The payload of this message will be JSON sent by the PHP application.  We’re using Mule’s JSON module to transform the JSON string to an instance of our Java domain model.  The subsequent Order object will then be sent synchronously to each VM outbound-endpoint.  Each in turn performs the steps that compose order submission.  When the process is finally completed the order will be converted back to JSON, presumably with some status fields filled out, and dispatched to the events-exchange.

Now let’s see how we can send the message using PHP’s AMQP support.  The following snippet indicates how the order submission on the PHP side sends the message.

One of the features of AMQP is that it decouples the production and consumption of messages.  You probably noticed from the PHP snippet above that we’re not defining a queue anywhere, we’re simply publishing to the exchange.  This allows the same message to be consumed differently depending on how the queue is created.   Contrast this to JMS, where you would need to manually publish a message to both a queue and a topic if you wanted to simultaneously support both delivery semantics.

Now let’s see how we could potentially consume the update published by Mule to the events-exchange.  The Gist below illustrates this.

Note the wildcard used as the consumer key.  This bit of code will respond to all order events submitted to the events-exchange.  It could be useful in an admin dashboard, for instance, to dynamically show updates as orders are processed.

Wrapping Up

Hopefully this post showed how easy it is to integrate PHP and Mule together with AMQP.   PHP’s ease of use and speed of development on the front-end and Mule’s extensive integration capabilities on the backend is a powerful approach when architecting web applications.

For more examples of using AMQP with PHP and Java check out RabbitMQ in Action.

We'd love to hear your opinion on this post

3 Responses to “Giving PHP a Backend”

  1. Agree(0)Disagree(0)Comment
  2. I had implemented something identical for order processing/management, delegating from PHP to Java but used RESTful endpoints instead of AMQP. The biggest challenge is error handling and rolling back remote transactions (Tax API, Payment API) with external vendors. As we coupled more and more services to the order processing chain, the exception handling became a non-trivial task and we would spend 80% coding/managing exceptions than implementing a new service (Mule makes implementation a breeze !!)

  3. […] talked in the past on this blog about Mule being used as a backend for PHP, now PHP developers can code custom logic in Mule using PHP. Mule scripting component allows you […]