Free MuleSoft CONNECT Keynote & Expo Pass Available!

Register now+

Learning the Module Model

The entry point for building a Mule module is the @Extension annotated class. This class is used to export all the module functionality and all the elements associated with it.

This class must be a public, non-abstract class. The @Extension annotation cannot be used on interfaces, abstract classes, private/protected classes, or typed classes (with generics).

@Extension(name = "basic")
public class BasicModule {

When using the @Extension annotation, you need to provide a descriptive and concise name for your module. You should not use extension, module, or connector in the module name. If you do, the SDK will trim them. Optionally, you can specify the module vendor and the module category (See Licensing).

Once you have created an empty module, you can start adding elements to it.

Module Basic Model Diagram
Figure 1. Basic Module Structure

At a high level, the elements are:


Components are the key to the functionality of a module. Given a set of parameters, they can be executed to produce or alter messages in a flow.

Sources and Operations are the most common components in a module:

  • Operations are components that process an incoming message and generate a result.

  • Sources are components that receive or generate new messages to be processed by the Mule Runtime.


Configurations are a set of configurable parameters that affect the behavior of the Module. Sources and Operations typically depend on a Configuration for parameters that determine their behavior. However, some can work on their own without a Configuration.

There is no requirement to declare a Configuration for a Module, but you can declare as many as you need. Different configurations might provide a different set of parameters and specify a set of Operations and Sources that are only available when using that configuration.

Connection Providers

A Connection Provider is the Module element in charge of handling connections, which are created from a Configuration. They centralize the logic and parameterization to provision and release connections of some specific type.

Like the Configurations, Sources, and Operations, Connection Providers typically depend on a connection in order to be executed. A connection is not required but is common. Connections used by Operations and Sources are provided by the Connection Provider.

Connection Providers are bound to Configurations. Configurations can have none, one, or many Connection Providers that create different types of connections, for example, one ConnectionProvider for HTTPS and another for (non-secured) HTTP connections.


Parameters are the most granular elements on the module model, and they are used in all these elements: Operations, Sources, Configurations, and Connection Providers.

They represent configurable elements that accept the values for elements to execute, or they hold the configured values.

Other Elements

A module can have other element types, for example, Routers, Scopes, Functions, or Errors. The ones described here are the core elements that most modules are likely have.