Wiring Everything Together

Endpoints are configuration elements that are the key to wiring together all the services. You specify endpoints in the inbound and outbound routers to tell Mule ESB which transport to use, where to send messages, and which messages a service component should receive. The primary part of an endpoint is the address, expressed as a Uniform Resource Identifier (URI), which indicates the transport to use, the location (a transport-specific resource), and any additional parameters.

For example, if a service's inbound router specifies the endpoint http://myfirm.com/mule, the HTTP transport will dispatch to that service any messages that have been sent to that URL. If the inbound router specifies file://myserver/files/, the File transport, which is watching that directory, dispatches any new files created in that directory to the service. The endpoint you specify on the outbound router indicates where the message will go next--it goes to the service with the same inbound endpoint as the previous component's outbound endpoint, as shown in the following illustration.
 
A service can receive messages using different transports. For each type of transport that a service will use, you must specify one or more separate endpoints. For example, if you want one of your services to handle messages coming in on both the HTTP and JMS channels, you would specify at least one HTTP endpoint and at least one JMS endpoint in the inbound router for that service. Mule registers these endpoints with the service, and the transport uses this registry information at runtime to configure itself and determine where to send and receive messages.

The router or endpoint can include filters that further specify which messages to send or receive. For example, you can specify that the service component only receives RSS messages by a specific author. Specifying routers and endpoints for your services simply requires editing an XML file. You do not have to write any Java code. As stated previously, your service components code remains completely separate from messaging and routing, which you handle through Mule configuration.

In summary, Mule provides a simple and lightweight way to write service components that do something to data without needing to worry about the sender or recipient of the data, the format of the data, or the technology being used to send/receive the data. Although many brokering and integration technologies offer the ability to connect to disparate data sources, they often require extra coding to get messages to behave the way you want and to deliver the data where you want it to go. Mule allows you to quickly develop service components and then change the way they behave through simple XML configuration instead of writing Java code.

The next section, Understanding the Logical Data Flow, provides a detailed example of how a message flows through all the parts in the Mule implementation.