Thx for answer.
1. Apache Camel - http://camel.apache.org/
Camel is a integration framework based on known Enterprise Integration Patterns with powerful Bean Integration.
It's somewhat similar to Mule, the main differences are:
a) Camel is more a library than container - it can be embedded in virtually every environment - one of most common usages is acting as EIP implementation for Apache Servicemix ESB - http://servicemix.apache.org/home.html, or Apache Karaf OSGi container - http://karaf.apache.org/
b) Camel's strong point is Java DSL, which allows for easy definition of integration routes (called flows in Mule)
What's more:
a) It's v. easy to add new components (called modules/transports in Mule) - there are more than 70 I guess - http://camel.apache.org/components.html.
Components are autodiscovered on classpath, and identified by uri (e.g. file:///tmp - identifies endpoint reading or writing files to folder /tmp, jsm:topic:myTopic - identifies endpoint publishing or subscribing to myTopic)
b) It's very easy to integrate Camel with spring or OSGi Blueprint
2. What we want to doOur main use case is to be able to deploy Activiti processes in OSGi container. We use mainly Camel for our integration needs, so we thought it'd be nice to be able to perform integration (both calling services from process, and processes waiting for messages from external systems) by custom Camel component.
3. How would it work?
The process would be deployed as a OSGi bundle, together with appropriate camel context, using OSGi deployment model currently available in Activiti.
https://github.com/mproch/activitiCamelKarafSample/tree/master/process/src/main - here is sample project structure.
a) setup
This part is a bit tricky.
First, you have to create CamelBehaviour class, which has to know which camel context (there could be many for many processes) should be invoked.
Here: https://github.com/mproch/camel-activiti/blob/master/sample/src/main/resources/camel-activiti-contex... is the example for monolithic environment, in OSGi context one has to use OSGi services,
as it's done here:
https://github.com/mproch/activitiCamelKarafSample/blob/master/bundle/src/main/resources/OSGI-INF/bl..., https://github.com/mproch/activitiCamelKarafSample/blob/master/process/src/main/resources/META-INF/s.... For OSGi example I had to do some extesion of activiti-osgi to be able to use blueprint beans in activiti expressions, btw.
b) invoking Camel route from ServiceTask.
In process code, it's as simple as adding
Then CamelBehaviour is responsible for finding Camel route starting with
c) Invoking process by camel.
When process is in receive node:
waiting in activity named receive. Then it signals this process, it also passes exchange properties as process variables (probably need some better solution).
Summary:
This component is not a rocket science, especially configuration is slightly awkward in OSGi environment, but it enables us to leverage power of Camel in Activiti. Guess it would serve some similar role as Mule integration, but for Apache Camel users, which are also quite numerous
1. Apache Camel - http://camel.apache.org/
Camel is a integration framework based on known Enterprise Integration Patterns with powerful Bean Integration.
It's somewhat similar to Mule, the main differences are:
a) Camel is more a library than container - it can be embedded in virtually every environment - one of most common usages is acting as EIP implementation for Apache Servicemix ESB - http://servicemix.apache.org/home.html, or Apache Karaf OSGi container - http://karaf.apache.org/
b) Camel's strong point is Java DSL, which allows for easy definition of integration routes (called flows in Mule)
What's more:
a) It's v. easy to add new components (called modules/transports in Mule) - there are more than 70 I guess - http://camel.apache.org/components.html.
Components are autodiscovered on classpath, and identified by uri (e.g. file:///tmp - identifies endpoint reading or writing files to folder /tmp, jsm:topic:myTopic - identifies endpoint publishing or subscribing to myTopic)
b) It's very easy to integrate Camel with spring or OSGi Blueprint
2. What we want to doOur main use case is to be able to deploy Activiti processes in OSGi container. We use mainly Camel for our integration needs, so we thought it'd be nice to be able to perform integration (both calling services from process, and processes waiting for messages from external systems) by custom Camel component.
3. How would it work?
The process would be deployed as a OSGi bundle, together with appropriate camel context, using OSGi deployment model currently available in Activiti.
https://github.com/mproch/activitiCamelKarafSample/tree/master/process/src/main - here is sample project structure.
a) setup
This part is a bit tricky.
First, you have to create CamelBehaviour class, which has to know which camel context (there could be many for many processes) should be invoked.
Here: https://github.com/mproch/camel-activiti/blob/master/sample/src/main/resources/camel-activiti-contex... is the example for monolithic environment, in OSGi context one has to use OSGi services,
as it's done here:
https://github.com/mproch/activitiCamelKarafSample/blob/master/bundle/src/main/resources/OSGI-INF/bl..., https://github.com/mproch/activitiCamelKarafSample/blob/master/process/src/main/resources/META-INF/s.... For OSGi example I had to do some extesion of activiti-osgi to be able to use blueprint beans in activiti expressions, btw.
b) invoking Camel route from ServiceTask.
In process code, it's as simple as adding
<serviceTask id="serviceTask" activiti:delegateExpression="${camel}"/> Then CamelBehaviour is responsible for finding Camel route starting with
from("activiti:camelProcess:serviceTask")….)(camelProcess is the processName). Exchange is created with empty body, and process variable values as properties (maybe some better solution is needed), and passed to the route, e.g.from("activiti:camelProcess:serviceTask")
.to("log
l.touk")
.setBody().property("var1")
.to("file:///tmp/activiti/serviceTask");
will log contents to 'pl.touk' log appender and then create file in /tmp/activiti/serviceTask, with value of process variable var1 as content.c) Invoking process by camel.
When process is in receive node:
<receiveTask id="receive" name="Wait State"/>it can be invoked (signaled) by following camel route:
from( "file:///tmp/activiti/receive")
.convertBodyTo(String.class)
.setProperty("PROCESS_KEY_PROPERTY").xpath("//@key")
.to("activiti:camelProcess:receive");
waiting in activity named receive. Then it signals this process, it also passes exchange properties as process variables (probably need some better solution).
Summary:
This component is not a rocket science, especially configuration is slightly awkward in OSGi environment, but it enables us to leverage power of Camel in Activiti. Guess it would serve some similar role as Mule integration, but for Apache Camel users, which are also quite numerous
sorry for the late reply. can you elaborate on what exactly you want to contribute to activiti?
fyi: we don't know camel, but we're interested in the integration.
Hi Tom
What do you mean with you don't know Camel? We spoke at the Devoxx 2010 conference
You and Tijs came by the FuseSource booth.I had a look at the activiti-camel component and it seems good work.
Maciek also posted on the Camel forum
http://camel.465427.n5.nabble.com/Integrating-camel-with-activiti-tp3331707p3331707.html
So we are talking about where the component should live. Obviously we can host it at Apache Camel.
But I wonder the Activiti team plans to host integrations to 3rd party as well? If so maybe this component is better hosted at Acitivi.
/Claus Ibsen
http://davsclaus.blogspot.com/
