Petals SE EIP

Run a petals container, place yourself at petalslink/integration/petals-integration/tests/petals-se-eip and
after that execute the followinf maven command in order to run EIP tests:

mvn antrun:run -Dpetals.integration.command=all

The test 8 invokes the dispatcher that forwards the request to SE RMI 2 and SE RMI 3. SE RMI 2 returns a DONE status and SE RMI 3 returns a fault.
I think that the problem is linked to:

• the expected replies order. SE RMI 2 is wait before SE RMI 3. But as the dispatcher is asynchronous the replies are received without order,
• the dispatcher returns only a message based on the last received reply: functions are missing at the dispatcher level to define which reply must be returned according received replies.

To fix the problem:

• add a new tag in integration test to define a sleep period before to send the reply at provider level (so the received replies order can be defined)
• improve the dispatcher against reply to return according received replies
• add integration tests about dispatcher enhancement.

Patch to add a tag to wait before seding a reply at the provider level of the RMIClient

I think this scenario may prove to obtain a new update:

One a way to specify a advanced behavior (a kind of extension) of a pattern.

For example the previous problem was the "Dispatcher" is not supposed to aggregate the answers returned by several "Performers".

Shouldn't we provide a mechanism allowing by one parameter to force the aggregation of responses?

The mechanism would be possible in each pattern to specify a palliative solution

for example take a look for the following jbi Dispatcher descriptor:

<?xml version="1.0"?>

<!-- JBI descriptor for the PEtALS component "EIP" -->
<jbi:jbi version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jbi="http://java.sun.com/xml/ns/jbi"
xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
xmlns:eip="http://petals.ow2.org/components/eip/version-2"
xmlns:test="http://petals.ow2.org/test">

<jbi:services binding-component="false">
<jbi:provides
interface-name="test:dispatcher"
service-name="test:dispatcherService1"
endpoint-name="dispatcherService1Endpoint">
<petalsCDK:wsdl xsi:nil="true" />
<eip:eip>dispatcher</eip:eip>
<eip:extendedBehavior>enforceAggregatingResponses</eip:extendedBehavior>
</jbi:provides>

<jbi:consumes
interface-name="test:dispatcherProvider"
service-name="test:dispatcherProviderService1"
endpoint-name="dispatcherProviderService1Endpoint">
<petalsCDK:mep>InOnly</petalsCDK:mep>
<petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
</jbi:consumes>

<jbi:consumes
interface-name="test:dispatcherProvider"
service-name="test:dispatcherProviderService2"
endpoint-name="dispatcherProviderService2Endpoint">
<petalsCDK:mep>InOnly</petalsCDK:mep>
<petalsCDK:operation xmlns:petals="http://org.ow2.petals">petals:operation</petalsCDK:operation>
</jbi:consumes>
</jbi:services>
</jbi:jbi>

Today, the dispatcher closes its incoming exchange on the first outgoing dispatched exchange closed. That has no sens. The incoming exchange should be closed by the pattern itself after to have forwarded the request. Or, as mentionned by adrien, the incoming exchange should be closed aggregating all responses

Hum ... I'm not sure that Dispatcher pattern must aggregates all response results (in specificationj dispatcher pattern), I'll watch it tonight. But just for information I think the Resequencer pattern mechanism can be a good track

I looked at home last night and I found we can certainly aggregate performers returns with Transaction aspect, because transaction is a part of Dispatcher specification, but isn't really recommended