8 Replies Latest reply on Jun 18, 2007 12:14 PM by mvaldes

    new source code structuring

    tom.baeyens

      i have been analysing the dependencies and components. please check out the projectstructuring.txt and the corresponding jpg. is that a good strategy to start building the subprojects ?

      the projects/packages correspond to the highest level components on the diagram.

      i was the most in doubt about the task component. people might be interested in a task component without a process language. we could make that a separate component, but it has dependencies on variables, process logging and lax (wiring).

      my conclusion was that task management will not be used that often outside of the context of a process language. therefor, it is not that big of a problem if it is inside the process package.

      too much package separation will cause library fragmentation. so I really considered what could be made reusable separately.

        • 1. Re: new source code structuring
          charoy

          Hello,

          I'm quite sure of the opposite. Task management should be a service outside of the process language as much as possible. Of course, having a task component embedded in the process system may be useful but you should consider that tasks that are allocated to the task management service are not always coming from a single process engine.

          Moreover, constraints on task execution should be tailorable to the application domain (task management in a grid system for scientific applications is not the same as task management for an administrative environment).

          regards, françois

          • 2. Re: new source code structuring

            Sorry Tom, where can i find the file you are talking about?

            • 3. Re: new source code structuring
              tom.baeyens

              it's in the doc directory fo the lightning module.

              note that this is not about the jPDL 3.x source code. we're talking about jPDL 4.x source code that we're building in collaboration with Bull/Bonita/Orchestra people.

              • 4. Re: new source code structuring

                Hi Tom,

                Hereafter some comments on the project structure you proposed:

                * I will start with some general remarks.

                - The discussion on our side would be around the use of maven in addition/rather ? to/than ant.
                We have already discussed about that in one of the meetings but I would like to open this discussion again with all of you.

                I'm not an expert on maven but I think that the kind of features you described: libraries based on on-line repositories and profiles configuration can be done by leveraging maven so, after a discussion here with the team, the question is why not just use what maven offers rather than develop it on top of ant ? or another way to address this point would be: could we leverage other useful fonctionalities included in maven ?

                - Otherwise, we are agree that "profiles" is a good way to handle multiple "flavours" for our BPM solutions, we like that.

                - Regarding the integration framework we wanted to use Bamboo. This is the tool used by JOnAS folks and other Bull R&D projects so makes sense for us to use it as well for new Bonita and Orchestra versions (but this is our business)
                However, as the PVM + common services is hosted in Jboss, the integration tools to build those "common" projects can be the one you proposed (in this case the integration framework will also be hosted in Jboss). Do you already set up this infraestructure for Jbpm 3 ?

                - For the component default project layout (last entry on the ptojectstructure.txt file), we think that the packaging files should be inside a child directory of "target", let's call it "components".

                * On the projects structure and contents:

                - There is some confusion on our side about the project called "process". In your proposal, this would be composed by the PVM basics + logging + lob + variables + task (I will talk about this one later on)

                Why this project is not called PVM ? From a "marketing" point of view, the PVM is described as the micro-kernel to support multiple process languages (and this seems to be the case of the "Process" project). It would be great to be able to distribute the PVM as a jar file

                - Is the task part of this project or not ? we think that this module should be outside of this project but not included into the "lax" project (because it have some relationships with "Process"). In fact we see task at the same
                level that "notifications" or "identity" projects. This structure will allow to the Orchestra guys to do not include task in their package.

                From a workflow point of view, I see the task project as a basis for different human workflow solutions (JBPM, Bonita...). We can work together on this project and then extend it to better fit with our particular requirements (i.e adding the Bonita related entities to handle human tasks).

                François Charoy (from INRIA labs) proposed that as well. I guess François was thinking more in a particular use case for tasks in which the task management is somehow distributed among multiple workflow installations. In this situation, the task project would be also extended to be able to support distributed todo list. It would be great if Inria folks could work on that.

                - The name of the project "lax" (language extentions) is also somehow confussing for us, we see "services" or "resources" more appropiate as the name of this project.

                BTW, we like the idea of having a separate project that could be leveraged by other applications out of the scope of the PVM

                - We would like to propose a new project called "Service". This is the one providing web services capabilities as well as ESB integration. This will be used either by the BPEL implementations to handle web services interactions (if used standalone) or ESB interaction

                best regards,
                Miguel Valdes

                • 5. Re: new source code structuring
                  tom.baeyens

                   

                  "mvaldes" wrote:

                  - The discussion on our side would be around the use of maven in addition/rather ? to/than ant.
                  We have already discussed about that in one of the meetings but I would like to open this discussion again with all of you.

                  I'm not an expert on maven but I think that the kind of features you described: libraries based on on-line repositories and profiles configuration can be done by leveraging maven so, after a discussion here with the team, the question is why not just use what maven offers rather than develop it on top of ant ? or another way to address this point would be: could we leverage other useful fonctionalities included in maven ?



                  there are in fact 2 problems why i chose not to use maven before:

                  1) maven comes as a package. there's lots of things in there. also, maven by default has a lot of assumptions on how your project is structured.

                  2) everything can be tweaked and customized, but that is hard to say the least.

                  so that is why (jbpm.3) we opted for ant scripts that only copied the good part of maven: use of a local repository.

                  "mvaldes" wrote:


                  - Regarding the integration framework we wanted to use Bamboo. This is the tool used by JOnAS folks and other Bull R&D projects so makes sense for us to use it as well for new Bonita and Orchestra versions (but this is our business)
                  However, as the PVM + common services is hosted in Jboss, the integration tools to build those "common" projects can be the one you proposed (in this case the integration framework will also be hosted in Jboss). Do you already set up this infraestructure for Jbpm 3 ?



                  for jbpm.3 we just switched to hudson: http://dev45.qa.atl.jboss.com:8585/hudson/job/JBPM.3/

                  pretty cool.

                  but integration builds only need to be set up by 1 of the two companies. i don't care who does it. as long as it's done.

                  "mvaldes" wrote:

                  - There is some confusion on our side about the project called "process". In your proposal, this would be composed by the PVM basics + logging + lob + variables + task (I will talk about this one later on)

                  Why this project is not called PVM ? From a "marketing" point of view, the PVM is described as the micro-kernel to support multiple process languages (and this seems to be the case of the "Process" project). It would be great to be able to distribute the PVM as a jar file



                  pvm is better. along with the other feedback, i checked today if we can abstract out the task pieces from the process thing.

                  then the contents of this one component would be pvm.

                  so instead of components
                  jpdl
                  process | job
                  lax

                  we would get
                  jpdl | xpdl | bpel
                  pvm | task | job
                  lax

                  and the variables and large objects would move to lax

                  i'll update the picture, that's probably easier to see.

                  one thing: do you think lax (language extensions) is good ? or would you prefer the name common ?

                  "mvaldes" wrote:


                  - Is the task part of this project or not ? we think that this module should be outside of this project but not included into the "lax" project (because it have some relationships with "Process"). In fact we see task at the same
                  level that "notifications" or "identity" projects. This structure will allow to the Orchestra guys to do not include task in their package.



                  i agree. one thing is necessary, though. the process languages will have to inherit and extend the task component with a reference to an execution.

                  that would be the only direct link on pvm. without that direct link, the task component could be reusable ouside of a process context.

                  the process languages could then define an inherited task type.

                  "mvaldes" wrote:


                  From a workflow point of view, I see the task project as a basis for different human workflow solutions (JBPM, Bonita...). We can work together on this project and then extend it to better fit with our particular requirements (i.e adding the Bonita related entities to handle human tasks).



                  yes. although we have to think on how we can do this in a way that still supports combinations of jPDL and bonita to run together. especially in the db schema this might be tricky.

                  "mvaldes" wrote:


                  François Charoy (from INRIA labs) proposed that as well. I guess François was thinking more in a particular use case for tasks in which the task management is somehow distributed among multiple workflow installations. In this situation, the task project would be also extended to be able to support distributed todo list. It would be great if Inria folks could work on that.

                  [/quote

                  indeed, that would be great.

                  "mvaldes" wrote:


                  - The name of the project "lax" (language extentions) is also somehow confussing for us, we see "services" or "resources" more appropiate as the name of this project.

                  BTW, we like the idea of having a separate project that could be leveraged by other applications out of the scope of the PVM



                  what about base, common, or util ?

                  "mvaldes" wrote:


                  - We would like to propose a new project called "Service". This is the one providing web services capabilities as well as ESB integration. This will be used either by the BPEL implementations to handle web services interactions (if used standalone) or ESB interaction



                  i also think that our bpel impl should support http as well as ESB. both for the services published by a bpel process as well as the service invocations done from a bpel process.

                  but i don't see the reusable part yet.


                  • 6. Re: new source code structuring
                    charoy

                    I do confirm that the task management service is on our worklist together with distributed security and privacy although part of it may be very experimental and not ready for prime time release. I'll try to elaborate later. I need to get more into pvm first

                    françois

                    • 7. Re: new source code structuring
                      tom.baeyens

                      i'm putting the new proposed structure (without any of the classes, but with the build files) into a new tempranillo module in the repository. then we can review and discuss better.

                      as for the module named lax. i decided to keep it for now, to show it. the motivation is the jar name. for all the proposals mentioned, you can't really have a resources.jar or a services.jar. same for util.jar, base.jar or common.jar. but you can have a lax.jar

                      • 8. Re: new source code structuring

                         


                        there are in fact 2 problems why i chose not to use maven before:

                        1) maven comes as a package. there's lots of things in there. also, maven by default has a lot of assumptions on how your project is structured.

                        2) everything can be tweaked and customized, but that is hard to say the least.

                        so that is why (jbpm.3) we opted for ant scripts that only copied the good part of maven: use of a local repository.


                        If this is the only advantage of using maven I understand your point. I will also ask the question to the people on our team using maven to know their opinion... I will let you know.


                        for jbpm.3 we just switched to hudson: http://dev45.qa.atl.jboss.com:8585/hudson/job/JBPM.3/
                        pretty cool.
                        but integration builds only need to be set up by 1 of the two companies. i don't care who does it. as long as it's done.


                        As the PVM + services are hosted in Jboss I think that the best would be to use the tool you proposed (you already using it).
                        On our side we will use bamboo afterwards for our Orchestra and Bonita packages.


                        pvm is better. along with the other feedback, i checked today if we can abstract out the task pieces from the process thing.

                        then the contents of this one component would be pvm.

                        so instead of components
                        jpdl
                        process | job
                        lax

                        we would get
                        jpdl | xpdl | bpel
                        pvm | task | job
                        lax

                        and the variables and large objects would move to lax
                        i'll update the picture, that's probably easier to see.
                        one thing: do you think lax (language extensions) is good ? or would you prefer the name common ?


                        what about PVM Services as a new name for "lax" ? that way there is no problem with the jars

                        BTW, from your "tempranillo" proposition, we think that components jpdl, bpel and xpdl should be out this directory as they are extentions ??


                        i also think that our bpel impl should support http as well as ESB. both for the services published by a bpel process as well as the service invocations done from a bpel process.

                        but i don't see the reusable part yet.


                        To me, a reusable service is composed by an interface (in this case with some methods to sent and receive messages) as well as multiple implementations (one for axis, one for jboss messaging, one to sent normalized messages to a JBI ESB...)

                        regards,
                        Miguel Valdes