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
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 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: