Back from the Mule Summit 2011

We Octo Mule fanboys assisted at Mule Summit 2011 in Paris. The summit was quite confidential. This made the interactions with MuleSoft technical staff even richer. CTO and founder Ross Mason was here one more time. It was a pleasure to have such technical speakers. Last year we focused on Mule 3 new exchange architecture (FR). Meanwhile MuleSoft largely improved its ESB with new features. This year we will focus on what makes Mule ESB a reliable Enterprise solution.

Business Events Analyzer

With version 3.2, Mule ESB has new business monitoring capabilities. These enhancements fill the lack of previous versions regarding monitoring.

The main applications of this new feature are:

• Root cause analyze : track back the exact source of an issue, without implementing complex logging. This considerably reduce the diagnose time.
• Regulatory compliance data tracking and storage
• SLA monitoring
• Business Activity Monitoring

Here is how it works:

• At design-time, the developer choose which exact events he wants to gather, by adding probes in the Mule configuration code. An event is composed of technical information (processing time, status, etc.) as well as business information (order id, price, customer name, etc.).
• Mule added partial support for Message Store and Message  History patterns. This permits to store an event at any time in the flow.
• A tracking context is associated with each instance of a business flow (the entire processing of an incoming message, not just a technical flow). This context is enriched with new events while the flow executes.
• An agent is running on each Mule instance, and the Management Console collects events from agents in the background.

Note that it is not possible to track entire messages automatically. The developer has to explicitly configure what information to track. We can't interact with the message and resubmit it through the Management Console. As a result, the feature can't be used as a retry point. Manual retry points still has to be tooled up with technical flows.

One interesting thing however is that Mule now supports the Correlation Identifier pattern. this permits end-to-end monitoring of business flows with time breaks (getting out of Mule ESB and back again). Examples :

• Request-Reply over an asynchronous transport (JMS, flat file, etc.)
• An invoice is received after an order is sent, and we want to monitor the all as a unique business flow

High Availability (HA)

Before this new feature, HA had to be tooled up with custom JMS persistence. Different instances of Mule ESB then stored messages in JMS on critical points of the flow, using the Wire Tap pattern. Until JMS became the single point of failure, and so on.

Announced in the roadmap last year, Mule HA is finally here. All these improvements have a price: unless you buy an Enterprise Edition of Mule, you will have to build HA the old way. The new solution offer an active/active clustering across several nodes as follows:

Here is how it works:

• At design-time, use queue-based transport to activate save points. A developer should place a save point at each critical point of the flow, using queues such as the internal transport, JMS, SEDA, etc.
• HA relies on Gigaspaces distributed memory to persist messages and other components states. Gigaspaces is embedded on each node of the cluster
• using save-points enables internal re-load-balancing. This is particularly useful for SEDA-based flow, where the processing can be automatically distributed on workers within the cluster
• Polled resources as flat files, FTP and JDBC are shared across the cluster and automatically available to only one node at a time

Conclusion

During the event, MuleSoft also presented two other new products :

• Mule Studio is an Eclipse-based environment that accelerates Mule developments
• Mule iON is a PaaS platform that offers no more no less than a new deployment option for your flows.

With new mechanisms as persistence (Message Store/Message History), and Correlation Identifier, Mule ESB is extending its initial role. Even if MuleSoft don't communicate on it, and rather highlights integration with external BPM engines, it is getting closer to BPM.

Mulesoft and the community have done a great job in one year. From my point of view, Mule keep its title of most popular ESB. It is very close to fill the gap with vendor's ESBs, providing as many features, but in a lightweight fashion and for a lightweight price per CPU.