WebSphere ESB includes two distinct technologies, both of which use the name ‘mediation’:
Mediation flows, the primary facility introduced by WebSphere ESB V6.0.1 itself.
Let’s come straight out and say it: yes, this can be a little confusing, given that these two technologies go by similar names. Nevertheless, although both of them can both be used to alter messages on the Platform Messaging bus, they work in quite different ways.
Platform Messaging mediations are specified as a sequential list of ‘mediation handlers’, administratively attached to a destination such as a queue or a topic space. These mediation handlers are programmatic: they are an implementation of the MediationHandler interface. This allows a message to be altered ‘in-place’: the fundamental properties of the message, such as the message ID, are not changed, because it is logically the same message. These mediations can also be used to destroy the message, or route it elsewhere. For more information, see Dan Murphy’s article in the IBM WebSphere Developer Technical Journal.
WebSphere ESB mediation flows, on the other hand, do not have to be a simple sequential list of steps. They are a network of mediations (in the ESB sense of the word). These mediations are generally re-usable components designed to modify a message in a certain way or make some decision based upon its contents (ESB ships with several out-of-the-box). The flows can have several potential paths from start to finish. Generally, when dealing with Platform Messaging messages, JMS exports and imports will be used to bring a message into the flow and output it from the flow. This means that a message will be destroyed when it is brought into the flow, and re-created from scratch when output - it is not the same message. This is partly because ESB mediation flows can also have other types of import and export, such as those which support web services. When a message is travelling through the flow, it is actually represented as a Service Message Object.
These two technologies are therefore quite different. In general, you would use a Platform Messaging mediation when you want mediation to be transparent to an already-existant application (mediation happens after a message is put to a destination but before it is recieved). ESB mediation flows offer a richer and easier-to-use set of functionality when that’s necessary, but don’t preserve message transparency. They also provide the facility to integrate with web services and other data sources.