E-mail
|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (23)
View Page History
...
{section} {column}
{multi-excerpt-include:Petals-SE-Camel\|name=features\|nopanel=true}
{multi-excerpt-include:Petals-SE-Camel|name=features|nopanel=true}
{column}
{column:width=40%}
{panel:title=Table of contents}{toc:outline=true}{panel}
{column:width=40%}
{panel:title=Table of contents}{toc:outline=true}{panel}
{panel:title=Contributors}{contributors:order=name\|mode=list\|showAnonymous=true\|showCount=true\|showLastTime=true}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list|showAnonymous=true|showCount=true|showLastTime=true}{panel}
{column}
{section}
{section}
...h1. Introduction
This implementation of the SE Camel uses Camel version 2.15.0.
This implementation of the SE Camel uses Camel version 2.12.3, the latest compatible version with Java 1.6.
{info}
The next version, 1.0.0-SNAPSHOT, will use the latest version of Camel (presently 2.15.x).
{info}
The next version, 1.0.0-SNAPSHOT, will use the latest version of Camel (presently 2.15.x).
{info}
Routes can be defined using any of the JVM based DSL, as well as using the XML notation.
A Camel route always starts with a *from* declaration, a consumer, and often ends with one or many *to* declaration, producers.
A Camel route always starts with a *from* declaration, a consumer, and often ends with one or many *to* declaration, producers.
...Each SU has its own Camel context: the Camel context is the runtime entity responsible of executing the routes.
Routes in the same context can refer to each others when needed (see the section [Camel Routes|#camel-routes] below).
When a JBI exchange arrives on for a provided service (an operation), it is transformed to a Camel exchange and dispatched to the route with a petals consumer (in the Camel terminology, i.e. with a *from* declaration using the *petals* URI scheme) the service.
When a Camel exchange is dispatched in a route to a petals producer (in the Camel terminology, i.e. with a *to* declaration using the *petals* URI scheme), it is transformed to a Petals exchange and sent to the corresponding consumes service.
... <groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
<artifactId>camel-core</artifactId>
<version>2.15.0</version> <version>2.12.3</version>
<!-- camel-core is provided by the component! -->
<scope>provided</scope>
</dependency>
</dependency>
<!-- Maybe other dependencies if you relies on other camel extensions (for xml and java routes) --> routes).
Note: these extensions are NOT provided by the component and must thus be present with the (default) scope compile. -->
</dependencies>
...Note: by default, it will use the value specified in the JBI consumes section and as usual, the value *0* means no timeout.
{anchor:camel-routes} {anchor:transformations}
h1. Camel Routes
h1. Petals to Camel to Petals
{color:red}{*}TODO. Add some explanation on how to use direct: and seda: URIs from Camel to call local routes, how to marshal and unmarshal, how to convert bodies, etc{*}{color}
Petals (i.e. JBI) and Camel share many concepts to format exchanges.
They both have exchanges with a WSDL MEP, In, Out and Fault messages, as well as Errors.
The main difference is that Camel exchanges do not make mandatory the use of XML for the messages content and that they have no explicit status (the status of Camel exchange is inferred from their content).
They both have exchanges with a WSDL MEP, In, Out and Fault messages, as well as Errors.
The main difference is that Camel exchanges do not make mandatory the use of XML for the messages content and that they have no explicit status (the status of Camel exchange is inferred from their content).
{anchor:transformations}
h1. Petals to Camel to Petals
h2. From Petals to Camel
{color:red}{*}TODO. Explains how Petals and Camel exchanges are transformed to each others{*}{color}
{color:red}{*}TODO. Explains problem with InOptionalOut{*}{color}
{color:red}{*}TODO. Explains problem with InOptionalOut{*}{color}
When a new exchange arrives on a provides endpoint, the following happen:
The JBI exchange is transformed to a Camel exchange.
Its properties are put into the Camel exchange properties (by reference).
Its In normalized message is transformed to a Camel message.
Its properties are put into the Camel message headers (by reference).
Its attachments are put into the Camel message attachments (by reference).
The content of the normalized message (a Source object in Java, containing XML) is put in the body of the Camel message without change.
h2. From Camel to Petals
When an exchange is sent from Camel to Petals through a consumes endpoint, the following happen:
The Camel exchange is transformed to a JBI exchange.
Its properties are put into the JBI exchange properties (by reference).
Its In message is transformed to a normalized message.
Its headers are put into the normalized exchange properties (by reference).
Its attachments are put into the normalized message attachments (by reference).
The body is transformed, using available [Camel type converters|http://camel.apache.org/type-converter.html], to a DOMSource object (or if it is already a Source, it stays as a Source) and put in the content of the normalized message.
h2. Back to Camel from Petals
When an answer to an exchange sent to Petals arrives back to Camel through a consumes endpoint, the following happen:
If the exchange has the error status, the exception is put in the exchange.
If the exchange has a Fault, it is transformed to a Camel message (same process as before), the fault status is set on it and put as the exchange's Out.
If the exchange has an Out, it is transformed to a Camel message (same process as before) and put as the exchange's Out.
h2. Back to Petals from Camel
When an answer to an exchange sent to Camel from Petals arrives back to Petals through a provides endpoint, the following happen:
If the exchange has an Exception, the exception is put as the JBI exchange's error and its status is set to error.
If the exchange has a Fault, it is transformed to a normalized message of type fault (same process as before) and put as the JBI exchange's Fault.
If the exchange has an Out and it is an InOut or an InOptionalOut, it is transformed to a normalized message (same process as before) and put as the JBI exchange's Out.
If the exchange has no Out and it is an InOut exchange, its In message is transformed to a normalized message (same process as before) and put as the JBI exchange's Out.
In all the other cases, the exchange's status is changed to done.
{warning}
Some Camel processors are made to work in-place with an In message without making an Out message: because of this practice, we have to make the assumption that an InOptionalOut Camel message MUST have an Out message for the exchange to be considered not done!
In other words: before sending an InOptionalOut message that has an Out message back to Petals, make sure that the answer is not in the In but in the Out message of the Camel exchange.
{warning}
h1. Examples
Some examples are available with the SE.
In particular, the example named su-camel-databinding shows how to do some logging as well as convert the body of the JBI messages to Java objects using JAXB.
The JBI exchange is transformed to a Camel exchange.
Its properties are put into the Camel exchange properties (by reference).
Its In normalized message is transformed to a Camel message.
Its properties are put into the Camel message headers (by reference).
Its attachments are put into the Camel message attachments (by reference).
The content of the normalized message (a Source object in Java, containing XML) is put in the body of the Camel message without change.
h2. From Camel to Petals
When an exchange is sent from Camel to Petals through a consumes endpoint, the following happen:
The Camel exchange is transformed to a JBI exchange.
Its properties are put into the JBI exchange properties (by reference).
Its In message is transformed to a normalized message.
Its headers are put into the normalized exchange properties (by reference).
Its attachments are put into the normalized message attachments (by reference).
The body is transformed, using available [Camel type converters|http://camel.apache.org/type-converter.html], to a DOMSource object (or if it is already a Source, it stays as a Source) and put in the content of the normalized message.
h2. Back to Camel from Petals
When an answer to an exchange sent to Petals arrives back to Camel through a consumes endpoint, the following happen:
If the exchange has the error status, the exception is put in the exchange.
If the exchange has a Fault, it is transformed to a Camel message (same process as before), the fault status is set on it and put as the exchange's Out.
If the exchange has an Out, it is transformed to a Camel message (same process as before) and put as the exchange's Out.
h2. Back to Petals from Camel
When an answer to an exchange sent to Camel from Petals arrives back to Petals through a provides endpoint, the following happen:
If the exchange has an Exception, the exception is put as the JBI exchange's error and its status is set to error.
If the exchange has a Fault, it is transformed to a normalized message of type fault (same process as before) and put as the JBI exchange's Fault.
If the exchange has an Out and it is an InOut or an InOptionalOut, it is transformed to a normalized message (same process as before) and put as the JBI exchange's Out.
If the exchange has no Out and it is an InOut exchange, its In message is transformed to a normalized message (same process as before) and put as the JBI exchange's Out.
In all the other cases, the exchange's status is changed to done.
{warning}
Some Camel processors are made to work in-place with an In message without making an Out message: because of this practice, we have to make the assumption that an InOptionalOut Camel message MUST have an Out message for the exchange to be considered not done!
In other words: before sending an InOptionalOut message that has an Out message back to Petals, make sure that the answer is not in the In but in the Out message of the Camel exchange.
{warning}
h1. Examples
Some examples are available with the SE.
In particular, the example named su-camel-databinding shows how to do some logging as well as convert the body of the JBI messages to Java objects using JAXB.