I don’t like the Mediator mediator

I don’t like the Mediator

Ok, so there you have it: I just don’t like the Mediator. I don’t really know why. But now that it’s in the open, let’s discuss it.

I often see a pattern where a composite with a synchronous operation is implemented with a Mediator and BPEL component:


I think that in most of these cases, it would be better to either leave out the Mediator component completely. Or replace it with a BPEL component that is run transient, i.e. in-memory.

This article discusses some of the aspects around using a Mediator.

We need to discuss…

Some of the reasons to avoid a Mediator:

  • It adds another ‘technology’ to your developer’s skillset
  • It adds more tasks for system administration
  • It’s bad for performance

Arguments in favor of using the Mediator:

  • One end-point for a composite with multiple operations
  • One external interface hides composite-internal changes

Let’s go.

Yet another developer skill

As developer has to learn a lot when trying to master the SOA Suite completely. Learning all the aspects of BPEL is already a big task. And the Mediator is yet another skill. Arguably, not a big skill. Even more, developers are often inclined to say ‘ah … not hard at all’. But … are you as a developer familiar with all the features of Mediators? Like the resequencing rules? The routing rules priorities? When to specify sequential and parallel execution?

I like simple things.

More tasks for system administration

Like for the developer, the Mediator also introduces new topics for the system administrator: purging and tuning.

Both should not be a big issue, as enough information is available on how to handle them . But … does your system administrator know that there is a Mediator engine that needs to be tuned? Just challenge your system administrators to have a look at  Mediator tuning and ask them how they handled it.


At the beginning of the article, it was argued that a Mediator with synchronous operation(s) can be replaced with a BPEL component. That BPEL component can then be made transient, i.e. it will run in memory. That would save the DB access by the Mediator engine.

I did a performance test on the following configuration:

  • laptop with core i7 cpu
  • SOA Suite 12.2.1 running in VirtualBox machine
  • Compact domain configuration, i.e. one Admin Server only
  • Oracle XE 11g as dehydration store
  • Memory 10GB, 4 CPU cores (out of 8)
  • Test tool SOAP UI
  • … all running in that same VirtualBox machine

In that set-up, two composites were compared for performance. A hello-world style composite with a Mediator and BPEL component:


Compared with a composite where the Mediator is replaced with a BPEL component that is run in-memory:


No, this is NOT a good set-up for getting really meaningful results, but nevertheless Winking smile It was noted that replacing the Mediator shaved about 10 msec off the round-trip time. In an environment where the performance demands are high, this can be an easy win. Furthermore, while doing the measurements, I noted:

  • Near empty dehydration store shows significantly better performance
  • SOAP UI statistics are no good when doing measurements in the msec area
  • It is better to use the dms spy servlet for examining performance metrics

One end-point, multiple operations

An often heard argument is that ‘we need a Mediator because we need one single end-point with multiple operations’. Figure below shows a Mediator and BPEL component, each with 3 operations:


The Mediator with multiple operations looks like:


And a BPEL process with multiple operations looks like:


Both components, when making production quality code, will not show all you need in one window. But both components in the end will do what’s needed – with comparable effort.

NOTE: as pointed out by Rodrigo, this is the point to note that the pick (‘onMessage’) always is a dehydration point. Therefore, a BPEL process with a pick can’t be run transient! Thanks Rodrigo.

Hide internal changes

Often, the pattern below is used:


The argument is then made that ‘the Mediator hides changes in the BPEL process from the outside world’. My argument is that:

  • one may end up with a very large number of mediators
  • BPEL changes where the process WSDL is affected, will occur rarely
  • the type of changes could also be absorbed in one single BPEL component

Hence, my proposal:



I have given the use of Mediators some thoughts, and … so should you. Don’t just put a Mediator as a starting point in all of your composites, just because you think that it’s a best practice. You may end up with more work and complexity in your solution – without having real benefits.

  • High-performance requirements can be a reason to leave out a Mediator
  • Developer and system admin skills may be a reason not to use Mediators
  • A single endpoint for multiple operations may be a reason to use Mediators
  • … whereas hiding internal changes from the external world may not be a very good reason to use a Mediator

But all-in-all, I must admit that I really do like the color of the Mediator. It’s really nice. Really, it is.

And now, off to the more important things of the holiday season:



  1. Jang-Vijay Singh September 30, 2016
  2. Prakash September 21, 2016
  3. Rodrigo February 2, 2016
  4. Rodrigo February 1, 2016
  5. Rodrigo February 1, 2016