1 2 3 Previous Next 35 Replies Latest reply on Jun 12, 2007 3:03 PM by bill.burke

    Rework of jBPM deployment within JBoss

    bill.burke

      I'm reworking the JBoss+jBPM configuration and deployment structure:

      1. The hibernate and jbpm xml files are embedded deep within the enterprise archive. These need to be moved up for easy edits by the user

      2. Getting up and started with jBPM is painful in a JBoss environment. (Please correct me on points here).

      a) You need to create the jBPM schema in the database
      b) You need to modify your ant build to save your .jpdl into the database so that the jBPM server can pick things up. OR you do some other manual or programmatic process to get your process definitions in the database.
      c) You need to copy and .jar files into the JBoss lib/ directory, WAR archive, or whatever.

      I want to create a ProcessDefinitionDeployer for jboss. This will work like the SAR, EJB, EAR, etc... deployers. Users would be able to deploy a .jar file named "xxx.bpm" or a foo.jpdl.xml file. The jar file would contain a "META-INF/jbpm.jpdl.xml" file within it and any classes that could possibily be used by the process definition.

      At deployment time, the JBPM deployer would calculate a hash for hte .xml file. If this hash matches a previously deployed .xml file nothing is done. If it is a new hash, a new version of the process definition is saved to the database.

      A new config structure would look like this:

      jbpm.deployer/
       hibernate.cfg.xml
       jbpm.cfg.xml
       jbpm-ds.xml
       jbpm-jpdl.jar
       jbpm-enterprise.ear
       META-INF/
       jboss-service.xml
      


        • 1. Re: Rework of jBPM deployment within JBoss
          kukeltje

          1. correct
          2. only partly true. Let me elaborate
          a) not to difficult, but the problem was that the identity scripts were separate. This has been fixed recently (in cvs and will be in 3.2.1)
          b) Right, or use the GPD
          c) depends on the jboss version. for 4.0.4.GA you can just deploy the jbpm-console war file and be up and running. The profiles in the build scripts should be adapted/expanded to cope with other versions. People expecting to deploy the war from the starterkit (4.0.4) in 4.2 have a problem because of jsf libs... I think addressing this is more important for JBoss

          A real process deployer would be great. This has been discussed in the forums before. The thing is that you need a kind of versioning to check if a processarchive should be redeployed after starting or not. See the versioning issues in jira

          Please allow me to address a separate issue. jBPM has its own identity module. To some extend it is similar to the one in the portal. People often do not get this login thing and that was the reason it was dropped from 3.0 compared to 2.0. In 3.2 (or was it 3.1) it was reintroduced, but lining up the portal usermanagement and the one from jBPM would be realy nice. Maybe the usermanagement part should be a separate project (combine it with the sso?). This way both jBPM and portal can take separate advantage of it, but at the same time be compatible...

          • 2. Re: Rework of jBPM deployment within JBoss
            dmlloyd

             

            "bill.burke@jboss.com" wrote:
            I'm reworking the JBoss+jBPM configuration and deployment structure:
            (...)
            2. Getting up and started with jBPM is painful in a JBoss environment.
            (...)
            b) You need to modify your ant build to save your .jpdl into the database so that the jBPM server can pick things up. OR you do some other manual or programmatic process to get your process definitions in the database.


            You can deploy process definitions using the web console or graphical process designer as well, but yeah...

            "bill.burke@jboss.com" wrote:
            I want to create a ProcessDefinitionDeployer for jboss. This will work like the SAR, EJB, EAR, etc... deployers. Users would be able to deploy a .jar file named "xxx.bpm" or a foo.jpdl.xml file. The jar file would contain a "META-INF/jbpm.jpdl.xml" file within it and any classes that could possibily be used by the process definition.


            At deployment time, the JBPM deployer would calculate a hash for hte .xml file. If this hash matches a previously deployed .xml file nothing is done. If it is a new hash, a new version of the process definition is saved to the database.

            • 3. Re: Rework of jBPM deployment within JBoss
              dmlloyd

              The forum (or my browser) ate my post, trying again...

              "bill.burke@jboss.com" wrote:
              I'm reworking the JBoss+jBPM configuration and deployment structure:
              (...)
              2. Getting up and started with jBPM is painful in a JBoss environment.
              (...)
              b) You need to modify your ant build to save your .jpdl into the database so that the jBPM server can pick things up. OR you do some other manual or programmatic process to get your process definitions in the database.


              You can deploy process definitions using the web console or graphical process designer as well, but yeah...

              "bill.burke@jboss.com" wrote:
              I want to create a ProcessDefinitionDeployer for jboss. This will work like the SAR, EJB, EAR, etc... deployers. Users would be able to deploy a .jar file named "xxx.bpm" or a foo.jpdl.xml file. The jar file would contain a "META-INF/jbpm.jpdl.xml" file within it and any classes that could possibily be used by the process definition.

              At deployment time, the JBPM deployer would calculate a hash for hte .xml file. If this hash matches a previously deployed .xml file nothing is done. If it is a new hash, a new version of the process definition is saved to the database.


              I think this is a good idea. Though I've always disagreed with storing the process archive (especially the classes) in the database. If you're going to make a file-based deployer, it would be much better to just load the archive's classes the normal way in my opinion. The database ought to hold just enough of the graph structure to define the structure of the process and provide relations with its instances, and that's it.

              Also this is something that has always bothered me a bit - process versioning. If the user has a process that is deployed into production, and there is a bug discovered after deployment, say a coding error like an NPE, the user cannot deploy a replacement process. They must deploy a new version, and manually (because there is no automated way) convert each running process instance over to the new process version.

              Your method of hashing the xml file would improve that substantially since coding bugs can be corrected. I'm not so sure that hashing the XML file would be the best solution though - I think it might be better generate a hash off of the actual semantic graph structure (since it's really changes in the graph structure that would *require* a new version), and also an (optional?) user-supplied version number (in case they want to deploy a new version of a process that has the same structure but maybe different java code behind it, so the XML file would otherwise be unchanged).


              • 4. Re: Rework of jBPM deployment within JBoss
                kukeltje

                @david

                The process is more than the .xml file. It's also the versioned classes. So not only changes in the semantic graph structure, but also changes (which?) in the classfiles and other property/resource files should lead to a new version.

                • 5. Re: Rework of jBPM deployment within JBoss
                  kukeltje

                  oops, me did not read the last line of your latest post

                  • 6. Re: Rework of jBPM deployment within JBoss
                    dmlloyd

                     

                    "kukeltje" wrote:
                    @david

                    The process is more than the .xml file. It's also the versioned classes. So not only changes in the semantic graph structure, but also changes (which?) in the classfiles and other property/resource files should lead to a new version.


                    I don't completely agree - I think that the user should be able to control (to the extent that it is possible) whether or not a new version is created, for the reason I already gave - the ability to patch an already-deployed process to fix production problems.

                    • 7. Re: Rework of jBPM deployment within JBoss
                      kukeltje

                      I agree, that he/she should have the option, but that should also be the case for changes in the .xml file. (small typo's in some text e.g.) and what about the forms....

                      • 8. Re: Rework of jBPM deployment within JBoss
                        dmlloyd

                         

                        "kukeltje" wrote:
                        I agree, that he/she should have the option, but that should also be the case for changes in the .xml file. (small typo's in some text e.g.) and what about the forms....


                        Exactly. That's why I said to hash the semantic graph structure, rather than the file itself. The only change that absolutely requires a deployment of a new version is a change in the graph structure. For any other change, it should be controllable by the user whether a new version is deployed.

                        • 9. Re: Rework of jBPM deployment within JBoss
                          kukeltje

                          Question: Why should a new processarchive with an identical pd.xml file but new classes not always require a new deployment? This is related to the problem how to decide a class is new. (build clean gives you a new timestamp but is something else identical?)

                          • 10. Re: Rework of jBPM deployment within JBoss
                            dmlloyd

                            Imagine that a process was deployed, and thousands of people started using it. Now imagine that some Java action or something has a code bug that results in a RuntimeException, so thousands of process instances that have been begun cannot move forward. The developers should be able to replace that buggy Java code with a fixed version, which would then allow those process instances to continue execution. If a new version is produced, then someone has to manually migrate all those thousands of process instances to the new process version before they can move forward.

                            • 11. Re: Rework of jBPM deployment within JBoss
                              kukeltje

                              aaaahhhhh, sorry, we ware talking about deployment from two different perspectives. I was looking at the complete processarchive as a version. You just looked at the processdefinition.

                              Correct, by just replacing a classfile in combination with the same pd, no need for 'upgrading' processinstances to the newer one.

                              • 12. Re: Rework of jBPM deployment within JBoss
                                kukeltje

                                small addition: for me getting this new processarchive to the server is going through our deployment department, hence for me that was a deployment as well, but on a different level.

                                I have to go to bed, it is 02:32 AM now.....

                                • 13. Re: Rework of jBPM deployment within JBoss
                                  tom.baeyens

                                   

                                  "bill.burke@jboss.com" wrote:

                                  1. The hibernate and jbpm xml files are embedded deep within the enterprise archive. These need to be moved up for easy edits by the user


                                  one option could be to extract all the .hbm.xml files and put then in the config jar file. would that qualify as 'moved up' ?

                                  i definitely want at least something that is as portable as this solution. if there are jboss specific ways on how to move the configs even up further, i 'm ok with that as long as it's another option that we offer apart from the portable deployment.

                                  "bill.burke@jboss.com" wrote:

                                  a) You need to create the jBPM schema in the database


                                  Previously detection and update of the schema was done automatically in a .sar. But i want to move to a portable .rar for this. Would that be an option for you ?

                                  "bill.burke@jboss.com" wrote:

                                  b) You need to modify your ant build to save your .jpdl into the database so that the jBPM server can pick things up. OR you do some other manual or programmatic process to get your process definitions in the database.


                                  3 ways of deployment of which you mentioned already 2
                                  * ant task
                                  * API
                                  * file upload in the web console

                                  "bill.burke@jboss.com" wrote:

                                  c) You need to copy and .jar files into the JBoss lib/ directory, WAR archive, or whatever.


                                  i don't get what you are referring to here

                                  "bill.burke@jboss.com" wrote:

                                  I want to create a ProcessDefinitionDeployer for jboss. This will work like the SAR, EJB, EAR, etc... deployers. Users would be able to deploy a .jar file named "xxx.bpm" or a foo.jpdl.xml file. The jar file would contain a "META-INF/jbpm.jpdl.xml" file within it and any classes that could possibily be used by the process definition.


                                  process definition deployer: yes

                                  META-INF/jbpm.jpdl.xml: we already have a process archive format called process archive. though, we should rename it from .par to .process or something like that to prevent conflicts with the persistence archives.

                                  "bill.burke@jboss.com" wrote:

                                  At deployment time, the JBPM deployer would calculate a hash for hte .xml file. If this hash matches a previously deployed .xml file nothing is done. If it is a new hash, a new version of the process definition is saved to the database.


                                  hash in combination with the last update time of the file would be good, i think. i wouldn't trust hash only. chances are small for a collision, but imagine if you have such a collision, then you would have to make sure something in the file is changed to get it deployed.

                                  saving that info in the database is going to be tricky in 3.2.x as we only want to allow updates to the db schema between minor version releases. 3.3 is still some time out.

                                  but it can be done in 3.2.x with a file attachment (see processDefinition.getFileDefinition()) but the query to see if a process is already deployed is going to be based on a binary column... not sure if that is db portable.

                                  on the other hand, it will be a pain to manage separate tables for the jboss deployer i think.

                                  if we have lots of processes (avg would be 10-20 i guess with lots being more then 1000), what will this do to the startup time of jboss ?

                                  "bill.burke@jboss.com" wrote:

                                  A new config structure would look like this:

                                  jbpm.deployer/
                                   hibernate.cfg.xml
                                   jbpm.cfg.xml
                                   jbpm-ds.xml
                                   jbpm-jpdl.jar
                                   jbpm-enterprise.ear
                                   META-INF/
                                   jboss-service.xml
                                  


                                  that looks good. but consider JCA and a .rar to deploy jbpm separate on the appserver, apart from the deployer. then the .rar would be portable.

                                  • 14. Re: Rework of jBPM deployment within JBoss

                                     

                                    Though I've always disagreed with storing the process archive (especially the classes) in the database.


                                    Don't forget about clustering.

                                    I think that the user should be able to control (to the extent that it is possible) whether or not a new version is created


                                    Agreed, although it will be hard to explain and control expectations about what will work and what won't. For example, I think that many topological changes would work fine, but specifying that set of changes may be hard.

                                    -Ed Staub

                                    1 2 3 Previous Next