Petals Documentation > Petals ESB > Petals Components > Page Comparison - Petals-SE-EIP 2.11.0+ (v.5 vs v.6)

Petals-SE-EIP 2.11.0+

Version 5 by Christophe DENEUX
on Mar 23, 2020 11:36.
<< Changes from 4 to 5
compared with
Version 6 by Christophe DENEUX
on Mar 23, 2020 12:14.
Changes from 6 to 7 >>
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (135)

View Page History
...
h1. Service Configuration

h2. Service Unit descriptor
The EIP used as service provider implementation is defined and configured in the service unit descriptor.

{code:lang=xml}
<?xml version="1.0" encoding="UTF-8"?>
<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:sample="http://petals.ow2.org/sample">
<jbi:services binding-component="false">
<!-- The Provides -->
<jbi:provides interface-name="sample:interface" service-name="sample:service"
endpoint-name="endpoint">
<petalsCDK:wsdl xsi:nil="true" />
<eip:eip>pattern</eip:eip>
</jbi:provides>
<!-- The first Consumes -->
<jbi:consumes interface-name="sample:calledInterface1" service-name="sample:calledService1"
endpoint-name="calledEndpoint1">
<petalsCDK:mep xsi:nil="true" />
</jbi:consumes>
<!-- The second Consumes -->
<jbi:consumes interface-name="sample:calledInterface2" service-name="sample:calledService2"
endpoint-name="calledEndpoint2">
<petalsCDK:mep xsi:nil="true" />
</jbi:consumes>
</jbi:services>
</jbi:jbi>
{code}
{warning}One service provider per service unit !!{warning}

{include:0 CDK SU Provide Configuration 5.7.0}
\\
{include:0 JBI SU Consume Configuration}
\\
{include:0 CDK SU Interceptor configuration}
h2. Service unit descriptor

h3. Processing an integration pattern

Processing a pattern is providing a service that invokes 'sub-services', this service is called the 'original' service and its caller the 'original' consumer.

A Service unit contains:
A Service Unit contains * one and only one {{Provides}} section, which describes the pattern that will be processed when a request message is received.,
* one or more {{Consumes}} sections, which reference services to invoke during the pattern processing. The order of the {{consumes}} sections is important, as it is the order taken account when a pattern need 'sub-service' coordination.

The Service Unit contains also one or more {{Consumes}} sections, which reference services to invoke during the pattern processing. The order of the {{consumes}} sections is important, as it is the order taken account when a pattern need 'sub-service' coordination.

The number of {{consumes}} sections depends on the pattern implemented.

...
{note:title=Caution}Either an operation must be specified in the consumes sections or the 'original' operation is used for 'sub-service' requests.{note}

h3. Aggregator Pattern
This {{Provides}} section is configured through parameters divided in following groups:
* *JBI parameters* that defines the service provider identification,
* *CDK parameters* that are parameters driving the service provider implementation at CDK layer,
* *CDK interceptor parameters* that are parameters driving interceptors at CDK layer,
* *Dedicated parameters* that are parameters driving the service provider implementation at component layer.

*Enterprise Integration Pattern*
{center} !aggregator.gif!{center}
h3. CDK parameters defining service provider implementation
The following parameters correspond to the CDK configuration of the service provider implementation.

{center}{*}Configuration of a Service Unit to provide a service (Aggregator)*{center}
{include:0 CDK SU Provide Configuration 5.8.0}

h3. CDK parameters driving interceptors
The following parameters drive interceptors at CDK layer.

{include:0 CDK SU Interceptor configuration 5.8.0}

h3. Dedicated configuration
{table-plus}
|| Parameter || Description || Default || Required ||
| eip | The name of the EIP pattern to execute. See nested paragraph to get the values for each EIP patterns. | {center}\-{center} | {center}Yes{center} |
{table-plus}

Other dedicated parameters can exist according to the EIP pattern used. See nested paragraphs to get more information on each EIP patterns.

h4. Aggregator Pattern

|| Parameter || Description || Default ||
| eip | The name of the pattern to execute : {{aggregator}} | {center}\-{center} |
| test | XPath condition applied on the message to complete or not the sequence and invoke the 'sub-service' | {center}\-{center} |
| aggregator-correlation | XPath condition that is applied on the incoming message to correlate them together | {center}\-{center} |
{center}!aggregator.gif!{center}

{table-plus}
|| Parameter || Description || Default || Required ||
| eip | The name of the pattern to execute : {{aggregator}} | {center}\-{center} | {center}Yes{center} |
| test | XPath condition applied on the message to complete or not the sequence and invoke the 'sub-service' | {center}\-{center} | {center}Yes{center} |
| aggregator-correlation | XPath condition that is applied on the incoming message to correlate them together | {center}\-{center} | {center}Yes{center} |
\\ {table-plus}

The EIP Component receives 'original' exchanges and correlates their content amongst the aggregation configurations. The correlation is identified from the XPath expression specified in the SU parameter {{aggregator-correlation}}. If an 'original' exchange is on a {{InOut}} or {{InOptionalOut}} MEP, a standard response is sent back to the 'original' consumer :

...

An example of Service Unit configuration for the *aggregator* pattern :

{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<!-- JBI descriptor for the PEtALS component "EIP"-->
<jbi:jbi version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
...
{note:title=Caution}All MEPs are accepted for the 'original' consumer and the 'sub-service'{note}

h34. Scatter-Gather Pattern

*Enterprise Integration Pattern*
{center} !scattergather.gif!{center}
\\
{center}{*}Configuration of a Service Unit to provide a service (Scatter-Gather)*{center}
{table-plus}
|| Parameter || Description || Default || Required ||
| eip | The name of the pattern to execute : {{scatter-gather}} | {center}\-{center} | {center}Yes{center} |
| fault-robust | If true, a fault returned by a 'sub-service' exchange do not interrupt the process of the pattern | {center}false{center} | {center}No{center} |
| exception-robust | If true, an exception thrown by a 'sub-service' exchange do not interrupt the process of the pattern | {center}false{center} | {center}No{center} |
{table-plus}
\\
The EIP Component forwards the message to all the configured 'sub-service(s)'. The component waits for all the responses from these services, and aggregates them.
The aggregation is returned to the 'original' consumer in the following form :
...

An example of Service Unit configuration for the *scatter-gather* pattern :

{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<!-- JBI descriptor for the PEtALS component "EIP"-->
<jbi:jbi version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
...
{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}

h34. Routing-Slip Pattern

*Enterprise Integration Pattern*
{center} !routingslip.gif!{center}

{center}{*}Configuration of a Service Unit to provide a service (Routing Slip)*{center}

{table-plus}
|| Parameter || Description || Default || Required ||
| eip | The name of the pattern to execute : {{routing-slip}}. | {center}\-{center} | {center}Yes{center} |
| fault-to-exception | If true, a fault received from a 'sub-service' service is transformed to an exception into the 'original' exchange. | {center}false{center} | {center}No{center} |
{table-plus}
\\
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}} patterns) and no response are received ({{InOnly}}, {{RobustInOnly}} patterns), a default response is returned :
...

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

<!-- JBI descriptor for the PEtALS component "EIP"-->
<jbi:jbi version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
...
</jbi:consumes>
</jbi:services>
</jbi:jbi>{code}
\\ {code}

{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}All the MEP are accepted from the 'original' consumer.{note}

h34. Wire-Tap Pattern

*Enterprise Integration Pattern*
{center} !wiretap.gif!{center}

{center}{*}Configuration of a Service Unit to provide a service (Wire-Tap)*{center}
{table-plus}
|| Parameter || Description || Default || Required ||
| eip | The name of the pattern to execute {{wire-tap}} | {center}\-{center} | {center}Yes{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}} received) | {center}\-{center} | {center}Yes{center} |
{table-plus}
\\
The EIP component acts a proxy to a target 'sub-service'. It intercepts the {{IN}} or {{OUT/FAULT}} messages during the exchange and relays it to a observer 'sub-service'.
The SU parameter {{wiretap-way}} determines at which step of the MEP and which message is relayed to the observer 'sub-service'.
...

An example of Service Unit configuration to provide the *Wire-Tap* pattern :
{code:lang=xml}
{code:lang=xml}<?xml version="1.0" encoding="UTF-8"?>
<!-- JBI descriptor for the PEtALS component "EIP" -->
<jbi:jbi version="1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
...
        </jbi:consumes>
    </jbi:services>
</jbi:jbi>{code}
{code}

{note:title=Caution}{{{}Consumes}} sections cardinality is 2.{note}
...
{note:title=Caution}All the MEP are accepted from the 'original' consumer and the target 'sub-service'.{note}

h4. Splitter Pattern

h3. Splitter Pattern
{center}!splitter.gif!{center}

*Enterprise Integration Pattern*
{center} !splitter.gif!{center}

{center}{*}Configuration of a Service Unit to provide a service (Splitter)*{center}
{table-plus}
|| Parameter || Description || Default || Required ||
| eip | The name of the pattern to execute : {{splitter}} | {center}\-{center} | {center}Yes{center} |
| test | XPath condition applied on the message to split from the 'original' exchange | {center}\-{center} | {center}Yes{center} |
| attachment | true to split the attachments of the incoming 'original' exchange, false to split against the {{test}} XPath expression on the In 'original' message | {center}false{center} | {center}No{center} |
| fault-robust | If true, a fault returned by a 'sub-service' exchange do not interrupt the process of the pattern | {center}false{center} | {center}No{center} |
| exception-robust | If true, an exception thrown by a 'sub-service' exchange do not interrupt the process of the pattern | {center}false{center} | {center}No{center} |
{table-plus}
\\
For this pattern, the EIP Component splits the incoming 'original' message to multiple messages, then send them to the configured 'sub-service'.
If {{attachment}} parameter is not set, the {{IN}} message of the exchange is split against the Xpath expression specified in the parameter {{test}}.
...

The aggregation of the responses is returned to the 'original' consumer, in the following form :
{code:lang=xml}
{code:lang=xml}<result xmlns="http://petals.ow2.org/petals-se-eip/splitter">
...
</result>
...
{code:lang=xml}
<?xml version="1.0" encoding="UTF-8"?>

<!-- JBI descriptor for the PEtALS component "EIP" -->
<jbi:jbi version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
...
{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}

h34. Bridge Pattern

*Enterprise Integration Pattern*
{center} !bridge.gif!{center}

{center}{*}Configuration of a Service Unit to provide a service (Bridge)*{center}

{table-plus}
|| Parameter || Description || Default || Required ||
| eip | The name of the pattern to execute {{bridge}} | {center}\-{center} | {center}Yes{center} |
| fault-to-exception | If true, a fault received from a 'sub-service' service is transformed to an exception into the 'original' exchange. | {center}false{center} | {center}No{center} |
{table-plus}
\\
The EIP Component acts as exchange MEP bridge. For instance, it transforms an {{InOnly}} invocation into an {{InOut}} one. It is useful to correlate incompatible MEPs services.
Define in the {{Consumes}} section the 'sub-service' to invoke with its MEP, and the EIP component will match the incoming 'original' exchange against the outgoing exchange patterns as best as possible :
...

An example of Service Unit configuration for the *bridge* pattern :
{code:lang=xml}
{code:lang=xml}<?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"
...
 </jbi:consumes>
</jbi:services>
</jbi:jbi>{code}
{code}

{note:title=Caution}{{{}Consumes}} sections cardinality is 1.{note}

h34. Router Pattern

*Enterprise Integration Pattern*
{center} !router.gif!{center}

{center}{*}Configuration of a Service Unit to provide a service (Router)*{center}

{table-plus}
|| Parameter || Description || Default || Required ||
| eip | The name of the pattern to execute : {{router}} | {center}\-{center} | {center}Yes{center} |
| test\[\] | XPath condition(s) applied on the message to select the 'sub-service' | {center}\-{center} | {center}Yes{center} |
| test-operation\[\] | Operation condition(s) applied on the message to select the 'sub-service' | {center}\-{center} | {center}Yes{center} |
| fault-to-exception | If true, a fault received from a 'sub-service' service is transformed to an exception into the 'original' exchange. | {center}false{center} | {center}No{center} |
{table-plus}
\\
The EIP Component evaluates the list of conditions against the 'original' exchange.
Once a condition is matched, the message is forwarded to the 'sub-service' configured in the {{Consumes}} section at the same position than the condition.
...

An example of Service Unit configuration for the *Router* pattern :
{code:lang=xml}
{code:lang=xml}<?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"
...

<jbi:services binding-component="false">

<jbi:provides
interface-name="test:router"
...
</jbi:consumes>
</jbi:services>
</jbi:jbi>{code}
{code}

{note:title=Caution}{{{}Consumes}} sections cardinality is the number of defined conditions plus 1.{note}
{note:title=Caution}The last {{Consumes}} section is the default service to invoke if no condition has been matched.{note}

h34. Dynamic Router Pattern

*Enterprise Integration Pattern*
{center} !dynamicrouter.gif!{center}

{center}{*}Configuration of a Service Unit to provide a service (Dynamic-Router)*{center}
{table-plus}
|| Parameter || Description || Default || Required ||
| eip | The name of the pattern to execute : {{dynamic-router}} | {center}\-{center} | {center}Yes{center} |
| test\[\] | XPath condition(s) applied on the message to select the 'sub-service' | {center}\-{center} | {center}Yes{center} |
| fault-to-exception | If true, a fault received from a 'sub-service' service is transformed to an exception into the 'original' exchange. | {center}false{center} | {center}No{center} |
{table-plus}
\\
This pattern is similar than the Router pattern but do not process the conditions evaluations on the 'original' exchange, but on a response of a conditioning 'sub-service'.
So, first at all, the {{IN}} message of the 'original' consumer is sent to the conditioning 'sub-service', which is the first {{Consumes}} section defined.
...

An example of Service Unit configuration for the *dynamic-router* pattern :
{code:lang=xml}
{code:lang=xml}<?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:eip="http://petals.ow2.org/components/eip/version-2"
xmlns:test="http://petals.ow2.org/test">

<jbi:services binding-component="false">
<jbi:provides
...
{note:title=Caution}The last {{consumes}} section is the default service to invoke if no condition has been matched.{note}

h34. Dispatcher Pattern

*Enterprise Integration Pattern*
{center} !dispatcher.gif!{center}

{center}{*}Configuration of a Service Unit to provide a service (Dispatcher)*{center}

{table-plus}
|| Parameter || Description || Default || Required ||
| eip | The name of the pattern to execute : {{dispatcher}}. | {center}\-{center} | {center}Yes{center} |
{table-plus}
\\
The EIP Component dispatches the incoming {{IN}} message toward the configured 'sub-services' in {{Consumes}} sections. No response message is expected.

An example of Service Unit configuration for the *Dispatcher* pattern :
{code:lang=xml}
{code:lang=xml}<?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"
...
</jbi:jbi>
{code}

{note:title=Caution}{{{}Consumes}} sections cardinality is \[1-n\].{note}
{note:title=Caution}MEP of the 'original' exchange and the 'sub-services' must be {{InOnly}}.{note}

h3. Service unit content

The service unit has to contain the following elements, packaged in the archive:
* the META-INF/jbi.xml descriptor file as described above,
* it is also highly recommended to provide a WSDL description for service provider embedded in the service-unit.

{code}
service-unit.zip
+ META-INF
- jbi.xml (as defined above)
- service.wsdl (recommended)
{code}

h3. Example

An example of a Service Unit descriptor to provide an EIP service:
{code:lang=xml}
<?xml version="1.0" encoding="UTF-8"?>
<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:sample="http://petals.ow2.org/sample">
<jbi:services binding-component="false">

<!-- Service provider -->
<jbi:provides interface-name="sample:interface" service-name="sample:service"
endpoint-name="endpoint">
<petalsCDK:wsdl xsi:nil="true" />
<eip:eip>pattern</eip:eip>
</jbi:provides>

<!-- Service consumers -->
<jbi:consumes interface-name="sample:calledInterface1" service-name="sample:calledService1"
endpoint-name="calledEndpoint1">
<petalsCDK:mep xsi:nil="true" />
<!-- The second Consumes -->
<jbi:consumes interface-name="sample:calledInterface2" service-name="sample:calledService2"
endpoint-name="calledEndpoint2">
<petalsCDK:mep xsi:nil="true" />
</jbi:consumes>
</jbi:services>
</jbi:jbi>
{code}

h1. Component Extension

...