1 2 Previous Next 27 Replies Latest reply on Jun 12, 2008 4:09 AM by Ronald van Kuijk

    renaming PvmService to ProcessService

    Tom Baeyens Master

      i guess that name is much more applicable.

      comments ?

        • 1. Re: renaming PvmService to ProcessService
          Tom Baeyens Master

          Another thing that IMO improves the interface is by hiding the environment factory.

          In the API's that we'll expose to the user, there is only one way of making use of the environment. That is by using a XxxService session facade. In the default API, users are not supposed to work with environment factories and environment blocks themselves. That will be only the allowed as a back door in the internal API's.

          So instead of doing something like

          EnvironmentFactory environmentFactory = EnvironmentFactory.parseResource("environment.cfg.xml");
          ProcessService processService = environmentFactory.get(ProcessService.class);


          I think we should make the ProcessService an abstract class and expose an interface like this:

          ProcessService processService = ProcessService.getInstance();


          with multiple getInstance methods so that it's possible to work with 2 different PVM installations in one program.

          ProcessService.getInstanceResource(String);
          ProcessService.getInstanceInputStream(InputStream);
          ProcessService.getInstanceUrl(URL);
          ProcessService.getInstanceFile(File);
          ...


          after that it will be up to the ProcessService to clean up the static cached object when it closes

          public abstract class ProcessService {
           ...
           public void close() {
           1) close this process service
           2) remove this process service from the instances cache
           }
          }


          comments ?

          • 2. Re: renaming PvmService to ProcessService
            Tom Baeyens Master

            As a part of this EnvironmentParser and EnvironmentFactory would move to package org.jbpm.pvm.internal.env

            • 3. Re: renaming PvmService to ProcessService
              Joram Barrez Master

              After inspecting the interface operations,
              I do find 'processService' a far more logical name since all the operations are process related.

              Im happy to see this interface, these kinds of operations I used to put into my 'CommonWfmService' if you can remember from in Dublin. So, having it in the framework is great :-)


              Small remark: The javadoc for this interface is 'session facade interface for the Process Virtual Machine'

              --> I believe that a session facade is not the correct term for this interface (see http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html). It is possible that there is no notion of a 'session' when using the interface, so the javadoc does not make sense then.

              I would write something like 'Service interface exposing process operations' or something more refined

              • 4. Re: renaming PvmService to ProcessService
                Tom Baeyens Master

                i agree and will read the session facade pattern again :-)

                • 5. Re: renaming PvmService to ProcessService
                  Joram Barrez Master

                  Concerning the getInstance() approach:

                  with multiple getInstance methods so that it's possible to work with 2 different PVM installations in one program.


                  --> What do you mean? Is this programmatically possible? What is the use case (instead of 'because we can' :p)

                  I'm not a big fan of the Singleton getInstance() approach, since it creates some problems when using IoC containers like Spring, which use the constructor to instantiate beans.

                  So, please enlighten my darkened vision :-)

                  • 6. Re: renaming PvmService to ProcessService
                    Joram Barrez Master

                    Another question:

                    why should the service be retrieved from the environmentFactory: for getting the right dependencies or am I missing something?

                    • 7. Re: renaming PvmService to ProcessService
                      Tom Baeyens Master

                      It's the same use case as when you want to work with 2 distinct databases, resulting in 2 datasources and 2 connections.

                      This doesn't happen a lot, but I think we can't support it.

                      A concrete use case might be scaling: Splitting the processes over multiple installations. An oracle DB might run all the high demand processes. And one postgresql backed DB that runs the majority of the normal demand processes.

                      Another concrete use case might be conversion.

                      Another might be that each department in an organisation might have it's own jBPM installation. Now that from inside an order processing process you want to signal or kick off a sales process.

                      • 8. Re: renaming PvmService to ProcessService
                        Tom Baeyens Master

                         

                        "jbarrez" wrote:
                        I'm not a big fan of the Singleton getInstance() approach, since it creates some problems when using IoC containers like Spring, which use the constructor to instantiate beans.


                        I would guess that in case of spring, that replaces the getInstance. In the spring case you'ld obtain the ProcessService from the spring container. It's up to the spring container to instantiate and wire the concrete implementation.

                        • 9. Re: renaming PvmService to ProcessService
                          Bernd Ruecker Master

                           

                          it's possible to work with 2 different PVM installations in one program.

                          The best use case is if you have different client versions running on the same server.

                          • 10. Re: renaming PvmService to ProcessService
                            Tom Baeyens Master

                             

                            "jbarrez" wrote:
                            why should the service be retrieved from the environmentFactory: for getting the right dependencies or am I missing something?


                            i came to the same question as you ask. i came to realize that the environmentFactory was only in the API because of the design background.

                            EnvironmentFactory and Environment would correspond to what spring does. Instantiating and wiring objects in multiple contexts (=scopes). The EnvironmentFactory corresponds to the spring singleton scope. The scope of the environment is between the openEnvironment and the environment.close() which is supposed to be put in a try-finally block. Not sure what the corresponding spring scope is there.

                            so the proposal i made here was to remove the environmentFactory from the client api and only work with ProcessService.

                            but there has to be some way on how to obtain a concrete ProcessService object based on a configuration. how would you do it if you wouldn't use a singleton method ?

                            • 11. Re: renaming PvmService to ProcessService
                              Tom Baeyens Master

                               

                              "camunda" wrote:
                              it's possible to work with 2 different PVM installations in one program.

                              The best use case is if you have different client versions running on the same server.


                              Bernd, could you elaborate. I don't get this use case yet.

                              • 12. Re: renaming PvmService to ProcessService
                                Bernd Ruecker Master

                                If you have an application with jBPM involved. Thos is hosted on your own server, but you have different clients which can customize their version of the processes and so on.

                                Normally you want to set up an own jBPM instance for every client, but maybe keep it in one ear... So the functionality of loading different jBPM instances is interessting here I think.

                                And I agree on the other use case of migration...

                                • 13. Re: renaming PvmService to ProcessService
                                  Tom Baeyens Master

                                  now i get it. and i agree that it is a valid use case and even more common then the ones that i mentioned.

                                  • 14. Re: renaming PvmService to ProcessService
                                    Joram Barrez Master

                                    Tom & Bernd, thanks for the good use case descriptions.

                                    I hadn't thought about it on that level, but it does make sense now. Especially the migration use case is very interesting.

                                    Tom, I've been going through the env package source and I understand your problem now. Great and very clear javadoc documentation by the way, there is some good stuff in there.


                                    These are my ideas:

                                    - Getting rid of the envFactory for instantiating the processService is a very good idea!

                                    - I think that having a getInstance() method is indeed the best option there is here, if using a constructor is not feasable (for caching?).

                                    - Can't the Environment.getCurrentEnvironment() be used in combination with a getInstance()/constructor?

                                    Environment env = Environment.getCurrentEnvironment();
                                    try {
                                     processService.do()
                                    finally {
                                     env.close();
                                    }


                                    This would mean off course that calling the processService should always be done in an environment block, which also means you don't have to call the several getInstance() methods anymore.

                                    I'm just writing this last option down to see if there is no other way of implementing it, perhaps there are implications I don't see yet.

                                    1 2 Previous Next