Endpoints - Wiring Everything Together

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

Addresses may be expressed as a Uniform Resource Identifier (URI) or as schema-specific XML configuration

For example, if a flow’s inbound endpoint’s address is http://myfirm.com/mule, the HTTP transport will dispatch to that flow any messages that have been sent to that URL. If the inbound endpoint specifies file://myserver/files/, the File transport, which is watching that directory, dispatches any new files created in that directory to the flow.

Depending on the messaging style you specify, Mule may or may not generate a response to send back through the inbound endpoint to the sender. Mule supports several Message Exchange Patterns and each transport has a default pattern it will follow unless you specify otherwise. Mule will typically return the final result of the message processing back as the result; however response processing can also be specified to control what is returned.

An outbound endpoint can also be specified to indicate where the message will go next. For example, after processing an HTTP request, you may want to place the result on a JMS queue.

A flow can receive messages using many different transports. For each type of transport that a flow will use, you must specify one or more separate endpoints. For example, if you want one of your flows to handle messages coming in on both the HTTP and JMS channels, you would specify at least one inbound HTTP endpoint and at least one inbound JMS endpoint. Mule registers these endpoints with the flow, and the transport uses this registry information at runtime to configure itself and determine where to send and receive messages.

Mule also supports dynamic endpoints, allowing the destination to be constructed from the content of the message. This allows routing-slip patterns where the message instructs Mule where to route it.

The flow can also include filters that further specify which messages to send or receive. For example, you can specify that the component only receives RSS messages by a specific author. Specifying filters, routers, and endpoints for your services simply requires editing an XML configuration. You do not have to write any Java code. Some routers are also dynamic and can change behavior based on the content of the message or an external data source such as a file or database. As stated previously, your 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 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 components and then change the way they behave through simple XML configuration instead of writing Java code.