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 buidling 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:
-
Component-centric Message Manipulation — use, or customize existing POJOs, Connectors, or Spring beans that contain the business logic to process or enrich messages.
-
Service Orchestration — configure endpoints, routers, transformers, and filters to orchestrate calls between Mule flows, each of which performs different processing tasks with the message.
-
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.