The architecture of Mule is driven by the principles of Industrial Best Practice as outlined in the well-known Enterprise Integration Patterns which have identified the most common building blocks for every integration problem. These building blocks are what make up Mule Flows, the executable units inside Mule Applications. No matter what the problem, wiring them together into an integration solution is extremely easy and by exploiting the power of Mule’s native support for the Drools Rules Engine, the Integration Developer has a very powerful set of tools to tackle even the most complex of integration problems with the greatest of ease. With this post I hope to be able to demonstrate this to you!
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’ CEP support.
Mule 3.2 is right around the corner and it is shaping up as the best Mule release ever.
Some highlights include:
One of the more common usages of Mule is as the integration piece of a larger SOA architecture. Mule has traditionally never attempted to offer a complete SOA suite/stack of products as some of its larger competitors do, but has rather focused on the thing it does best, which is integration. Other aspects of an SOA architecture (messaging backbone, data storage, governance, etc.) are generally provided by other best-of-breed solutions for those areas, and Mule allows you to integrate with as many different options as possible.