2 Replies Latest reply on Aug 14, 2006 4:19 PM by kukeltje

    process deployment from WAR file

    kukeltje

      The way processes have to be deployed now, does not realy fit our procedures and the way we use processes. Let me explain.

      A process with the versioned classes and taskforms is part of a bigger web application. Most of this is not versioned in the way jBPM processes are. So most of the webapplication is in a war file:
      - other pages
      - images
      - resource files
      - roles (in web.xml)
      - ....

      and in a separate file the process info.

      Now if I look at the structure the process eclipse is getting, it's looking more and more like a war file

      war:

      /WEB-INF/web.xml
      /META-INF/
      /WEB-INF/lib/...
      /WEB-INF/classes/OwnClass.class
      /myPage.html
      



      processArchive
      /processdefinition.xml
      /classes/my/OwnClass.class
      /form1.xhtml
      


      There was a discussion on versioning and there is an issue in jira on using the context classloader in jBPM

      What I'm thinking about is is putting all the relevant information in a war file and generating a hash of all these files and this into a total hash

      In the warfile is a reference to a deployservlet (so this should be in EACH web.xml in EACH war file), which takes this total hash and compares it with a stored hash, if it differs the new process is deployed, in combination with all classes, forms etc...

      The challenge is to give each war file a unique context. So each version of the process get's it's unique url, but in such a way that the jbpm engine can determine what it should be. This is needed for having the web-console still work (otoh, should it? Wasn't it meant for RAD? not full APPS?) The unique urls could either be done by deploying as an ear, where you can have files (application.xml) which define the context of war files in it, or a unique name for the war file. Using the hash for this would be a nice solution.

      There are lots of other advantages to this (imo) e.g. an expanded deployment where the form files are not read from the db, but from the war structure. Just changing one .xhtml file and not 'deploy' the new process (since just a page changed) would make it instantly available and reduces the times deployment is needed by a huge amount.

      Maybe there are other advantages and even disadvantages. So please lets discuss those here. These were just my initial thoughts.





        • 1. Re: process deployment from WAR file
          tom.baeyens

          i'll rephrase to see if i get you correctly:

          You want to make a process archive a part of the deployment structure (=available to the classloader or in a deployment directory). Then, you want to discover all the deployed process archives on the deployment directory and deploy them to the jbpm db. The hashing of process archives is the solution you propose for making the distinction between processes that are already deployed and processes that need to be (re)deployed. This to overcome the difference in lifecycle of a deployed process versus the java/webapp deployment lifecycle.

          right ?

          in the recent drools discussions, i realized that there are many ways to go from sources to deployments and developers are used to the different java deployment strategies. In more general terms: I'm still looking at how we can create a unified deployment model that would provide a similar picture to java, servlet, process, rules and other deployments.

          It seems that we're now trying to embed our deployment model in the known existing deployment models, rather then to try and unify all of them.

          • 2. Re: process deployment from WAR file
            kukeltje

             

            "tom.baeyens@jboss.com" wrote:
            i'll rephrase to see if i get you correctly:

            You want to make a process archive a part of the deployment structure (=available to the classloader or in a deployment directory).

            Yes

            "tom.baeyens@jboss.com" wrote:
            Then, you want to discover all the deployed process archives on the deployment directory and deploy them to the jbpm db.

            No, I was thinking to have a servlet configured in this specific war (the code of the servlet is in the generic jbpm.jar if that works, or a small jbpm-deploy.jar in the WEB-INF/lib). This startup servlet gets the pd from the WEB-INF and deploys it to the db. But if what you propose can be done in a generic (App server independent) way, I'm all for it.

            "tom.baeyens@jboss.com" wrote:
            The hashing of process archives is the solution you propose for making the distinction between processes that are already deployed and processes that need to be (re)deployed. This to overcome the difference in lifecycle of a deployed process versus the java/webapp deployment lifecycle.

            Correct

            "tom.baeyens@jboss.com" wrote:
            right?

            Most of it (or all if the second question goes in your favour)

            "tom.baeyens@jboss.com" wrote:
            in the recent drools discussions, i realized that there are many ways to go from sources to deployments and developers are used to the different java deployment strategies. In more general terms: I'm still looking at how we can create a unified deployment model that would provide a similar picture to java, servlet, process, rules and other deployments.

            It seems that we're now trying to embed our deployment model in the known existing deployment models, rather then to try and unify all of them.



            Correct, if rules come into play that is another level, and what to think of services on the ESB?

            Configuration management only gets more and more difficult. Where is the good old one ear deployment. 20MB, everything in it. :-)))