You are viewing an older version of this topic. To go to a different version, use the version menu at the upper-right. +

How Mule Works 

Basic Message Flow Architecture

The diagrams below illustrates a simple Mule flow as it appears in Studio — a message enter the flow at left, each building block processes the message one by one, then the message exits the flow at right.


We can examine the same flow within the context of Mule ESB’s architecture layers: application, integration, and transport. As the diagram below illustrates, Mule building blocks function on different abstraction layers within one flow.


Configuration in Mule ESB

There are three general types of flows in Mule applications:

  1. Component-centric Message Manipulation — use, or customize existing POJOs, Connectors, or Spring beans that contain the business logic to process or enrich messages.

  2. Service Orchestration — configure endpoints, routers, transformers, and filters to orchestrate calls between Mule flows, each of which performs different processing tasks with the message.

  3. Integration — use transports to “decouple” Web services from their underlying protocols and send or receive messages on different protocol connectors. Mule ESB supports many existing transports and popular communication protocols, but you may also develop a custom transport if you need to extend Mule to support a particular legacy or proprietary system.

Refer to Mule Application Architecture document for further details on how Mule works.