10 Replies Latest reply on Nov 21, 2008 7:35 AM by thomas.diesler

    Classloader-Registry in AS/ESB allows one central jbpm insta

    camunda

      Hi all!

      As mentioned in earlier posts I look into class loading issues at the moment. For the current project I proposed a solution, which I quickly sketched into this PDF:

      http://www.camunda.com/content/jbpm/esb/jbpm-esb-classloading.pdf

      Hopefully you get the idea from it?

      By doing it like this, we solved all classloading issues within the ESB/jBPM combination, even with scoped deployments. And the console is working for all processes out of the box. And we don't have to include jbpm jars in every ear and also don't have to put anythin in lib directories (which wouldn't be possible because of different deployed versions).

      What do you think of this? Feedback, Comments?

      How about contributing this back? Would this be part of the ESB? I think so... So I think I do a crossposting in the ESB forum (Sorry Ronald ;-)).

      The Code and the changes aren't that complicated and working here in a JBoss ESB 3.3, even if it is not completely finished yet...

      Cheers
      Bernd

        • 1. Re: Classloader-Registry in AS/ESB allows one central jbpm i
          kukeltje

           

          So I think I do a crossposting in the ESB forum (Sorry Ronald ;-)).


          I'm not subscribed to the esb forum, so I do not mind :-P

          Regarding your proposal, You mention something about not deploying classes to the database but to a classpath. Are you thinking about some other way of versioning then or ditch it at all?



          • 2. Re: Classloader-Registry in AS/ESB allows one central jbpm i
            kukeltje

            Sorry, to short a statement.... some additions

            It is not the just the versioning of processdefinitions but screens (or even pageflows) for tasks (which in the current solution is only viable to be used in demo situations)

            It is a more generic problem than just jBPM. So maybe we could come up with something together with the seam guys which are more knowledgable about the frontend.

            • 3. Re: Classloader-Registry in AS/ESB allows one central jbpm i
              camunda

              In our current project we have the following concept for versioning (sorry for not posting that the first place):

              Versioning is applied to applications and services, normally correspond to one EAR (with Java classes, maybe web pages, wsdl, whatever. Depends on the kind of service). There are two versioning schemes:

              1.) Major Versions: Bigger changes. These may be not compatible. New major versions may be run in parallel to older services.

              2.) Minor versions = patches. These are patches, bug fixes or compatible changes. New Minor versions replace the existing service.

              The EAR includes the version in its name, so all beans and stuff include the version in the JNDI-Name. jBPM-processes are included in this EAR. New major versions will create new processdefinition names (basically the version is added to the process name, e.g. "websale_3"). "Normal" jbpm versioning is only applied on patch level.

              It is a more generic problem than just jBPM.


              Exactly, normally you have to take care of versioning for a lot of artefacts, so I think this solution makes sense... And I like having bytecode and classpath stuff in EAR files more than in the jBPM database...

              So maybe we could come up with something together with the seam guys


              Yeah, maybe. But I think it is not only seam, but much more. Especially if you look into the direction of the ESB with whatever services connected to it. This direction (to the backend) is also very interessting.

              • 4. Re: Classloader-Registry in AS/ESB allows one central jbpm i
                kukeltje

                 

                "camunda" wrote:

                Versioning is applied to applications and services, normally correspond to one EAR (with Java classes, maybe web pages, wsdl, whatever. Depends on the kind of service). There are two versioning schemes:

                1.) Major Versions: Bigger changes. These may be not compatible. New major versions may be run in parallel to older services.

                2.) Minor versions = patches. These are patches, bug fixes or compatible changes. New Minor versions replace the existing service.


                Ok, clear. Would be my take to.

                "camunda" wrote:

                The EAR includes the version in its name, so all beans and stuff include the version in the JNDI-Name.

                You do this manually (deploy time), manually (design time) or is this some automagic JBoss AS feature?

                "camunda" wrote:

                jBPM-processes are included in this EAR. New major versions will create new processdefinition names (basically the version is added to the process name, e.g. "websale_3").

                Again, do you do this deploy time or designtime?

                "camunda" wrote:

                "Normal" jbpm versioning is only applied on patch level.

                Ok, makes me even more curious how you achieve this. The high-level take on it is clear, now the devil^W details ;-)

                "camunda" wrote:

                It is a more generic problem than just jBPM.


                Exactly, normally you have to take care of versioning for a lot of artefacts, so I think this solution makes sense... And I like having bytecode and classpath stuff in EAR files more than in the jBPM database...

                It does make sense, I miss one thing though but I'll talk about that in the end.
                "camunda" wrote:


                So maybe we could come up with something together with the seam guys


                Yeah, maybe. But I think it is not only seam, but much more. Especially if you look into the direction of the ESB with whatever services connected to it. This direction (to the backend) is also very interessting.


                You are right, but currently I am (was) focussing on the web side of things.

                How do you run multiple major versions next to eachother? Suppose I have App A-v1 (version 1) on http://myhost/AppA. That is easy to run. But now comes AppA-v2, an incompatible major release. Running this on http://myhost/AppA. is not possible since we already have AppA-v1 there, so something more advanced needs to take place.

                One thing I came upo with (and I do not know all the disadvantages yet, or alternatives, so please shoot) is to have an AppA 'wrapper' which contains things like showing tasklist (since our customers do not want to use to different 'apps' because there are newer versions), basic navigation etc which is a war by itself running on url http://myhost/AppA. The 'versioned' parts are in separate deployable artifacts (war or ear) running on urls like http://myhost/AppA-v1 or http://myhost/AppA-v2 of which the wrapper has knowledge via some defined schema so it can make a link directly to a task. But there probably needs to be some kind of 'TaskHandlingPageUrlService' to retrieve that.

                I'll not go into it any further now and just let you guys shoot... But I do think there needs to be some more generic mechanism for all this Gourvernance stuff...



                • 5. Re: Classloader-Registry in AS/ESB allows one central jbpm i
                  camunda

                  I described the solution which works for our current project now in a bit more details:

                  http://www.camunda.com/knowledge/jbpm_deployer_for_enterprise_environment.html

                  [quote from ESB forum]
                  The current codebase appears to be based on the premise that each jBPM instance is standalone and co-located with the code running within the system


                  I agree! We got rid of it with the described solution and something similar should find its way into the SOA platform I think...

                  But seems to be the first task to define which project is responsible for this type of functionality (jBPM? ESB? ..?)...

                  How do you run multiple major versions next to eachother?


                  • 6. Re: Classloader-Registry in AS/ESB allows one central jbpm i
                    camunda

                    Forum swallowed the rest, here it is:

                    I think this is really out of scope of jBPM itself. The question for jBPM to solve is how to support what the people want to do in terms of classloading and how to align jbpm versioning (or life cycle) with the app/esb versioning...

                    Cheers
                    Bernd

                    • 8. Re: Classloader-Registry in AS/ESB allows one central jbpm i
                      thomas.diesler
                      • 9. Re: Classloader-Registry in AS/ESB allows one central jbpm i
                        camunda

                        You are right, this was just a first shot. But the information was moved into this blog entry: http://www.bpm-guide.de/2008/10/16/jbpm-deployer-for-jbpm-in-enterprise-environments/

                        • 10. Re: Classloader-Registry in AS/ESB allows one central jbpm i
                          thomas.diesler

                          merci (f)