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 <[EMAIL PROTECTED]> > wrote: >> 2008/5/7 cmoulliard <[EMAIL PROTECTED]>: >> >> >> > >> > 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.
