2 Replies Latest reply on Nov 11, 2009 6:06 AM by Juan Ignacio Sánchez Lara

    Riftsaw, jBPM/BPEL and Drools flow

    Thorbjørn Blixen-Finecke Newbie

      Hi

      First of all great initiative.

      Now to the questions:

      How does Riftsaw fit in with jBPM/BPEL? Will it replace jBPM/BPEL as the way to execute WS-BPEL 2.0 processes (since jBPM i think can do that too)?

      There are quite many ways to do processses/workflows in the JBoss stack (jBPM, Page Flow, Drools Flow and now Riftsaw). The jBPM approach of one engine and many ways to model flows depending on what one needs (ie. Page Flows, Technical workflows and Business Processes/BPEL) seems quite sound (as it is quite easy to understand why a business/project might need this).

      However now the same way of modeling (BPMN and BPEL) seems to become possible on many different engines (jBPM, Drools Flow and Riftsaw/Apache Ode). I can see why a Rule engine might need a different workflow execution environment from a more traditional workflow engine. But Riftsaw and jBPM seem very similar (execution of long running and short running process graphs with wait states). I have used a few workflow/process execution engines and judging by their quality with regards to handling exceptions, parallel execution, large volumes of active flows, process versioning, transactions and resource outages (for instance in the databases that support them) it seems that creating a workflow engine from scratch is no simple task. Hence the approach of one execution environment and many ways to model seems like a good idea (the quality of the tools means a lot, but the quality and robustness of the execution engine is critical). However i might be missing something here.

      Is there any road map one could look at that indicates how these different process execution environments will work together or why they are different (both at the technical level and with regards to what services they will provide/admin consoles etc.)?

        • 1. Re: Riftsaw, jBPM/BPEL and Drools flow
          Burr Sutter Master

           

          How does Riftsaw fit in with jBPM/BPEL?

          Riftsaw is based on Apache Ode and has no relationship to jBPM BPEL

          Will it replace jBPM/BPEL as the way to execute WS-BPEL 2.0 processes (since jBPM i think can do that too)?

          Riftsaw will be the basis for the supported enterprise version of WS-BPEL 2.0 at JBoss/Red Hat. It does not replace jBPM BPEL at jboss.org but it does represent a new forward looking direction.

          Is there any road map one could look at that indicates how these different process execution environments will work together or why they are different (both at the technical level and with regards to what services they will provide/admin consoles etc.)?

          We are working on a roadmap that incorporates the futures of jBPM, Riftsaw and DroolsFlow. One of the reasons there are multiple engines is because of the multiple communities which drive the focus for these projects.
          The Drools community wanted a solution where business rules, business events and business processes were all first-class citizens and tightly interwoven into a cohesive whole.
          The Riftsaw/Apache Ode community has been almost exclusively focused on standards-based BPEL.


          Burr


          • 2. Re: Riftsaw, jBPM/BPEL and Drools flow
            Juan Ignacio Sánchez Lara Apprentice

            I'm quite worried about effort duplication and future integration problems with all this flow stuff. I hope that jBPM/RiftSaw/ESB/Drools roadmap is defined soon and clarifies this situation.
            I can understand this is a difficult problem: service orchestration is not exactly the same than business modelling and so, but I'm sure they're really tight related. For example, I want to be able to define flows where a node writes to the DB, the next one sends a document to a DNA server and calls a web service, the next one makes a decision based on business rules... That kind of flow is common in enterprises, and it makes no sense using three different technologies to define it.

            By now I think jBPM 4 is the best tool for my needs, but if the next JBoss ESB doesn't support it and uses only RiftSaw, for example, I won't be able to use it...

            I know orchestrating several workgroups is difficult, but it seems that there's the need of some kind of collaboration between them on this subject.