camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cmoulliard <>
Subject Re: bpm and events planned in Camel !
Date Thu, 08 May 2008 07:58:10 GMT

BTW you'd be using a database to store each business process and
process instance right? Or do you mean all the workflow processes
would exist purely in RAM?

Here is my point of view :

It depends of the strategy. According to the implementation done in
servicemix (ex of osworkflow), this is not required to have a database where
status of the workflow steps are save because the workflow is started in a
separate thread when a message arrive at the endpoint.
What has been done by Mule is slightly different because they support to
start (or advance or stop) a workflow at a endpoint when a message arrives
(so same functionality as provided by servicemix and osworkflow) but the
workflow process itself can interact with endpoints of the ESB bus using
events (see remark hereafter coming from Mule doc). In this last case, a
database could be helpful to avoid to lost data/information about where we
are in the workflow process in case of a ESB crash.

I'm not at all a partisan/subscriber of a BPM approach because using two
servers in parallel (the ESB bus server and the BPM engine) will increase
also the complexity and probably debugging and deployment time. But to be
honest, the big advantage of a BPM approach is that they provide a GUI
interface (eclipse based) to allow business/user/developer to design the
solution and understand the business to implement. Using Camel, we don't
have such a tool and communication between business/analayst and developers
is not simplified. Moreover, developers have to generate the routing
developed through a maven script at the end of the development process.

The design of a SOA solution top of an ESB bus include of course EIP
patterns to route data/information from components to other components but
also to include business decision according to user's data/requirements.
Intrinsically, the way which is proposed today to design a SOA solution is
to mix business logic and routing at the endpoints of the ESB bus or inside
POJO deployed. Is it the best strategy in term of development and
maintenance ?
As long as the project advances, that the requirements evolve, the developer
will have to review continuously the Camel routes (content message, splitter
or aggregator, ....) and the business rules implemented. This increase the
cost of the project for the development and the test part. 

My opinion is that it should be better (according to the IT environment of
the clients and their business) during the analysis phase to concentrate our
work defining the components and the business services that we will deploy
on to the ESB bus.
But how the communication, how the orchestration according to the client's
requirements will be done should be designed through a workflow using
decision points and tasks. A task could be a service of the bus.
In this way, we can reuse the components / business services from different
projects in order to avoid to overload the camel routes with too much
decision points each time new client requirements arrive or that we have to
implement a new client top of the ESB (this is case when you plan to install
a HOSTING ESB SOLUTION). The beautiful world would be that we can modeling
through Camel the client workflow using camel routes + drools and that when
a message arrive on the bus, the Camel container will process the message
according to the client workflow (like a BPM engine do). As the workflows
are not the same from a client to another (because they require different
STP processes), we can concentrate our work to build a SOA world and not
spending our time to overload the existing rules inside Camel routes in
order to support the new requirements. This is why I try to plead to
integrate a BPM engine into the ESB bus. In this way, we can build as many
workflows as we want and when new components or business services are
required we add them on the bus and orchestration will allow to interconnect
the endpoints. But, int his case, the BPM will process the communication
between the endpoints. Is it something which is realistic for Camel and/or
Servicemix ?



James.Strachan wrote:
> 2008/5/7 cmoulliard <>:
>>  Hi,
>>  Imagine that you start a ESB/SOA project and you are able to design
>> using
>>  EIP the routing that you need for most of your clients (ex : messages
>> file
>>  or queue messages must be parsed --> client must be identified -->
>> messages
>>  must be transformed --> DB must be called to enrich messages -->
>> messages
>>  enriched must be send back to the client through queue manager or file
>>  directory). To develop this STP process, you use the Camel routing.
>>  Unfortunately, over time, clients request more and more different
>> extensions
>>  points (meaning that the routing or workflow of a client is different
>> from
>>  another) and your routing becomes very complex because :
>>  - lot of decision points have been added to change the routing according
>> to
>>  client's requirements,
>>  - debugging/testing time increases to be able to tests all the test case
>> or
>>  debug problem
>>  At that moment, you contemplate to reconsider your architectural
>> platform
>>  and to implement a dynamic routing based on the client workflow.
>>  But How can I implement a dynamic routing between my components to
>>  orchestrate the workflows of my clients ?
>>  A solution that you can investigate to implement such a workflow is to
>> use
>>  an orchestration engine like WS-BPEL but your architecture does not
>> require
>>  to persist state of the tasks and to use webservices.
>>  An interesting alternative is to use a workflow engine like jBoss BPM or
>>  OSworkflow to orchestrate the communication between services/endpoints.
>>  But this approach requires that you have one queue/service because the
>>  orchestration engine must place messages into the queues to trigger the
>>  correct service or component according to client's workflow.
>>  The simplest solution would be to have event to trigger components.
>>  Mule platform proposes this kind of functionality
>>  (
>>  Of course, my question will be simple :
>>  Are bpm endpoint (bpm:///) AND events between endpoints planned for
>> Camel
>>  like this is proposed within Mule ?
> Sure - I think a BPM connector would be a great idea. Particularly for
> OSWorkflow / jBPM. Also Drools could help in these complex cases.
> Sometimes just using your own Bean with Java code can be much easier
> than using a BPM tool btw :) On projects I've often found BPM tools
> seem great on day one but cause more and more pain over time until you
> end up replacing it :)
> But yes for folks who wanna use a BPM tool to help create workflows,
> we should support it; it should be pretty easy to add.
> BTW you'd be using a database to store each business process and
> process instance right? Or do you mean all the workflow processes
> would exist purely in RAM?
> -- 
> James
> -------
> Open Source Integration

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message