Database Reference
In-Depth Information
Before discussing the main Mediator Service Engine properties, it is important
to understand the execution behavior of Mediator routing rules.
Choosing among routing rules
Mediator executes routing rules either sequentially or in parallel. Even if a Me-
diator service is designed as a one-way service and a sequential routing rule is
used, it behaves similarly to a synchronous transaction (that is, the client holds
onto the request until the request is completed, and faults are propagated back
up to the client). Thus, despite their superior performance, sequential routing
rules should not be used for true asynchronous transactions.
On the other hand, by using parallel routing rules, services can be designed to
be truly asynchronous. However, the service engine executes these requests in
a rather unique fashion.
Let's say you have five Mediator services deployed to your SOA server and each
of these has a single parallel routing rule. Let's say that the average time it takes
to complete execution of each service is one second. If you receive 10 requests
on the first Mediator service and the Mediator Service Engine is configured with
10 threads, you would expect all requests to be completed within one second.
That is not the case.
The Mediator Service Engine loops through every composite, which has a paral-
lel routing rule every X seconds, where X is the
Parallel Locker Thread Sleep
setting. In our example, the service engine will loop through the five Mediator
composites, one at a time, and see if there are any requests to process from the
composite's internal queue. It processes only one request from that composite,
then moves on to the next composite. It finds no request, so it moves on to the
next, and the next, until it loops back to the first composite, where it would then
process its next request. The engine behaves this way by design in order to pre-
vent starving of threads caused by load on a single composite. What the engine
wants to avoid is that, if you have a Mediator service that has received hundreds
of thousands of requests and another one having received two requests, each
service is given a fair amount of time to be serviced, otherwise the two requests
may have to wait for hours to execute.
