Mule architecture

This figure illustrates the main concepts of the Mule ESB that enable it to process incoming messages to the proper target applications.

The main concepts of the Mule architecture
Application
This identifies the application we’re integrating with. It can be anything -- an old legacy Cobol system, a .NET application, a J2EE application, or even another Mule instance.
Channel
A channel (an Enterprise Integration pattern) provides a way for external applications to communicate with Mule. Channels can also be used inside Mule to wire services together.
Message receiver
As the name implies, this component can receive information from a certain channel. Mule provides receivers for a lot of common standards and technologies.
Connector
A connector understands how to send and receive data from certain channels. As you can see in the previous figure, the connector is present both at the receiving and the sending ends. The message receiver and message dispatcher are part of the connector.
Transformer
We’ve already seen this component in chapter 1. A transformer transforms data from one format to another.
Inbound router
An inbound router determines what to do with a message once it’s received from a channel.
Component
The component is the logical place within the Mule architecture to implement
integration logic not provided by other Mule parts. A component can be implemented with a number of technologies: POJO, Groovy Script, REST service, and BPM, among others.
Outbound router
This is much the same as the inbound router, but this component determines where a message is sent to after it’s processed by the component.
Message dispatcher
This is the opposite of the message receiver. This component knows how to send information over a specific channel.