Petals-SE-EIP

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

Changes (16)

View Page History

*Configuration of a Service Unit to provide a service (EIP)*
{table-plus}
|| Parameter || Description \\ || Default \\ || Required by pattern \\ ||
| eip | The name of the pattern to execute : {{routing-slip}}. \\ | \- | all |
routing-slip \\
dispatcher |
{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 : 

*Configuration of a Service Unit to provide a service (EIP)*
{table-plus}
|| Parameter || Description \\ || Default \\ || Required by pattern \\ ||
| eip | The name of the pattern to execute : {{wire-tap}} \\ | \- | All |
| 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) \\ | \- | wire-tap |
{table-plus}
\\
The EIP Component copy the IN or 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.

*Configuration of a Service Unit to provide a service (EIP)*
{table-plus}
|| Parameter \\ || Description \\ || Default \\ || ||
| eip \\ | The name of the pattern to execute : {{splitter}} \\ | \- | All |
| test \\ | XPath condition applied on the message to split the source exchange \\ | \- | aggregator\\
splitter
router
dynamic-router
aggregator\\
splitter\\
router\\
dynamic-router | dynamic-router\\
| attachment\\ | | false | splitter |
| fault-robust\\ | | false | scatter-gather\\
aggregator \\
splitter \\
router \\
dynamic-router |
| attachment \\ | true to split the source exchange on the attachments, false to split it on the IN content | false | splitter |
| fault-robust \\ | If true, a fault thrown by a target exchange don't stop the process and don't change the original exchange status to FAULT | false | scatter-gather \\
splitter |
| exception-robust\\ | | false | scatter |
| exception-robust \\ | If true, an exception thrown by a target exchange don't stop the process and don't change the original exchange status to ERROR | false | scatter |
{table-plus}



h3. Bridge Pattern