1 2 Previous Next 27 Replies Latest reply on Aug 12, 2006 10:55 AM by Ronald van Kuijk

    versioning and auto deployment of processes

    Tom Baeyens Master

      The problem
      When starting a process execution in jBPM, this is typically done in the latest version of the process of a given name.

      Currently, jBPM is responsible for assigning version numbers during the deployment of a process archive. So there is no relation between the process deployment and jboss server lifecycle. That is why currently it is a manual process and there is no automatic deployer for jBPM processes.

      This is hard to match with the JBoss deployer architecture. A JBoss deployer will deploy every deployable file at boot time (each time).

      Another consideration is that the solution should be easy for organisations that have split development from their production environment. In that scenario, the development team provides to the production guys a process archive and a description on how to deploy it on to the production system.

      Also backup and restore of a whole jboss server (including the processes) should be taken into account. The JBoss way is that a server configuration contains all software and configurations that defines the whole server behaviour. In the case of jBPM, the processes are part of that and those must live in the database.

      I'm looking into writing a JBoss deployer or other mechanism that can cope with this situation. There are 3 approaches that i can think of:

      Alternative 1) Using the webconsole
      A web console could list all the process definitions in a process deploy directory. Then an admin can just click on any of those processes for them to be deployed. This mechanism would not necessary need a JBoss Deployer.

      Alternative 2) Adding a deployment file timestamp and/or file-hash
      I suppose that the deployer can get a hold of the file descriptor (right?). So during deployment, the jBPM could get the file timestamp and add it to the process in the database. Similarly, a hash of the whole process archive file could be added to the process definition in the database. So that on subsequent scans and reboots, the jbpm archive deployer can compare the process archive in the deploy folder with the latest process definition in the jBPM database.

      Alternative 3) Adding a version attribute
      An optional 'version' attribute should be added to the 'process-definition' element. During deployment, jBPM will check wether this attribute is set.

      If a version is specified, jBPM will only deploy the process if the given version number is higher then the current highest version for process definitions with the same name. Otherwise, a log message should say that the deployment is ignored because a newer version is present in the jBPM system.

      If a version is not specified, things will remain as they are. Meaning that a version number will be assigned by jBPM.

      regards, tom.

        • 1. Re: versioning and auto deployment of processes
          Konstantin Kolev Newbie

          If you allow me I would like to share my unpretended opinion.
          I best like Alternative 2 with the file-hash.
          The arguments about are that process definition is considered changed if something in its real nature changes, if the sense of the business process changes. For example: a new node has been added, the name of a node has changed, a new transition has been added, the code of an action handler has changed. This imo is the sense of a new version of process definition, this means that a new version has been introduced, that brings as a matter of principle new meaning and functionality. Another argument is that the check that something has changed is reduced to a simple equality comparison.
          Also it doesn't matter who is deploying the process definition. That's why the concept of

          process definition deployer
          seems a good idea as for now.
          P.S. Actually we've been put the problem with process definition identity before and we even wrote our own ProcessDefinitionComparator.
          P.S. My words about code change of an action handler aplly to the situation of persisting the hash of a process archive, not the XML process definition.

          • 2. Re: versioning and auto deployment of processes
            Elias Ross Master


            I like 3 the most.

            2 is unreliable, since it relies on timestamping of files, and then you have to sweat it if somehow your timestamp changed on the older version when doing a copy.

            1 is not automatic.

            • 3. Re: versioning and auto deployment of processes
              Rainer Alfoeldi Novice

              Hi all,

              my 5 cents?

              1) doesn't work unless you have a web app (not all of us have one)

              3) doesn't work :-) believe me. I've implemented this and it happens at least 3-4 times a week that I forget to update the version value. It has to be automatic.

              2) the way to go. Not timestamp based but hash key based. This IS what you would want. The system recognizes that the processDefinition has changed and updates accordingly. Nothing to forget, failsafe even for types like myself.

              Greetings

              Rainer

              • 4. Re: versioning and auto deployment of processes
                Scott Stark Master

                A deployer is the double-click action for a file in the server deploy directory. Deployment of an ejb-jar with entities has behavior externalized to the database used by the entities. Your process definition deployment should have whatever info is needed to uniquely identify the process to deployment, or associate in case the process archive already has an active workflow.

                • 5. Re: versioning and auto deployment of processes
                  Scott Stark Master

                  The main issue for me is that its not clear that the deployer should ever start a workflow. I would view it as simply the means by which jbpm is integrated into jboss, and its process definition archive is a way for users to tell jbpm they want to be associated with one or more process definitions. I would expect the application deals with multiple versions of of one or more process definitions. A one-to-one correspondence between a process definition arechive and a workflow instance is not something I would expect the jbpm deployer to manage.

                  • 6. Re: versioning and auto deployment of processes
                    Scott Stark Master

                    Maybe a JCA abstraction is a better integration option. jbpm is deployed as a rar and process definition factories are defined that allow workflow instances to be created/attached.

                    • 7. Re: versioning and auto deployment of processes
                      Alejandro Guizar Master

                      So the process definition becomes the resource manager connection factory, with process instances acting as connections? JCA connections have no identity outside a specific conversation, whereas process instances do. Can you elaborate on the JCA analogy, Scott?

                      • 8. Re: versioning and auto deployment of processes
                        Tom Baeyens Master

                        scott,

                        my explanation wasn't very good. this should fill in some details:

                        a process definition is stored in the database. one process definition can have many executions (=process instances).

                        each process definition has a name and a version. currently, jbpm increments and assigns that version number. each process definition is completely separated from any other process definition. also different versions of the process definitions with the same name are completely separate.

                        ! So redeploying the same process definition again will result in a completely new process definition in the database. Redeploying the same process multiple times is higly undesirable. It will create multiple completely identical process definitions in the jbpm db. Apart from being inefficient, this is also problematic for collecting statistics.

                        the API to work with jBPM is very similar to hibernate: a factory (JbpmConfiguration) and a session (JbpmContext)

                        when users want to start a new process definition they can query the db for the latest version of a process with a given name.

                        So in my opinion, we should use a web admin console to perform. We could identify a deploy/process folder which does not automatically deploy, but shows the processes in the jbpm web admin. then the admin can decide when to deploy. This also gives a future path towards migrating process executions from one process definition to another. That will need an admin webapp as well.

                        I definitely see other integration points with JBoss:
                        * deploy jbpm as a service archive that publishes the factory (JbpmConfiguration) somewhere in JNDI. this is already done.
                        * plug in JBossMessaging for jbpm message service
                        * see if we can make the scheduler work with the jboss timer service
                        * making sure this all works properly in a clustered environment

                        regards, tom.

                        • 10. Re: versioning and auto deployment of processes
                          Nick Nickolov Newbie

                          Er... I meant alternative 2, with a hash. A slip of the finger.

                          Nick

                          • 11. Re: versioning and auto deployment of processes
                            Scott Stark Master

                             

                            "alex.guizar@jboss.com" wrote:
                            So the process definition becomes the resource manager connection factory, with process instances acting as connections? JCA connections have no identity outside a specific conversation, whereas process instances do. Can you elaborate on the JCA analogy, Scott?

                            At its most basic JCA is just a connection factory that produces a connection. Both can be proprietary interfaces (as in unknown to JCA ala JMS, JDBC), or they be implementations of the detyped JDBC like CCI (which I have yet to see used because its just too abstract).

                            The connection factory is bound to a configuration based on the *-ds.xml used to deploy it. I don't know if this abstraction is meaningful for jbpm (have not read Tom's followup post yet).


                            • 12. Re: versioning and auto deployment of processes
                              Scott Stark Master

                               

                              "tom.baeyens@jboss.com" wrote:

                              ...
                              the API to work with jBPM is very similar to hibernate: a factory (JbpmConfiguration) and a session (JbpmContext)

                              when users want to start a new process definition they can query the db for the latest version of a process with a given name.
                              ...


                              Well, then it seems that a JCA/RAR is more approriate then a deployer because the configuration is not really an inherent aspect of the application as multiple application can share the same configuration (process definition).


                              • 13. Re: versioning and auto deployment of processes
                                Tom Baeyens Master

                                 

                                "scott.stark@jboss.org" wrote:

                                ...
                                Well, then it seems that a JCA/RAR is more approriate then a deployer because the configuration is not really an inherent aspect of the application as multiple application can share the same configuration (process definition).


                                Yes that could make sense. What is the advantage of developing a JCA .rar versus an MBean that puts the service factory in JNDI as we have now ?

                                regards, tom.

                                • 14. Re: versioning and auto deployment of processes
                                  Scott Stark Master

                                  Some benefits to JCA:

                                  1. Its a deployment format supported by all app servers
                                  2. Support for user's should be able to control how many active connections there are to the engine.
                                  3. Support for security/transaction context to associate with the connection.
                                  4. Support for integrating with the server thread pools for doing work.

                                  We have a new hire coming on in a couple of weeks that will be working in the JCA layer and could help with evaluating/implementing such an integration piece.

                                  1 2 Previous Next