You are viewing an older version of this section. Click here to navigate to the latest version.

Components - Processing the Data

When a message is sent from an application (such as the invoice from an order entry system), Mule ESB picks up the message, sends it to a service that processes it using some specific business logic (such as checking the customer and inventory databases), and then routes it to the correct application (such as the order fulfillment system). Mule contains many individual parts that handle the processing and routing of the message. One key part is the component. Components execute business logic on messages, such as reading the invoice object, adding information to it from the customer database, and then forwarding it to the order fulfillment application.


An important feature of components is that they don’t have to have any Mule-specific code; they can simply be POJOs, Spring beans, Java beans, Groovy scripts, or web services containing the business logic for processing data in a specific way. Mule even supports a powerful type of component called a [Cloud Connector] that can connect to any cloud-based service or application and process or enrich the message. Cloud connectors operate on Application APIs, typically exposed over web services.

Mule manages components for you, bundles them with configuration settings, exposes them as message processors, and ensures that the right information is passed to and from them based on the settings you specified for their flows in the Mule configuration file.

Mule supports chaining multiple processing steps together through an orchestration mechanism called [flow]. Flows allow any number of components to be chained together along with other forms of message processing. Flows allow Mule to orchestrate how and when a message is routed to a component. Components can also be exposed directly as services using the Simple Service pattern or the Service Model.

You can have many different components that perform different business logic, such as one that verifies whether the items on the invoice are in stock and one that updates a separate customer database with the order history. The invoice, which is encapsulated in a message, can flow from one service component to the next until all the required processing is complete.