Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <17122269.post@talk.nabble.com>
Date: Thu, 8 May 2008 01:01:09 -0700 (PDT)
From: cmoulliard <cmoulliard@gmail.com>
To: camel-user@activemq.apache.org
Subject: Re: bpm and events planned in Camel !
In-Reply-To: <b23ecedc0805070751i35f46bbdm3b67143c62bcf97e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <17106171.post@talk.nabble.com>
 <ec6e67fd0805070742p6c08872as4963ca5dac1e1fbf@mail.gmail.com>
 <b23ecedc0805070751i35f46bbdm3b67143c62bcf97e@mail.gmail.com>


I know this component but the functionality proposed here are different from
Mule integration.

OSworkflow is started as a new thread when a message arrives at its endpoint
while Mule bpm component allow to start, advance ot stop a process AND a
task of the process can interact with another endpoints of the bus.

Regards,

Charles


gnodet wrote:
> 
> Btw, servicemix has a new OSForklow component:
>   http://servicemix.apache.org/servicemix-osworkflow.html
> 
> On Wed, May 7, 2008 at 4:42 PM, James Strachan <james.strachan@gmail.com>
> wrote:
>> 2008/5/7 cmoulliard <cmoulliard@gmail.com>:
>>
>>
>> >
>>  >  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
>>  >  (http://mule.mulesource.org/display/MULEUSER/BPM+Connector).
>>  >
>>  >  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
>>  -------
>>  http://macstrac.blogspot.com/
>>
>>  Open Source Integration
>>  http://open.iona.com
>>
> 
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> 
> 

-- 
View this message in context: http://www.nabble.com/bpm-and-events-planned-in-Camel-%21-tp17106171s22882p17122269.html
Sent from the Camel - Users mailing list archive at Nabble.com.