The argument is then made that ‘the Mediator hides changes in the BPEL process from the outside world’. Therefore, a BPEL process with a pick can’t be run transient! Thanks Rodrigo. NOTE: as pointed out by Rodrigo, this is the point to note that the pick (‘onMessage’) always is a dehydration point. But both components in the end will do what’s needed – with comparable effort. The Mediator with multiple operations looks like:Īnd a BPEL process with multiple operations looks like:īoth components, when making production quality code, will not show all you need in one window. Figure below shows a Mediator and BPEL component, each with 3 operations:
It is better to use the dms spy servlet for examining performance metricsĪn often heard argument is that ‘we need a Mediator because we need one single end-point with multiple operations’. SOAP UI statistics are no good when doing measurements in the msec area. Near empty dehydration store shows significantly better performance. Furthermore, while doing the measurements, I noted: In an environment where the performance demands are high, this can be an easy win. 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. A hello-world style composite with a Mediator and BPEL component:Ĭompared with a composite where the Mediator is replaced with a BPEL component that is run in-memory: In that set-up, two composites were compared for performance. … all running in that same VirtualBox machine. SOA Suite 12.2.1 running in VirtualBox machine. I did a performance test on the following configuration: That would save the DB access by the Mediator engine. That BPEL component can then be made transient, i.e. PerformanceĪt the beginning of the article, it was argued that a Mediator with synchronous operation(s) can be replaced with a BPEL component. 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. Like for the developer, the Mediator also introduces new topics for the system administrator: purging and tuning.īoth should not be a big issue, as enough information is available on how to handle them.
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? Even more, developers are often inclined to say ‘ah … not hard at all’. Learning all the aspects of BPEL is already a big task.
One external interface hides composite-internal changesĪs developer has to learn a lot when trying to master the SOA Suite completely. One end-point for a composite with multiple operations. It adds more tasks for system administration Īrguments in favor of using the Mediator:. It adds another ‘technology’ to your developer’s skillset. This article discusses some of the aspects around using a Mediator. Or replace it with a BPEL component that is run transient, i.e. I think that in most of these cases, it would be better to either leave out the Mediator component completely. I often see a pattern where a composite with a synchronous operation is implemented with a Mediator and BPEL component: But now that it’s in the open, let’s discuss it. Ok, so there you have it: I just don’t like the Mediator.
0 kommentar(er)
