The motivations behind the Mule project were −

• to make things simpler for the programmers,

• the need of lightweight and modular solution that could scale from an application-level messaging framework to an enterprise-wide highly distributable framework.

Mule ESB is designed as an event-driven as well as programmatic framework. It is event-driven because it is combined with unified representation of messages and can be expandable with pluggable modules. It is programmatic because programmers can easily implant some additional behaviors such as specific message processing or custom data transformation.

History

The historical perspective of Mule project is as follows −

SourceForge project

The Mule project was started as the SourceForge project in April 2003, and after 2 years its first version was released and moved to CodeHaus. Universal Message Object (UMO) API was at the core of its architecture. The idea behind UMO API was to unify the logic while keeping them isolated from the underlying transports.

Version 1.0

It was released in April 2005 containing numerous transports. The key focus of many other versions followed by it, was on debugging and adding new features.

Version 2.0 (Adoption of Spring 2)

Spring 2 as configuration and wiring framework was adopted in Mule 2 but it proved to be a major over-haul because of the lack of expressiveness of the required XML configuration. This issue was resolved when XML Schema-based configuration has been introduced in Spring 2.

Building with Maven

The biggest improvement that simplified Mule usage, both at development and deployment times, was the use of Maven. From version 1.3, it started to be constructed with Maven.

MuleSource

In 2006, MuleSource got incorporated “to help support and enable the rapidly growing community using Mule in mission-critical enterprise applications”. It proved to be the key milestone for Mule Project.

Competitors of Mule ESB

Following are some of the major competitors of Mule ESB −

• WSO2 ESB
• Oracle Service Bus
• WebSphere Message Broker
• Aurea CX Platform
• Fiorano ESB
• WebSphere DataPower Gateway
• Workday Business Process Framework
• Talend Enterprise Service Bus
• JBoss Enterprise Service Bus
• iWay Service Manager

Mule’s Core Concept

As discussed, Mule ESB is a lightweight and highly scalable Java-based enterprise service bus (ESB) and integration platform. Regardless of various technologies used by applications, Mule ESB enables easy integration of applications, enabling them to exchange data. In this section, we will discuss about Mule’s core concept coming into play to make such integration happen.

For this, we need to understand its architecture as well as building blocks.

Architecture

The architecture of Mule ESB has three layers namely, Transport layer, Integration layer and Application layer as shown in the following diagram −

Generally, there are following three types of tasks that can be performed to configure and customize Mule deployment −

Service Component Development

This task involves development or re-using the existing POJOs, or Spring Beans. POJOs is a class with attributes that generates the get and set methods, cloud connectors. On the other hand, Spring Beans contains the business logic to enrich messages.

Service Orchestration

This task basically provides the service mediation that involves configuring the message processor, routers, transformers and filters.

Integration

The most important task of Mule ESB is the integration of various applications regardless of the protocols they are using. For this purpose, Mule provides transport methods that allow receiving and dispatching the messages on various protocol connectors. Mule supports many existing transport methods, or we may also use a custom transport method.

Building Blocks

Mule configuration has the following building blocks −

Spring beans

The main use of Spring beans is to construct service component. After constructing spring service component, we can define it through a configuration file or manually, in case you do not have configuration file.

Agents

It is basically a service created in Anypoint Studio before Mule Studio. An agent is created once you start a server and will be destroyed once you stop the server.

Connector

It is a software component configured with the parameters that are specific to protocols. It is mainly used for controlling the usage of a protocol. For example, a JMS connector is configured with a Connection and this connector will be shared among various entities in charge of actual communication.

Global Configuration

As the name implies, this building block is used to set the global properties and settings.

Global Endpoints

It can be used in Global Elements tab which can be used as many times in a flow −

Global Message Processor

As the name implies, it observes or modifies a message or message flow. Transformers and filters are the examples of Global Message Processor.

Transformers − The main job of a transformer is to convert data from one format to another. It can be defined globally and can be used in multiple flows.

Filters − It is the filter that will decide which Mule message should be processed. Filter basically specifies the conditions that must be met for a message to be processed and routed to a service.

Models

In contrast to Agents, it is a logical grouping of services which are created in studio. We have the liberty to start and stop all the services inside a specific model.

Services − Services are the one that wrap our business logic or components. It also configures Routers, Endpoints, transformers and filters specifically for that service.

Endpoints − It may be defined as an object on which services will inbound (receive) and outbound (send) messages. Services are connected through endpoints.

Flow

Message processor use flows to define a message flow between a source and a target.

Mule Message Structure

A Mule message, totally wrapped under Mule Message Object, is the data that passes through applications via Mule flows. The structure Mule’s message is shown in the following diagram −

As seen in the above diagram, Mule Message consists of two main parts −

Header

It is nothing but the metadata of the message which is further represented by the following two properties −

Inbound Properties − These are the properties which are automatically set by the message source. They cannot be manipulated or set by the user. In nature, inbound properties are immutable.

Outbound Properties − These are the properties that contain metadata like an inbound property and can set during the course of flow. They can be set automatically by Mule or manually by a user. In nature, outbound properties are mutable.

Outbound properties become inbound properties when the message passes from the outbound endpoint of one flow to the inbound endpoint of a different flow via a transport.

Outbound properties remain outbound properties when the message is passed to a new flow via a flow-ref rather than a connector.

Payload

The actual business message carried by message object is called payload.

Variables

It may be defined as the user-defined metadata about a message. Basically, variables are temporary pieces of information about a message used by the application that is processing it. It is not meant to be passed along with the messages to its destination. They are of three types as given below −

Flow variables − These variables apply only to the flow in which they exist.

Session variables − These variables apply across all the flows within the same application.

Record variables − These variables apply only to records processed as part of a batch.

Attachments and Extra Payload

These are some extra metadata about message payload which is not necessarily appeared every time in message object.