Being part of the Service Prototyping lab, the ICCLab teaches the Service Engineering course at ZHAW. As part of that course was a lecture on MuleSoft, a tool that facilitates the data exchange between applications following the service-oriented architecture (SOA) methodology. It was developed to take the donkey-work out of the integration process, allowing developers to connect anything, anywhere. Because it “carries the heavy development load” of connecting systems, it is also sometimes referenced as a Swiss army knife. Mule differs from the typical web application servers by specializing in integration between different applications, databases and cloud services, as opposed to integration with just the end users. Mule applications are also stateless and event-driven.
MuleSoft is an integration platform that consists of CloudHub and Mule ESB. CloudHub is an integration platform as a service (iPaaS) that connects SaaS and on-premise application. It allows cloud to cloud integration as well as cloud to enterprise integration. MuleESB on the other hand, is Java-based enterprise service bus for building and running integration applications and web services. It offers service meditation by separating business logic from protocols and message formats, message routing and data transformation. Most importantly, it provides service creation and service orchestration. It allows the functionalities in any endpoint to be exposed as a service and existing services to be hosted as a lightweight service containers.
To facilitate the access to MuleESB’s functionalities, there is Mule Studio, an Eclipse-based integration development environment that can be used as either a visual, drag-and-drop editor or just a simple XML editor. Because Mule is also based on the concept of event-driven architecture, you can use MuleStudio to create an application that processes messages by forming a flow. The Mule flow is actually a sequence of message-processing events constructed by combining several building blocks which are pre-packed units of business logic. Each building block in the flow evaluates or process the message until it has passed through all the building blocks in the flow. Mule receives the message through a request-response inbound endpoint, transforms the content into a new format and process the business logic before returning a response via the message source.
The Mule flow typically consists of a message source, message processors and some global elements. The message source accepts a message from an external source, thus triggering the execution of the flow itself. The message processors transform, filter and enrich the message, while the global elements are reusable pieces of code that can be invoked by multiple elements in any flow within the application. The Mule message is the data that passes through the application via one or more flows. It consists of a message header that is the meta data about the message, and message payload, the actual data content that is being transported through the Mule application. Mule uses the Mule Expression language (MEL) to facilitate the transport of the Mule message. In the final stages, a response is returned to the original sender or the results of the processing are logged to a database or send to a third party.
For example, lets say that a company has a shipping and a billing service which now need to connect to an inventory system. Writing the code manually may work for the time being, but suppose we want to make a few changes in the future. Or connect to a third party SaaS app. We will then have to update every connection. Instead, Mule can transform the different data formats and act as a translator between them.
To sum up, what Mule basically does is enabling the integration between the SaaS and on-premise applications, eliminating point-to-point connections and taking out the need to worry about the different data formats.