We have two kind of workflow families depending if they relies or not on the standard ws-bpel using webservices & schema and if the information can be persist in DB or not.
Workflow engine not implementing the WS-BPEL standard but using java objects and running the process in memory - OSWorkflow, - Flow4J Workflow engine implementing the WS-BPEL standard (without DB) - Ode Workflow engine implmenting the WS-BPEL standard and using a DB - jBPM, - Intalio Remark : jBPM is an exception because the engine can run WS-BPEL or JPDL processes. The JPDL process are designed through Eclipse GUI interface and allow the user like OSWorkflow/Flow4J to link a task to a java class and not like in BPEL a task to a schema/webservices. Remark : This list of workflow engines is non exhaustive and can be extended. Regards, Charles Work quote author="gnodet"> So what's the difference with a bpel engine like Ode ? On Thu, May 8, 2008 at 10:01 AM, cmoulliard <[EMAIL PROTECTED]> wrote: > > 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. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/bpm-and-events-planned-in-Camel-%21-tp17106171s22882p17143074.html Sent from the Camel - Users mailing list archive at Nabble.com.
