Asynchronous messaging is critical to creating a truly scalable system, where various services can communicate with each other easily, can scale up and down independently, and where one service failing won’t cause all the other services to fail. With the trend of microservices in full swing, this has become even more important. As Tim Bray from Amazon stated: “The proportion of services I work on where queues are absolutely necessary rounds to 100%.”
I’m at the Barcelona airport. It’s summer and I’m finally going to visit my family in Badajoz after a long period. The queue at the security checkpoint looks endless but I have time. The phone rings. It’s my mom, she’s excited that I’m visiting and is giving me an update on how things are there now.
Once upon a time, I couldn’t do without my middleware. To make my application resilient and scalable, and to allow it to talk to everything else in the enterprise, I had no choice but to stand up an ESB in my architecture. It was literally in the middle of everything I did. Then, when I moved to the cloud, my world began to change.
Complex event processing engines are a natural fit for event driven platforms like Mule. Native CEP support has been available in Mule since version 3.2 by way of the Drools Module. The Esper Module now offers an alternate way to leverage CEP in your integration applications. Esper is a robust, performant, open source, complex event processing engine. Let’s take a look at how to use Esper with Mule and then see how it compares to Drools’
When you send a request to an API and it gets processed the API might want to notify you app about the status of the request. In order for your application to handle this callback you would have to set up an endpoint to listen for the notification and then send the url of that endpoint to the API. For example Twilio, one of the most popular public APIs,
