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.
Performance
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 
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:
Summary
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:
I think your article is great in that one should take another look at why certain things are done and perhaps review patterns rather than following blindly. But I think the mediator is a useful little lightweight tool to have in our kits and here’s why-
If it’s all about pennies and cents:
*you can simply check the ‘validate schema’ checkbox and the Mediator will do schema validations for you and also pack the validation errors neatly into your custom fault as per your wsdl.
*One endpoint-multiple operations:The mediator allows you to ‘route’ straight-through versus BPEL where you would at least need an assign if not transformations (in addition to partnerlinks etc.)
The effort is actually not exactly comparable…
* For simple stateless services (such as most “Data services” as defined by the Oracle Reference architecture for SOA), you could simply have a mediator calling connectors and avoid BPEL altogether.
*About skill set: Most SOA Suite developers aren’t one-trick ponies, they often have to deal with disparate technologies and systems. A mediator is the least of their worries..
The above were just a few hands-on technical points i could think of. Now coming to “Software engineering”:
The Mediator is a lightweight service bus and is used for routing and mediation (now that we also have a more powerful OSB, the Mediator is fit for applying these patterns inside the composite services). BPEL is a “service orchestration” tool – has transactional and stateful capabilities. Earlier (and depending on budgets, it still is) it was also used for “Process orchestration” but for that, now we have a more business friendly BPMN engine.
We know there are many overlaps between different technologies but long-term practitioners can appreciate the place of different technologies and even complementary technologies from outside the Oracle FMW eco-system.
Hi Luc, Well Written and thanks for this. A few of my opinion below.
“◾It adds another ‘technology’ to your developer’s skillset”
A technology which a SOA suite developer wouldn’t mind to learn in ..say..half a day? Which will certainly come in handy looking at the bigger picture of overall integration.
◾It adds more tasks for system administration
System Admin tasks should NOT drive your composite design and it can always be automated.
◾It’s bad for performance
It’s something for Oracle to work on to improve the performance on transient mediator components. Also I thought Mediator wont use the dehydration store unless the rules are configured to be parallel routing.
Also in a multiple- multiple operation scenario (Medaitor – BPEL) there is always scope to introduce different flavours of BPEL’s for same operation and route it by specific rules from mediator. This gives a flexibility of patching a production Composite with a new BPEL only to cater to specific scenarios.
Otherwise I feel your statements are true 🙂
Hi Luc, thanks for your response. Justly my composite scenario is you described in the blog. A unique service with many operations. To achieve this, we need an initial BPEL component with a pick elemnt with several OnMessage activities. But the OnMessage element is an dehydratin point, and this make impossible to get that BPEL behave as Transient. Consequently, I think your article should clarify that it is not possible to avoid the use of mediator (for the performance purposes described in the article) for cases where we contract with many operations. While the article named something about it, but I think is not categorically established as an impediment.
Hey, what happened with my comments?
Hello, I have a question. How I can replace the mediator with a transient bpel if, in a POC I have receiving the follow error message: Activity create a dehydration point- process cannot be marked with in-memory optimization. There are other way to replace this mediator?
Hi Rodrigo,
I think that your BPEL process has a dehydration point, e.g. a timer? Or is it an a-synchronous BPEL process that you’re trying to run as transient?
When a BPEL process has a de-hydration point, you can’t run it transient.
Or you would have to use in-memory SOA: https://docs.oracle.com/middleware/1221/soasuite/develop/GUID-6B218606-0B51-4E3B-BF5E-FDC11E8EF2B5.htm#SOASE-GUID-382A688E-62BB-4C14-8618-A1CF1A53D23A