At the most basic level, Mule is a distributable object broker called the Container or Mule Model. The Container manages operational objects, or Universal Message Objects TM. These guys, UMOs for short, are simple Java objects that communicate between themselves and external applications. The communication points are called "Endpoints".
The diagram below shows a simplified breakdown of the Mule Server components.
The Mule Manager is central to a Mule server instance (also known as a Node or Mule Node). Its primary role is to manage the various objects such as connectors, endpoints and transformers for a Mule instance. These objects are then used to control message flow to and from your services/components and provide services to the Model and the components it manages.
The model is the container in which your components are managed and executed. It controls message flow to and from your components, manages threading, lifecycle and pooling. The default MuleModel is SEDA-based meaning it uses an efficient event-based queuing model to maximize performance and throughput.
The container provides a range of services for UMO components such as transaction management, transformation of events, routing, event correlation, logging, auditing and management. Mule separates object construction from management meaning that popular IoC/DI containers such as Spring, PicoContainer or Plexus can be used to construct your UMO components.
UMO stands for Universal Message Object TM; an object that can receive and send events from anywhere. UMO Components are your business objects. These are components that execute business logic on an incoming event. These components are standard JavaBeans, there is no Mule-specific code in your components. Mule handles all routing and transformation of events to and from your objects based on the configuration of your component
Endpoints are fundamental to Mule's communication capabilities. An Endpoint defines a communication channel between two or more components, applications or repositories. They provide a powerful way of allowing your objects to talk over any protocol in a unified way. An endpoint can be configured with message filters, security interceptors and transaction information to control who, what and how messages are received or sent via the endpoint. For more information see Mule Endpoints.
External applications can be anything from application servers to legacy payroll systems, to mainframe trading applications or a client application. Basically, any application that has a way of serving or consuming data. As Mule performs all communication via endpoints, UMO components have no notion of what application produced the data, where the application is located nor the transport protocol used.
The terminology used within Mule might be a bit confusing, but it breaks down pretty simply.
|Transport||A transport or "provider", is a set of objects that add support to Mule to handle a specific kind of transport or protocol. For example, the "Email Provider" enables Mule to send and receive messages via the SMTP, POP and IMAP protocols.|
|Connector||A connector is the object that sends and receives messages on behalf of an endpoint. Connectors are bundled as part of specific transports or providers. For example, the FileConnector can read and write file system files.|
|Router||A router is the object that do something with messages once they have been received by a connector, or prior to being sent out by the connector.|
|Filter||A filter optionally filters incoming or outgoing messages that are coming into or going out from a connector. For example, the File Provider comes with a FilenameWildcardFilter that restricts which files are read by the connector based on file name patterns. Filters are used in conjunction with Routers.|
|Transformer||A transformer optionally changes incoming or outgoing messages in some way. For example, the ByteArrayToString transformer converts byte arrays into String objects.||