13 Replies Latest reply on Aug 5, 2008 10:24 AM by kukeltje

    Making the BPM API more generic?

    krisverlaenen

      I believe that the idea of creating a public API for jPDL or BPM in general is very interesting. We (the JBoss Drools team) try to achieve close integration between processes and rules. A generic BPM API could be very useful here. Our vision is to create a unified platform where rules and processes are simply different ways of expressing (some of your) business logic and can be seamlessly integrated. This would allow users to select the most appropriate paradigm for their problem and integrate rules and processes without requiring them to learn and integrate different products themselves.

      This is partially based on the observation that both rules and processes have a very similar life cycle: creation in a custom editor, storing your business logic in a repository, deployment to a runtime environment, monitoring and management of the execution, etc. We believe that is should be possible to offer an unified environment where this life cycle is supported as much as possible and both rules and processes are considered different types of business logic.

      Drools has a RuleFlow language (for specifying the order in which rules should be executed using a flow chart) since v4.0 and is now extending that scope to become a more generic workflow language as well, where rules and processes can be integrated seamlessly (called Drools Flow). It would be interesting to see whether Drools Flow (or any other language like e.g. BPEL) can also fit in this common API effort, and maybe in the long term whether we can offer a similar API for both rules and processes.

      I think it would be possible to achieve this if we split the API into a more generic part (offering methods to interact with processes of any type) and allow specific process languages (like jPDL3 or 4 or Drools Flow) to extend this API with more specific constructs. For example, different languages would probably have a different process model, but they all could implement a generic process interface. I also believe that the API for interacting with a process engine (starting processes, signalling events , communicating with external services, etc.) can all be made independent of the underlying process model and implementation (the user should not be confronted with these details in most cases). The interfaces defined by the WfMC are a very good example of this.

      I'd be glad to provide more details on the different APIs Drools Flow is currently using to communicate with the outside world if needed !

      Kris

        • 1. Re: Making the BPM API more generic?
          jbarrez

           

          .. split the API into a more generic part (offering methods to interact with processes of any type) and allow specific process languages (like jPDL3 or 4 or Drools Flow) to extend this API with more specific constructs. ... API for interacting with a process engine (starting processes, signalling events , communicating with external services, etc.) can all be made independent of the underlying process model and implementation (


          Isn't this what the PVM is all about: extracting what is generic and allowing process languages to be built on top of that?

          If I'm following the discussions here, the 'BPM API' is something that is separated from the PVM, since it is a refactoring of jBPM3.

          I call myself a 'jbpm power-user' since I use it on a daily basis in real-life projects. But I find it quite confusing that these 'BPM API' and 'PVM' ideas seem separated while efforts should be bundled to have a better product. If I'm wrong (which would be good), please correct me.

          • 2. Re: Making the BPM API more generic?
            thomas.diesler

             


            A generic BPM API could be very useful


            Yes, moreover. JBossBPM customers need a stable API that they can rely on between version updates. For details on compatibility see
            http://jbpm.dyndns.org/jbpmwiki/index.php?title=APIMission#What_is_expected_to_be_stable.2C_what_is_not.3F

            As documented in the wiki the JBossBPM conceptually follows the BPMN specification

            http://en.wikipedia.org/wiki/BPMN

            Using that spec we created a model which is meant to accommodate the conceptual constructs from the BPM world

            * Event (start, stop, intermediary)
            * Gateway (exclusive, inclusive, parallel, complex)
            * Task (None, User, Send, Receive, Script, etc)
            * SequenceFlow, MessageFlow
            * Pools, Swimlanes
            * SubProcesses
            * CompensationFlow, ExceptionFlow.
            * InputSet, OutputSet, IORules

            See http://jbpm.dyndns.org/jbpmwiki/index.php?title=BPMNGlossary for the definition of terms.

            Together with the API we define a Compatibility Test Suite (CTS) that checks whether a BPM implementation is actually fulfils the SOA-Platform product requirements. At this point jBPM4 is expected to do so. It is ready when it passes the CTS through the API.

            With respect to DroolsFlow, I would expect that you can map your model to the API model implementing a DialectHandler

            http://jbpm.dyndns.org/jbpmwiki/index.php?title=BPMPublicAPI
            http://jbpm.dyndns.org/jbpmwiki/index.php?title=APIDialectHandler

            For even more detail you can have a look at the API JavaDocs.
            http://jbpm.dyndns.org/jbpm-site/jbpm-api/apidocs/index.html

            You can have a look at the Airticket GWT Sample Application (to be documented in the wiki) from the JBossBPM reference implementation (RI). There you find a standard BPMN process definition created with the Eclipse BPMN Editor from the SOA Tools Package (STP). Additionaly an API native descriptor that adds BPMN constructs that are not currently supported by STP. The API Dialect handler includes the STP process definition, builds the API model and executes it on the RI.

            A process modelling tool that supports the full set of BPMN constructs would have very little externally defined.

            In short: A good modelling tool is one that supports a large set of standard constructs plus proprietary extensions. A DialectHandler should be able to map that to the API model. A BPM provider that implements the API should be able to execute that model.

            Hopefully, we can get together soon to discuss this in more detail.

            • 3. Re: Making the BPM API more generic?
              thomas.diesler

               


              the 'BPM API' is something that is separated from the PVM, since it is a refactoring of jBPM3


              This is not true. The JBossBPM API, together with its RI and CTS is a separate project with no relation to jBPM3


              I call myself a 'jbpm power-user' since I use it on a daily basis in real-life projects. But I find it quite confusing that these 'BPM API' and 'PVM' ideas seem separated while efforts should be bundled to have a better product. If I'm wrong (which would be good), please correct me.


              Yes, it'd be good if we could actually see some of the PVM concepts and API - so we can discuss them at a conceptional level. Implementation detail is not useful for that purpose.

              CONCEPTS not detail is what needs to be discussed in a early design phase.

              The first release of the API will come out 1-Sep-2008

              • 4. Re: Making the BPM API more generic?
                jbarrez

                Ok, thanks for the clarification so far. I still have some questions though:

                If I'm correct:
                - The API is a product not related in any way to jBPM
                - The PVM is an improvement of jBPM but not related to the API

                Does this mean that we'll have *2* JBoss BPM products in the future? Or will the 2 projects be merged? What's the benefit of having these 2 separate products?

                • 5. Re: Making the BPM API more generic?
                  tom.baeyens

                   

                  "KrisVerlaenen" wrote:
                  I believe that the idea of creating a public API for jPDL or BPM in general is very interesting. We (the JBoss Drools team) try to achieve close integration between processes and rules. A generic BPM API could be very useful here. Our vision is to create a unified platform where rules and processes are simply different ways of expressing (some of your) business logic and can be seamlessly integrated. This would allow users to select the most appropriate paradigm for their problem and integrate rules and processes without requiring them to learn and integrate different products themselves.

                  This is partially based on the observation that both rules and processes have a very similar life cycle: creation in a custom editor, storing your business logic in a repository, deployment to a runtime environment, monitoring and management of the execution, etc. We believe that is should be possible to offer an unified environment where this life cycle is supported as much as possible and both rules and processes are considered different types of business logic.

                  Drools has a RuleFlow language (for specifying the order in which rules should be executed using a flow chart) since v4.0 and is now extending that scope to become a more generic workflow language as well, where rules and processes can be integrated seamlessly (called Drools Flow). It would be interesting to see whether Drools Flow (or any other language like e.g. BPEL) can also fit in this common API effort, and maybe in the long term whether we can offer a similar API for both rules and processes.

                  I think it would be possible to achieve this if we split the API into a more generic part (offering methods to interact with processes of any type) and allow specific process languages (like jPDL3 or 4 or Drools Flow) to extend this API with more specific constructs. For example, different languages would probably have a different process model, but they all could implement a generic process interface. I also believe that the API for interacting with a process engine (starting processes, signalling events , communicating with external services, etc.) can all be made independent of the underlying process model and implementation (the user should not be confronted with these details in most cases). The interfaces defined by the WfMC are a very good example of this.

                  I'd be glad to provide more details on the different APIs Drools Flow is currently using to communicate with the outside world if needed !

                  Kris


                  PVM contains 3 different API views:
                  1) client
                  2) activity implementation
                  3) event listener

                  In its current shape, Thomas' BPM API has the same scope and target then the client API part (1) of the PVM. I think this is to be considered a learning excercise in Thomas' start to work out the BPM product requirements.

                  But to answer your question, I think it is always good to compare each other's work. Are your API docs online ? A link would be great.

                  PVM API lastest version is here: http://docs.jboss.com/jbpm/pvm/api/ This is still in flux, but the next version to a couple of weeks will be pretty much stable.

                  • 6. Re: Making the BPM API more generic?
                    krisverlaenen

                     

                    "thomas.diesler@jboss.com" wrote:
                    Using the BPMN spec we created a model which is meant to accommodate the conceptual constructs from the BPM world


                    All these constructs sound extremely familiar of course, basically all workflow specifications and languages define these in one way or another. What I don't see is this language is different from for example the jPDL language, WS-BPEL, XPDL or Drools Flow? Why not use an existing process model (and possibly extend that if necesary)?

                    "thomas.diesler@jboss.com" wrote:
                    With respect to DroolsFlow, I would expect that you can map your model to the API model implementing a DialectHandler

                    This would mean that the common API is some kind of uber process model that can be used to execute any process and that all process languages could be mapped to this language? The PVM idea on the other hand tries to offer the flexibility of different process languages on the same execution platform without having to map everything to one core language. Different contexts typically require different types of nodes: service orchestration is quite different from pipelining events and from healthcare processes for example. Sometimes it's just better to allow users to plug in their own implementation (based on a generic core) than force them to translate to one specific model.

                    However, regardless of which process model is used internally, I think that it is possible however to define a high-level generic API in how the user interacts with the different BPM components: repository, runtime engine, monitoring, etc.

                    Kris


                    • 7. Re: Making the BPM API more generic?
                      krisverlaenen

                       

                      "tom.baeyens@jboss.com" wrote:
                      Are your API docs online ? A link would be great.


                      Yes, of course, all Drools code can be found in our svn repository. But as it might be a bit difficult to find what you need in this web of classes, let me give you a high-level overview. Note that I will only include generic interfaces, specific process languages could extend some of these interfaces to offer more options to the end users.

                      /* A process contains the definition of the business logic, specific process languages need to extend this interface. */
                      Process

                      void setId(String id);
                      String getId();
                      void setName(String name);
                      String getName();
                      void setVersion(String version);
                      String getVersion();
                      void setType(String type);
                      String getType();
                      void setPackageName(String packageName);
                      String getPackageName();
                      void setMetaData(String name, Object value);
                      Object getMetaData(String name);

                      /** End users that want to execute processes interact with a session */
                      Session

                      ProcessInstance startProcess(String processId);
                      ProcessInstance startProcess(String processId, Map<String, Object> parameters);

                      public Collection getProcessInstances();
                      public ProcessInstance getProcessInstance(long id);

                      /** A process instance represents one instance of a process that is currently executing, specific process languages need to extend this interface */
                      ProcessInstance

                      long getId();
                      String getProcessId();
                      int getState();
                      void setState(int state);

                      /* Events */
                      void signalEvent(String type, Object event);

                      /* Variable Scope */
                      Object getVariable(String name);
                      Map<String, Object> getVariables();
                      void setVariable(String name, Object value);

                      /* Whenever the execution engine want to invoke external services, it does so using an abstract workitem (contains name-value parameters) */
                      WorkItemHandler

                      void executeWorkItem(WorkItem workItem, WorkItemManager manager);
                      void abortWorkItem(WorkItem workItem, WorkItemManager manager);

                      /* Results of these invocations can be returned to the execution engine */
                      WorkItemManager

                      void completeWorkItem(long id, Map<String, Object> results)
                      void abortWorkItem(long id)

                      Then there are of course also interfaces for storage and deployment, monitoring, etc.

                      Note that these interfaces are generic and contain nothing specific about Drools Flow.

                      Kris

                      • 8. Re: Making the BPM API more generic?
                        mark.proctor

                        Drools in M3 in about 3 weeks will be orienting away from a rules centric api to a knowledge centric api - i.e. it will not be process centric either, nor will it be tied to Drools. This has been planned for a while:
                        http://www.mail-archive.com/rules-dev@lists.jboss.org/msg00757.html//www.mail-archive.com/rules-dev@lists.jboss.org/msg00757.html

                        This api will be able to wrap, to some degree, other process engine apis. Our PVM will also be capable of executing their models. As proof of concepts krisv has done partial implementations for BPEL, OSWorkfow and jBPM. BPEL runtime is almost complete (Drools is able to execute most examples), although it has not been wired up to WS and still needs work on XML assignment issues. OSWorkflow and jBPM runtime mappings are about 70% complete.

                        Diego from OSWorkflow is keen on finishing the OSWorkflow adaption. And I'm hoping someone else will take ownership of the BPEL side - we are in talks with large health organisation that is possible going to lend 2 resources for BPEL and WS-Human-Task implementation. We've checkout the Eclipse BPEL tooling and it's now much more improved and almost complete, making BPEL support with tooling now a possibility.

                        • 9. Re: Making the BPM API more generic?
                          kukeltje

                          Hmmm... I admire JBoss having this discussion on a public forum. It is good to have the intention to achieve synergy. Personally though, I get the impession there are, at least to a certain extend, 2 competing camps.

                          If I were a potential/current customer/user I'd become a little restless on where 'everything' (and I know I exaggerate) is going. 'Drools executing BPEL', jBPM runtime mappings? A second PVM, OSWorkflow?... Besides that, as an (upcomming) consultant, I to have to be able to rely on something.

                          A stable API?afaik, the jBPM api was kind of stable. Not very transparant, but stable. In fact it is not that different from what Kris mentions for Drools.

                          I know this is only partially a comment on the contents of this topic, but I thought I'd give my €0.0125 (at an exchangerate of 1:1.6) anyway.

                          • 10. Re: Making the BPM API more generic?
                            thomas.diesler

                             


                            The API is a product not related in any way to jBPM


                            Branding is not decided yet. For now I'd like to call it JBossBPM, which comprises API + RI + CTS. Yes it is not related to jBPM


                            The PVM is an improvement of jBPM but not related to the API


                            The jBPM4 project is expected to take part in the JBossBPM API design and eventually provide an implementation of it.

                            • 11. Re: Making the BPM API more generic?
                              thomas.diesler

                              Mark


                              This api will be able to wrap, to some degree, other process engine apis. Our PVM will also be capable of executing their models. As proof of concepts krisv has done partial implementations for BPEL, OSWorkfow and jBPM. BPEL runtime is almost complete (Drools is able to execute most examples), although it has not been wired up to WS and still needs work on XML assignment issues. OSWorkflow and jBPM runtime mappings are about 70% complete.


                              Whow ... so its high time we actually get together and consolidate what can get consolidated. I'd like to present you and Kris our ideas show you whats there and line up roadmaps.

                              Lets take this off-line and try to find a way to get together.

                              • 12. Re: Making the BPM API more generic?
                                tom.baeyens

                                 

                                "thomas.diesler@jboss.com" wrote:
                                The jBPM4 project is expected to take part in the JBossBPM API design and eventually provide an implementation of it.


                                The project efforts in jBPM 4 for client API will be concentrated around the PVM API and if the product wants to do something else, it will have to be done in a separate space. Not in the jBPM coderepositories, forums, wikis, mailing lists, jira.

                                • 13. Re: Making the BPM API more generic?
                                  kukeltje

                                  +1