Petals-SE-EIP 2.5

compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (28)

View Page History
{table-plus}


|| Parameter || Description || Default ||
| eip | The name of the pattern to execute : {{aggregator}} | {center}\-{center} |

{note:title=Caution}Message order is kept from incoming sequence to the outgoing message.{note}
{note:title=Caution}{{{}Consumes}} sections cardinality is [1-1|1-1].{note}
{note:title=Caution}All Message Exchange Patterns are accepted for the 'original' consumer{note}

{center}{*}Configuration of a Service Unit to provide a service (Scatter-Gather)*{center}
{table-plus}

|| Parameter || Description || Default ||
| eip | The name of the pattern to execute : {{scatter-gather}} | {center}\-{center} |
| fault-robust | If true, a fault returned by a 'sub-service' exchange do not interrupt the process of the pattern | {center}false{center} |
| error-robust | If true, an exception thrown by a 'sub-service' exchange xchange do not interrupt the process of the pattern | {center}false{center} |
{table-plus}
\\
{code}

{note:title=Caution}{{{}Consumes}} sections cardinality is [1-n|1-n].{note}
{note:title=Caution}Message exchange pattern accepted from the 'original' consumer is {{InOut}}.{note}
{note:title=Caution}By default, the process stops when a Fault is returned by a 'sub-service'. To continue the process even if a fault is thrown, returned, set the {{fault-robust}} parameter to {{TRUE}}. The fault is concatenated with the other results.{note}
{note:title=Caution}By default, the process stops when an Exception is returned by a 'sub-service'. To continue the process even if an exception is thrown, set the {{exception-robust}} to {{TRUE}}. The exception is concatenated with the others results.{note}


{table-plus}

|| Parameter || Description || Default ||
| eip | The name of the pattern to execute : {{routing-slip}}. | {center}\-{center} |
| fault-to-exception | If true, a fault received from the target a 'sub-service' service is transformed to an exception into the source 'original' exchange. | {center}false{center} |
{table-plus}
\\
The EIP Component chains invocation of the referenced services in the {{consumes}} sections, in the order that they are declared. The IN message of the incoming exchange is sent to the first service; the OUT response of this service is sent to the second service as an IN message, and so on. The last target exchange is matched with the source exchange as better as possible. So : 
The EIP Component chains invocation of the 'sub-services', in the order that they are declared. The {{IN}} message of the incoming exchange is sent to the first 'sub-service', the {{OUT}} response of this service is sent to the second 'sub-service' as a {{IN}} message, and so on. The last exchange is matched with the 'original' exchange as better as possible:
* If the source exchange needs a response (InOut or InOptionalOut ({{InOut}} patterns) and no response are received (InOnly, RobustInOnly or InOptionalOut ({{InOnly}}, {{RobustInOnly}} patterns), a default response is returned :
{code:lang=xml}<result xmlns="http://petals.ow2.org/petals-se-eip/bridge">
Bridge: no content into the final target exchange
</result>{code}
* If the source exchange doesn't accept a response (InOnly or RobustInOnly patterns) and a response is received (InOut or InOptionalOut patterns), the response is ignored.
* If the source exchange doesn't accept a fault (InOnly pattern) and a fault is received (RobustInOnly, InOut or InOptionalOut patterns), the fault is ignored.
* If the 'original' exchange do not accept a response ({{InOnly}} or {{RobustInOnly}} patterns) and a response is received ({{InOut}} or {{InOptionalOut patterns), the response is ignored.
* If the 'original' exchange do not accept a fault ({{InOnly}} pattern) and a fault is received ({{RobustInOnly}}, {{InOut}} or {{InOptionalOut}} patterns), the fault is ignored.

An example of service unit configuration :
An example of service unit configuration for the *Routing-Slip* pattern:
{code:lang=xml}<?xml version="1.0" encoding="UTF-8"?>

</jbi:jbi>{code}
\\
{note:title=Caution}{{{}consumes}} sections cardinality is [1-n|1-n]
{note}
{note:title=Caution}by default, the {{process}} stops when a Fault is returned by the provider if it doesn't use the InOnly Message Exchange Pattern{note}
{note:title=Caution}by default, the process stops when an Exception is returned by the provider{note}
{note:title=Caution}message exchange pattern of all the target exchanges, except the last, is {{InOut{}}}{note}
{note:title=Caution}all the Message Exchange Pattern are accepted for the source exchange{note}
{note:title=Caution}{{Consumes}} sections cardinality is [1-n]{note}
{note:title=Caution}By default, the process stops when a Fault is returned or an exception is raised by a 'sub-service'{note}
{note:title=Caution}MEP of all the 'sub-services' must be set to {{InOut}}, except the last one which can be accorded to the 'original' MEP{note}
{note:title=Caution}All the MEP are accepted from the 'original' consumer{note}

h3. Wire-Tap Pattern
{center} !wiretap.gif!{center}

{center}{*}Configuration {center}*Configuration of a Service Unit to provide a service (EIP)*{center} (Wire-Tap)*{center}
{table-plus}






|| Parameter || Description || Default ||
| eip | The name of the pattern to execute {{wire-tap}} | {center}\-{center} |
| wiretap-way | Exchange way on which the message should be copied and sent to the monitoring service. \\
Values are request (copy IN), response (copy OUT/Fault), {{request-response}} (copy IN and OUT/Fault), {{request-on-response}} (copy IN after OUT is received; not copied if Fault or Error) | {center}\-{center} |
| wiretap-way | Specify the step of a MEP on which the message should be copied and sent to the 'sub-service'. \\
Values can be {{request}} (copy {{IN}}), {{response}} (copy {{OUT}}/{{FAULT}}), {{request-response}} (copy {{IN}} and {{OUT}}/{{FAULT}}), {{request-on-response}} (copy {{IN}} after {{OUT}} is received; no copy if {{FAULT}}) | {center}\-{center} |
{table-plus}
\\
The EIP Component copy the {{IN}} or OUT/Fault {{OUT/FAULT}} message of the exchange between the consumer and the provider of the functional service to a 'monitoring' service. The SU parameter wiretap-way determines which way of the invocation is relayed to the 'monitoring' service. At each way correspond a message of the exchange to copy. The copied message is sent to the 'monitoring' service as an IN message using the InOnly exchange pattern. The first consumes section references the provider, the second one references the 'monitoring' service.

An example of service unit configuration :



|| Parameter || Description || Default ||
| eip | The name of the pattern to execute : {{splitter}} | {center}\-{center} |



|| Parameter || Description || Default ||
| eip | The name of the pattern to execute {{bridge}} | {center}\-{center} |



|| Parameter || Description || Default ||
| eip | The name of the pattern to execute : {{router}} | {center}\-{center} |



|| Parameter || Description || Default ||
| eip | The name of the pattern to execute : {{dynamic-router}} | {center}\-{center} |



|| Parameter || Description || Default ||
| eip | The name of the pattern to execute : {{dispatcher}}. | {center}\-{center} |



|| Parameter || Description || Default || Required ||
| your-pattern-name | Name of the java class implementing your pattern. The name of the pattern at runtime will be the one you give as parameter name | {center}\-{center} | {center}No{center} |