E-mail
|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (30)
View Page History
...
{section} 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.
Consumers and producers refers to service external to Camel using an URI: Petals has its own URI scheme.
Consumers and producers refers to service external to Camel using an URI: Petals has its own URI scheme.
For each *provides* section, exactly one route must be present and will be activated when a message is received.
Each route can call any service declared in a *consumes* section.
*Consumes* corresponds to an operation of a service and have a MEP defined.
Each route can call any service declared in a *consumes* section.
*Consumes* corresponds to an operation of a service and have a MEP defined.
*Provides* corresponds to a service defined with WSDL and for which every operation has a one corresponding route.
{tip}
...{tip}
We show in the next section a general overview of a typical Service Unit.
{tip}
The SOA terminology is sometimes confusing: in the following we will use the general term *service* and operation interchangeably.
{tip}
The SOA terminology is sometimes confusing: in the following we will use the general term *service* and operation interchangeably.
{tip}
We show in the next section a general overview of a typical Camel Service Unit.
h1. Overview of a Camel Service Unit at Runtime
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.
For details on the transformation, see the section [Petals to Camel to Petals|#transformations] below.
h1. Overview of a Camel Service Unit at Runtime
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.
For details on the transformation, see the section [Petals to Camel to Petals|#transformations] below.
h1. Overview of a Camel Service Unit at Implementation Time
...{noformat}
There must be at least one route implementation per operation of the provides, in a jar file or an xml file, a WSDL description for every provides service declared in of the JBI descriptor and of course a JBI descriptor.
h2. A Camel Route
...{code:lang=xml}
<!-- we must still use the http://camel.apache.org/schema/spring namespace so Camel can load the routes
though but Spring JARs is are not required -->
<routes xmlns="http://camel.apache.org/schema/spring">
<route>
<route>
...{code}
{color:red}{*}TODO. make that a real example, this is copied from an example on the web...*{color}
{color:red}{*}TODO. make that a real example...*{color}
The only specificity for Petals of this route are the URIs used to identify the services consumed by the route (*from* element) and to which messages are then sent (*to* element).
The protocol scheme reserved to petals is *petals* and *petals*: it is followed by *:* and then the unique id identifying a service's operation.
One can refer to provides services with from() and to consumes services with to().
The rest is typical Camel but some Camel processors are particularly useful to handle Petals exchange from within Camel, such as the jaxb marshaller/unmarshaller or the body conversion.
See the section [Camel Routes|#camel-routes] below for details.
See the section [Camel Routes|#camel-routes] below for details.
{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}
h2. JBI Descriptor and WSDL definition
...In order to identify a service's operation, each of the operation, provided or consumed, must have a unique id.
Of course, a provided service's operation will be only usable by *from* elements and consumed services by *to* elements.
{code:lang=xml}
...<jbi:consumes interface-name="hello:HelloInterface" service-name="hello:HelloService">
<!-- Mandatory CDK specific elements -->
<petalsCDK:operation>hello:sayHello</petalsCDK:operation>
<petalsCDK:mep>InOut</petalsCDK:mep>
<petalsCDK:mep>InOut</petalsCDK:mep>
<!-- Mandatory Component specific elements -->
<petals-se-camel:service-id>theConsumesId</petals-se-camel:service-id>
</jbi:consumes>
</jbi:consumes>
...{code}
In these two snippets, the important parts are the elements with the namespace URI {{http://petals.ow2.org/components/petals-se-camel/jbi/version-1.0}} for the JBI and {{http://petals.ow2.org/components/petals-se-camel/wsdl/version-1.0}} for the WSDL.
The first one enables to define the service id for a consumes in the JBI: notice that the consumes must also have a MEP and an operation set.
...Finally, the *services* section of the JBI contains a list of routes to be loaded by the Camel SE.
Two types of route definitions can be used: java classes and XML files.
Two types of route definitions can be used: java classes and XML files.
Java classes refer to classes that extends the Camel RouteBuilder abstract class, i.e. routes written with any of the JVM-based DSLs: [Camel DSL Page|http://camel.apache.org/dsl.html].
XML files refer to routes defined used the XML DSL from Camel: [Camel XML Examples|http://camel.apache.org/walk-through-another-example.html].
h1. Overview of a Camel Service Unit at Runtime
h1. Semantics of the Send operation (synchronicity, timeouts, etc)
Camel routes are instantiated in a Camel context.
With the SE Camel, for every SU, there is one Camel context created containing all the routes described in the SU.
When a message arrives on a provided service, it is dispatched to the route that consumes the service.
With the SE Camel, for every SU, there is one Camel context created containing all the routes described in the SU.
When a message arrives on a provided service, it is dispatched to the route that consumes the service.
By default, the execution is asynchronous: it means that if one of the processor or producer on the route needs to do blocking operations, the processing won't keep the CDK thread that received the message busy and it will continue execution when it is time to depending on the blocked processor.
This has no impact on how the routes are implemented, but in term of execution, it means that threads are not blocked and resources are often freed as soon as possible.
This has no impact on how the routes are implemented, but in term of execution, it means that threads are not blocked and resources are often freed as soon as possible.
See http://camel.apache.org/asynchronous-routing-engine.html [Camel Asynchronous Routing Engine|http://camel.apache.org/asynchronous-routing-engine.html] and http://camel.apache.org/asynchronous-processing.html [Camel Asynchronous Processing|http://camel.apache.org/asynchronous-processing.html] for technical details.
Nevertheless, it is possible to force synchronous execution:
- of a route either by adding the *synchronous* argument to the Camel *from* URI, or
- of a service invocation when calling an external petals services using a *to* with the same argument.
It is also possible to have a timeout (for synchronous and asynchronous mode) to specify how long we should wait before failing a service invocation done with *to* by using the *timeout* option.
Note: by default, it will use the value specified in the JBI consumes section. The section and as usual, the value *0* means no timeout.
{anchor:camel-routes}
h1. Camel Routes
{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}
{anchor:transformations}
h1. Petals to Camel to Petals
{color:red}{*}TODO. Explains how Petals and Camel exchanges are transformed to each others{*}{color}