Getting Started with Mule

Abdul Samad

August 2013

(For more resources related to this topic, see here.)

Mule ESB is a lightweight Java programming language. Through ESB, you can integrate or communicate with multiple applications. Mule ESB enables easy integration of existing systems, regardless of the different technologies that the applications use, including JMS, web services, JDBC, and HTTP.

Understanding Mule concepts and terminologies

Enterprise Service Bus (ESB) is an application that gives access to other applications and services. Its main task is to be the messaging and integration backbone of an enterprise.

An ESB is a distributed middleware system to integrate different applications. All these applications communicate through the ESB. It consists of a set of service containers that integrate various types of applications. The containers are interconnected with a reliable messaging bus.

Getting ready

An ESB is used for integration using a service-oriented approach. Its main features are as follows:

  • Polling JMS
  • Message transformation and routing services
  • Tomcat hot deployment
  • Web service security

We often use the abbreviation, VETRO, to summarize the ESB functionality:

  • V– validate the schema validation
  • E– enrich
  • T– transform
  • R– route (either itinerary or content based)
  • O– operate (perform operations; they run at the backend)

Before introducing any ESB, developers and integrators must connect different applications in a point-to-point fashion.

How to do it...

After the introduction of an ESB, you just need to connect each application to the ESB so that every application can communicate with each other through the ESB. You can easily connect multiple applications through the ESB, as shown in the following diagram:

Need for the ESB

You can integrate different applications using ESB. Each application can communicate through ESB:

  • To integrate more than two or three services and/or applications
  • To integrate more applications, services, or technologies in the future
  • To use different communication protocols
  • To publish services for composition and consumption
  • For message transformation and routing


What is Mule ESB?

Mule ESB is a lightweight Java-based enterprise service bus and integration platform that allows developers and integrators to connect applications together quickly and easily, enabling them to exchange data. There are two editions of Mule ESB: Community and Enterprise. Mule ESB Enterprise is the enterprise-class version of Mule ESB, with additional features and capabilities that are ideal for clustering and performance tuning, DataMapper, and the SAP connector. Mule ESB Community and Enterprise editions are built on a common code base, so it is easy to upgrade from Mule ESB Community to Mule ESB Enterprise.

Mule ESB enables easy integration of existing systems, regardless of the different technologies that the applications use, including JMS, web services, JDBC, and HTTP. The key advantage of an ESB is that it allows different applications to communicate with each other by acting as a transit system for carrying data between applications within your enterprise or across the Internet. Mule ESB includes powerful capabilities that include the following:

  • Service creation and hosting: It exposes and hosts reusable services using Mule ESB as a lightweight service container
  • Service mediation: It shields services from message formats and protocols, separate business logic from messaging, and enables location-independent service calls
  • Message routing: It routes, filters, aggregates, and re-sequences messages based on content and rules
  • Data transformation: It exchanges data across varying formats and transport protocols

Mule ESB is lightweight but highly scalable, allowing you to start small and connect more applications over time. Mule provides a Java-based messaging framework. Mule manages all the interactions between applications and components transparently. Mule provides transformation, routing, filtering, Endpoint, and so on.

How it works...

When you examine how a message flows through Mule ESB, you can see that there are three layers in the architecture, which are listed as follows:

  • Application Layer
  • Integration Layer
  • Transport Layer

Likewise, there are three general types of tasks you can perform to configure and customize your Mule deployment. Refer to the following diagram:

The following list talks about Mule and its configuration:

  • Service component development: This involves developing or re-using the existing POJOs, which is a class with attributes and it generates the get and set methods, Cloud connectors, or Spring Beans that contain the business logic and will consume, process, or enrich messages.
  • Service orchestration: This involves configuring message processors, routers, transformers, and filters that provide the service mediation and orchestration capabilities required to allow composition of loosely coupled services using a Mule flow. New orchestration elements can be created also and dropped into your deployment.
  • Integration: A key requirement of service mediation is decoupling services from the underlying protocols. Mule provides transport methods to allow dispatching and receiving messages on different protocol connectors. These connectors are configured in the Mule configuration file and can be referenced from the orchestration layer. Mule supports many existing transport methods and all the popular communication protocols, but you may also develop a custom transport method if you need to extend Mule to support a particular legacy or proprietary system.

  • Spring beans: You can construct service components from Spring beans and define these Spring components through a configuration file. If you don't have this file, you will need to define it manually in the Mule configuration file.
  • Agents: An agent is a service that is created in Mule Studio. When you start the server, an agent is created. When you stop the server, this agent will be destroyed.
  • Connectors: The Connector is a software component.
  • Global configuration: Global configuration is used to set the global properties and settings.
  • Global Endpoints: Global Endpoints can be used in the Global Elements tab. We can use the global properties' element as many times in a flow as we want. For that, we must pass the global properties' reference name.
  • Global message processor: A global message processor observes a message or modifies either a message or the message flow; examples include transformers and filters.
  • Transformers: A transformer converts data from one format to another. You can define them globally and use them in multiple flows.
  • Filters: Filters decide which Mule messages should be processed. Filters specify the conditions that must be met for a message to be routed to a service or continue progressing through a flow. There are several standard filters that come with Mule ESB, which you can use, or you can create your own filters.
  • Models: It is a logical grouping of services, which are created in Mule Studio. You can start and stop all the services inside a particular model.
  • Services: You can define one or more services that wrap your components (business logic) and configure Routers, Endpoints, transformers, and filters specifically for that service. Services are connected using Endpoints.
  • Endpoints: Services are connected using Endpoints. It is an object on which the services will receive (inbound) and send (outbound) messages.
  • Flow: Flow is used for a message processor to define a message flow between a source and a target.

Setting up the Mule IDE

The developers who were using Mule ESB over other technologies such as Liferay Portal, Alfresco ECM, or Activiti BPM can use Mule IDE in Eclipse without configuring the standalone Mule Studio in the existing environment. In recent times, MuleSoft ( only provides Mule Studio from Version 3.3 onwards, but not Mule IDE. If you are using the older version of Mule ESB, you can get Mule IDE separately from

Getting ready

To set Mule IDE, we need Java to be installed on the machine and its execution path should be set in an environment variable. We will now see how to set up Java on our machine.

  1. Firstly, download JDK 1.6 or a higher version from the following URL:
  2. In your Windows system, go to Start | Control Panel | System | Advanced.
  3. Click on Environment Variables under System Variables, find Path, and click on it.

  4. In the Edit window, modify the path by adding the location of the class to its value. If you do not have the item Path, you may select the option of adding a new variable and adding Path as the name and the location of the class as its value.

  5. Close the window, reopen the command prompt window, and run your Java code.

How to do it...

If you go with Eclipse, you have to download Mule IDE Standalone 3.3.

  1. Download Mule ESB 3.3 Community edition from the following URL: Unzip the downloaded file and set MULE_HOME as the environment variable.
  2. Download the latest version of Eclipse from

After installing Eclipse, you now have to integrate Mule IDE in the Eclipse. If you are using Eclipse Version 3.4 (Galileo), perform the following steps to install Mule IDE. If you are not using Version 3.4 (Galileo), the URL for downloading will be different.

  1. Open Eclipse IDE.
  2. Go to Help | Install New Software….

  3. Write the URL in the Work with: textbox: and press Enter.
  4. Select the Mule IDE checkbox.
  5. Click on the Next button.
  6. Read and accept the license agreement terms.
  7. Click on the Finish button.

    This will take some time. When it prompts for a restart, shut it down and restart Eclipse.

Mule configuration

After installing Mule IDE, you will now have to configure Mule in Eclipse. Perform the following steps:

  1. Open Eclipse IDE.
  2. Go to Window | Preferences.

  3. Select Mule, add the distribution folder mule as standalone 3.3; click on the Apply button and then on the OK button. This way you can configure Mule with Eclipse.

Installing Mule Studio

Mule Studio is a powerful, user-friendly Eclipse-based tool. Mule Studio has three main components: a package tree, a palette, and a canvas. Mule ESB easily creates flows as well as edits and tests them in a few minutes. Mule Studio is currently in public beta. It is based on drag-and-drop elements and supports two-way editing.

Getting ready

To install Mule Studio, download Mule Studio from

How to do it...

Unzip the Mule Studio folder. Set the environment variable for Mule Studio. While starting with Mule Studio, the config.xml file will be created automatically by Mule Studio.

The three main components of Mule Studio are as follows:

  • A package tree
  • A palette
  • A canvas

A package tree

A package tree contains the entire structure of your project. In the following screenshot, you can see the package explorer tree. In this package explorer tree, under src/main/java, you can store the custom Java class. You can create a graphical flow from src/main/resources.

In the app folder you can store the file. The folders src, main, and app contain the flow of XML files. The folders src, main, and test contain flow-related test files. The Mule-project.xml file contains the project's metadata. You can edit the name, description, and server runtime version used for a specific project. JRE System Library contains the Java runtime libraries. Mule Runtime contains the Mule runtime libraries.

A palette

The second component is palette. The palette is the source for accessing Endpoints, components, transformers, and Cloud connectors. You can drag them from the palette and drop them onto the canvas in order to create flows. The palette typically displays buttons indicating the different types of Mule elements. You can view the content of each button by clicking on them. If you do not want to expand elements, click on the button again to hide the content.

A canvas

The third component is canvas; canvas is a graphical editor. In canvas you can create flows. The canvas provides a space that facilitates the arrangement of Studio components into Mule flows. In the canvas area you can configure each and every component, and you can add or remove components on the canvas.

Configuring Mule components

A simple POJO component will be invoked by Mule when a message is received. You can create your own custom component.

Getting ready

There are three types of components in Mule Studio:

  • Simple component
  • Java component
  • Other components

How to do it...

Service components contain the business logic. Drag-and-drop a Component from the palette onto the canvas and configure the component. Double-click on the component.

How it works...

The following are the palette components present in Mule.


Palette components

There are different palette components available in Mule Studio, where each palette component has different uses. We will see that in detail here:

  • Endpoints
  • Components
  • Transformers
  • Filters
  • Flow control
  • Routers
  • Scopes
  • Cloud connectors


Generally, Endpoints send and receive data, and are responsible for connecting to external resources and delivering messages. Endpoints can be Inbound or Outbound. An Inbound Endpoint receives messages via its associated transport. Each transport implements its own Inbound Endpoint element. An Outbound Endpoint sends messages via its associated transport. Each transport implements its own Outbound Endpoint element.

  • FTP Endpoint: This Endpoint reads files from the FTP server. This Endpoint carries all the information for an FTP connection. The host and port values are required. The FTP Endpoint implements a file transport channel so that your Mule application can exchange files with an external FTP server. You can configure FTP as an Inbound Endpoint (which receives files) or Outbound Endpoint (which writes files to the FTP server). This is only used in the Enterprise edition.
  • File Endpoint: This Endpoint reads a file from the filesystem. The File Endpoint implements a transport channel so that your Mule application can exchange files with a filesystem. You can implement the File Endpoint as an Inbound Endpoint (a message source), or as an Outbound Endpoint. This Endpoint implements only a one-way exchange pattern. The File Endpoint is used for transferring the file from one directory to another.
  • Generic Endpoint: This Endpoint is used as a dynamic way to configure an Endpoint using Mule expressions and specifying paths. The Generic Endpoint allows for a wide array of configuration options by defining a particular transport to be used as the Endpoint.
  • HTTP Endpoint: This Endpoint is used to process HTTP requests or responses. Mule uses HTTP Endpoints to send and receive requests over the HTTP transport protocol, or HTTPS over the SSL protocol. Configured as either Inbound (also known as message sources) or Outbound, HTTP Endpoints use one of the two patterns: request-response and/or one-way.
  • JMS Endpoint: This Endpoint is used to send or receive messages from a JMS queue. The JMS Endpoint's two-way exchange patterns use: request-response and/or one-way.
  • VM Endpoint: This Endpoint is used for an in-memory queue that allows you to integrate different flows or services in the same Mule configuration. The VM Endpoint's two-way exchange patterns use request-response and/or one-way.



The Studio building blocks are known as components and fall into three categories: general, script, and web service.

General components execute whenever a message is received. The logic embedded into general components cannot be modified. Components such as Logger, Flow Reference, and Echo fall into this category.

Script components do not contain prepackaged logic; instead they allow the developer to specify the logic (in the form of a custom script or a Java class) to add into the component. Script components also allow you to:

  • Configure interceptors
  • Add Spring beans
  • Change the value or reference of a specific property within the associated class

The Java component allows you to reference a Java class. The other script components support the Groovy, JavaScript, Python, and Ruby scripting engines.

Web service components, as the name implies, enable Mule to use SOAP and RESTful protocols to communicate with external web services. The SOAP and RESTful components use CXF and Jersey services to convert messages from Java to XML. Web service components also allow the developer to select or define the logic to be invoked by the component. If using the RESTful component, you only need to select a Java class and add a script to the component. On the other hand, SOAP configuration requires you to define attributes and select the operation method used to publish a SOAP web service.

As an example of how the SOAP component can be used, a SOAP message could be sent to a web-service-enabled website, such as a used car price database, with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data; for example, prices, models, and features. The data returned is then integrated directly into a third-party website or application.

The following components are present in Mule:

  • Echo: This component is used to echo a message payload to the console.
  • Logger: This component is used to perform logging using an expression that determines what should be logged depending on the logging level. Use Logger to log messages, such as error messages or exceptions.
  • REST: This component is used to make a REST service available via Jersey. REST is the formalized architecture of HTTP based on the concepts of resources, links, and a uniform interface. It uses the HTTP protocol. We can create a web service using the REST component.
  • SOAP: This component is used to make a web service available via CXF. You can create a CXF web service in Studio by configuring a SOAP component in your Mule flow to perform any of the following CXF web service operations:
    • Publish a simple service
    • Publish a JAX-WS service
    • Proxy a published service
    • Consume a service using a simple client
    • Consume a service using JAX-WS client
    • Proxy to a service

Using Mule's SOAP component, you can also enable WS-security, specify data bindings, and add interceptors to your CXF web service.



Transformers convert message payloads to formats expected by their destinations. Mule ESB provides many standard transformers, which you configure using predefined elements and attributes in your Mule XML configuration file. You can also configure custom transformers using the <custom-transformer>element. You can configure a transformer locally or globally.

The following transformers are present in Mule:

  • Custom Transformer: Transformers in Mule are used to convert messages from one format to another or to manipulate the message information such as headers and attachments. Mule ESB also provides several standard transformers, including XML transformers. You can create your own custom Java class using the extended AbstractTransformer interface. Two ways to create a Custom Transformer are:
    • Use a transformer annotation on a method
    • Create a custom Java class
  • Object-to-Xml transformer: This transformer is used to convert a Java object to an XML representation using XStream. You configure this transformer using the <object-to-xml-transformer>element.
  • Script Transformer: This transformer is used to transform the payload using a script. This defines script components to be used as transformers. The Script transformer lets you select the particular scripting engine from a pull-down list. The predefined script transformers, namely, Groovy, JavaScript, Python, and Ruby, have the scripting engines already set.
  • Transformer Ref: This transformer is used to reference a global transformer.
  • XSLT Transformer: This transformer is used to transform XML using XSLT.
  • Xml-to-Object Transformer: This transformer is used to convert XML to Java bean graphs using XStream. You configure this transformer using the <xml-to-object transformer>element.


Filters specify conditions that must be met for a message to be routed to a service or continued progressing through a flow. There are several standard filters that come with Mule ESB, which you can use, or you can create your own filters. You can create a global filter and then reference it from your services and flows. You can define a filter locally or globally.

The following filters are present in Mule:

  • Custom Filter: This filter is used as a user-implemented filter. The standard filters handle most filtering requirements, but you can create your own custom filter. To create a custom filter, you have to implement the Filter interface.
  • Exception Filter: This is a filter that matches an exception type.
  • Expression Filter: This filter evaluates a range of expressions providing different types of evaluators such as XPath, JXPath, and OGNL and also a custom evaluator.
  • Message Property Filter: This filter allows you to add logic to your routers based on the value of one or more properties of a message. This filter can be very powerful because the message properties are exposed, allowing you to reference any transport-specific or user-defined properties.
  • Filter Reference: This filter is used to reference to a globally defined filter.
  • Regular Expression Filter: This filter is used on a filter that applies a regular expression pattern to the message payload.
  • Wildcard Filter: This is a filter that matches string messages against wildcards.
  • Payload Filter: This is a filter that checks the class type of the payload object inside a message.


Flow Controls/Routers route messages to various destinations in a Mule flow. Some Flow Controls incorporate logic to analyze and possibly transform messages before routing takes place.

The following Routers are present in Mule:

  • All: This Router can be used to send the same message to multiple targets. It sends messages to all routes.
  • Choice: The Router sends a message to the first message processor that matches. It routes messages based on expressions.


Cloud Connectors

A Cloud Connector easily integrates your Mule application with third-party web APIs. A Cloud Connector is built using the Cloud connect toolset, which resides in Mule Studio by default.

The following Cloud Connectors are present in Mule:

  • Salesforce: This connector provides an easy way to integrate with the Salesforce API. This allows users to create flows which can query, create, and update information in Salesforce.
  • Twitter: This connector provides an easy way to integrate with the Twitter API using Mule flows.


Deploying your first Hello World application on the Mule server

By creating a simple Hello World application, you will know how to create a flow and deploy the flow using the Mule server.

Getting ready

Using the steps for application deployment, given in this recipe, you will learn the execution of the flow, how that flow execution will occur, and what will be the output of the application code.

How to do it...

In this example you will see how to create and deploy the first "hello world" using Mule Studio.

  1. Open Mule Studio and enter the name for the workspace name, as shown in the following screenshot:

  2. Create a project in Mule Studio. You will see the Mule Studio Welcome Page window. If you click on New Mule Project Based on a template, you will see an existing example. By clicking on Go to Mule Studio, it will start redirecting away from the Mule Studio Welcome Page window. You can even create a project from a menu bar by going to File | New | Mule Project.

  3. Enter the project name called HelloWorld, click on Next, and enter the .mflow name as the filename. Then, click on the Finish button.

  4. Go to src/main/java, right-click on it, and go to New | Class. Create a class called Greeting under the package; here we have created the sayHi method and its return type is set to String.

    public String sayHi(String str)
    return "Hello "+str;

  5. Go to the Greeting.Mflow file. In the following screenshot, the central part is called the canvas where we can put graphical elements and on the right-hand side you can see the group of elements; this area is called a palette. You have to drag-and-drop the HTTP Endpoint from the palette onto the canvas area.

  6. Double-click on the HTTP Endpoint to configure it. You will see the hostname. If you want to change the hostname, you can change it. In this example, we use localhost. If you want to change the port number, you can change that as well. By default, port number 8081 will be taken by the Mule server.

  7. Drag-and-drop the Java component from the palette onto the canvas area. In the Java component, we will store the custom Java class. Configure the Java component. In this example, we configure the Greeting class that we created before.

  8. Double-click on the Java component and configure it. Click on the Java icon and configure the Greeting class.

How it works...

In this section, you will see how to deploy the application and how it will run on the browser.

  1. If you haven't saved your application code, do save it. To deploy the application code in the Mule server, go to Run As | Mule Application; the Mule server will deploy your application.

  2. If your application code is successfully deployed, you will see the following output screen:

  3. Copy the URL http ://localhost:8081 and paste it on your browser.

  4. Paste the URL on your browser, and you will see the following output:


We have covered some core concepts and terminologies related to Mule ESB, and we have learned how to configure Mule elements and deploy applications on the Mule server.

Resources for Article :

Further resources on this subject:

You've been reading an excerpt of:

Mule ESB Cookbook

Explore Title