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.
Some of the reasons to avoid a Mediator:
Arguments in favor of using the Mediator:
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.
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. Read the complete article here.
For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.