March 1, 2021
Hot Topics:

The Fundamentals of Mule Configuration

  • By Thribhuvan Thakur
  • Send Email »
  • More Articles »

Mule Components

This section defines various components that make up the Mule messaging framework and explains how to configure them using XML. The discussion refers to Mule version 2.x.

Service Component

Services are the primary Mule artifact used to implement integration solutions. A service component is a piece of code that implements some business functionality (see Figure 3). One of the primary advantages of Mule is that service components can be simple POJOs with no pre-existing external interface other than the invocation of its methods. In early versions of Mule (1.x), service components were called universal message objects (UMO).

Click here for larger image

Figure 3: Service Component

Mule provides pluggable connectivity for any service component by wrapping it with Mule-specific configuration settings that define service-specific behavior and translating external messages into an invocation of a service component's method and controlling its lifecycle. The configuration for this translation is in an XML file (mule-config.xml by default) that specifies the message flow, which should be directed to the service component.

Mule Messages

A message in Mule is simply a packet of data that can be handled and sent between applications on a specific channel or an endpoint. A message is also the equivalent of an event that is triggered by an external occurrence such as a data being received on a queue or a file being copied to a directory. You can generate MuleMessage programmatically with the Mule client.

Service Endpoints

An endpoint functions as a gateway or channel that connects the service component to external messages, which can be either local or over a network (see Figure 4). Mule can be configured to intercept messages on endpoints and transform them if needed before passing the messages onto the service components.

Click here for larger image

Figure 4: Inbound and Outbound Endpoints

A service can use different transports to receive and send messages. For each type of transport that a service will use, you could use a separate endpoint.

Message Routers

Message routers control how messages are received by components and where they are sent after they are processed. Inbound routers control how a service handles incoming messages (e.g., selectively allowing only those messages that meet specific criteria). Outbound routers control how a message is dispatched after the service has processed it (e.g., sending it to a list of recipients or splitting up the message and sending the parts to different endpoints). See Figure 5.

Click here for larger image

Figure 5: Inbound and Outbound Routers

Routers work in conjunction with filters, which specify conditions that must be met for a message to be routed to a service, and expressions to extract information from the current message.

Transports and Connectors

A transport is a data carrier that carries messages between applications using a specific protocol (see Figure 6). Mule provides support for various standard transports (JMS, HTTP, etc.) along with a facility to create custom transports by extending org.mule.transport.AbstractConnector.

Click here for larger image

Figure 6: Mule-Provided Transports

A connector represents the configuration of a specific transport. For example, a JMS connector uses a queue or topic to receive and send data; a HTTP connector uses a port to exchange data. The specific queue, topic, or port is specified within the connector. Connectors can be specified globally (for the entire Mule application) or locally at the service level.


Data transformation is a technique that enables disparate components to understand each other's messages. A message undergoes a translation process to bridge any gap between the data representations of the two components. Mule translators (which Mule calls transformers) are Java classes, which are the data equivalent of the Adapter pattern (GOF) for messages (see Figure 7).

Click here for larger image

Figure 7: Transformer Translate Messages

Examples of translations include the transformation of an XML message to another XML format or an XML message into a Java object. Transport-specific transformers are used to convert data received and sent on a specific protocol (e.g., ObjectToJMSMessage transformer for the JMS transport).

Mule comes with a variety of transformers and allows you to create specialized ones by extending the AbstractTransformer.

A service itself may be confined to the local network or may use a native or proprietary transport that is not supported by external applications. By providing a messaging framework that is capable of translations via transformers and providing access to the service component via endpoints, Mule exposes a component service to general intranet/Internet message exchange.

Page 2 of 4

This article was originally published on June 11, 2009

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date