Mediation - Separating Business Logic from Messaging

One of the many advantages of Mule ESB is that it can handle messages that are sent via a variety of protocols. For example, an invoice might always be in XML format, but it might arrive over HTTP in one situation and as a JMS message in another depending on which application created the invoice. If a component handles only business logic and works with the data, not the message itself, how does it know how to read the various formats in which the message might arrive?

The answer is that components don’t know how to read the messages, because by default, components are completely shielded from the message format. Instead, a transport carries the message along, and transformers change the message’s payload (such as the invoice) as needed to a format the component can read before the flow passes the message to the component. For example, if an XML invoice is sent over HTTP, the HTTP transport turns it into a Mule message, transformers change it along the way (such as from XML to a Java object) as required, and the flow directs the message to each component that needs to process it. All the transporting, transforming, and routing of the message are completely transparent to the component. This decoupling is service mediation.

Transformers are the key to exchanging data, as they allow Mule to convert the data to a format that another component or application can understand. Most importantly, data is transformed only as needed. Instead of mandating the conversion of every message to a single common data protocol (like XML) and specific message format, messages and their data are transformed only as needed for the target component or application where the message is being sent. Mule also enables content enrichment of messages through integration patterns that allow you to retrieve additional data during processing and attach it to the message.

Multiple types of transports can be enabled to handle different channels, such as sending the message over a synchronous HTTP endpoint and then forwarding it as an asynchronous JMS message after it has been processed by the Customer Data component. This decoupling of the transport layer allow services to be reused across the enterprise regardless of the legacy technology decisions that were made and enable different choices in protocols to be made based on service level agreements or concerns around reliability or performance.

Mediation also means that policy compliance can be layered into the architecture outside of the services. Logging, auditing, and security monitoring can all be performed without any modification of the existing code. Policy enforcement can even be applied based on who is calling the service or what routing has occurred.

The separation of the business logic from the sending and transformation of messages allows for great flexibility in how you set up your architecture and makes it much simpler to customize the business logic without having to worry about the various formats in which a message might arrive. Your component can work with the raw data of the message if desired, but it is not required.