Mediator vs. Adapter

I've been a part of several separate conversations about how applications communicate. As a result, I've been thinking in more detail about the difference between Mediators and Adapters. (These discussions also lead to Message Channel Revisited.)

What is an Adapter?

An Adapter (the Channel Adapter pattern from Enterprise Integration Patterns) connects an application to a Message Channel (or, really, any kind of Channel, Message or otherwise) in a messaging system or ESB. It does whatever is necessary to adapt the application to messaging, which can be quite a lot if the application wasn't designed for messaging.

IBM has a set of Adapter products, the WebSphere Adapters. By this definition, messaging API classes like javax.jms.MessageProducer and javax.jms.MessageConsumer can be considered very simple Adapters.

For example, an HTTP-to-JMS adapter connects an HTTP channel to a request/reply pair of JMS channels. An incoming HTTP message gets converted to a JMS message and vise versa.

What is a Mediator?

A Mediator connects one or more input channels to one or more output channels. The mediator consumes one or more input messages, processes them, and then produces one or more output messages. This enables applications with different integration APIs to still be integrated; the Mediators bridge the differences.

A Mediator can be a Message Router, a Message Translator, and/or a transport (aka protocol) converter. For example, an XSL translator consumes an XML message with one schema and produces another message with a different XML schema.

The Difference

The difference between a Mediator and an Adapter is this: An Adapter lives on the edge of the messaging system/bus/integration solution, half inside the solution and half inside the application, whereas a Mediator lives inside the integration solution. The application invokes the Adapter's API (half of it, anyway) whereas the applications never see the Mediators.

Part of what's confusing is that often the same behavior can be implemented in an Adapter or a Mediator. Consider an XSL translation: It can be implemented in an Adapter because the application uses one schema and the channel uses another. Or it can be implemented in a Mediator because the first channel uses the same schema as the application but the second channel uses another.

The behavior is the same, the XSLT code is the same, but the benefits are different. When behavior is implemented as a Mediator, it can be reused by any application that puts messages on the input channel(s). When the same behavior is implemented in an Adapter, only the applications that use the Adapter get the behavior, which is usually just one application (actually, one part of an application, such as a component or a thread) per instance of an adapter.

Another issue is where the behavior runs at runtime. A Mediator runs in the messaging system/bus/integration solution and therefore creates load there. An Adapter may run in the integration solution, in the application, or in a third process. This has implications for distributing load, monitoring performance, and so on.

Conclusions

When mediation behavior is being performed inside a bus, call it a Mediator. When the same behavior is being performed in the connection between an application and the bus, call it an Adapter.