Reliability Pattern in Mule
Reliability Pattern in Mule
This article talks about ensuring the reliability of your HTTP application with the reliability pattern provided by Mule.
Join the DZone community and get the full member experience.Join For Free
Learn more about how to Prevent Slow or Broken APIs From Affecting Your Bottom Line.
A reliable application is one that can not tolerate a single loss of information. For an application to be reliable, apart from the underlying ESB being highly reliable, it is necessary that the connections made by the application to other services must be reliable too. If the application uses a transactional transport such as JMS, VM, or JDBC, reliable messaging is ensured by the built-in support for transactions in the transports. This means that you can configure a transaction on a JMS inbound endpoint that makes sure messages are only removed from the JMS server when the transaction is committed.
However, most of the time, we use connections that are not reliable. For example, HTTP transport. How would you ensure reliability in an HTTP application? This is the point of discussion of this article.
The reliability pattern provided by Mule ensures that the messaging is reliable for an application even though application receives messages from a non-transactional transport. Here comes the best use of VM connector.
Let's assume the simplest virtual scenario as depicted below:
In the scenario above, we receive an order on an HTTP endpoint. Then we log the order, and finally, send the order to SalesForce for further processing. Our application must be highly reliable, i.e we can not lose a single piece of order information.
Now assume that the application has received an order information and suddenly the Mule ESB went down. So, your order is definitely gone. How do you tackle this problem? Here is how the Reliability Pattern comes into play.
Refactor the Application
Let's refactor the above application as shown below:
This approach is exactly same as using JMS queue. But fortunately, by using the VM Connector in Mule, you don't incur the administrative cost and performance overhead of running a separate JMS Broker.
You can make the VM Connector persistent by applying the Queue Store configuration as shown below:
In my case, the message passed over the queue (orderqueue in the example) will be persisted to the disk of the machine. So in the event of a Mule shutdown or failure, it will still be delivered to the HTTP outbound endpoint.
Also, the characteristics of how the VM transport stores its messages can be configured by defining the queue profile VM connector.
Using just the simple VM Connector provided by Mule, a simple non-transactional flow can be made highly reliable. Also, instead of using the VM Connector, the JMS connector can also be used to implement the reliability pattern.
Opinions expressed by DZone contributors are their own.