7 Replies Latest reply on Sep 3, 2009 9:37 AM by Jim Dwyer

    jBPM4  - Remote Service interface

    Jim Dwyer Novice

      We are currently running a stand alone Tomcat server outside of JBoss. We were trying not to disturb this working system but would like to access a jBPM engine running in JBoss.

      Does jBPM 4 offer remote interfaces for RepositoryService, ExecutionService and such? I have looked at the gwt-console-server web services but that doesn't seem like the right way to go.

      PS I realize we could run jBPM in Tomcat but our long term architecture is to have jBPM in JBoss. I also realize we could run the web apps in the Tomcat in JBoss but once again the long term doesn't support that move.

      Thanks for your help


        • 1. Re: jBPM4  - Remote Service interface
          Jim Dwyer Novice

          RemoteCommandExecutor? I believe that is probably the answer.

          • 2. Re: jBPM4  - Remote Service interface
            Joram Barrez Master

            You can use the RemoteCommandExecutor for sure, but the downside of this solution is that you can't use the standard API's (executionService, taskService, etc).

            The REST service offered by the console can be used, but it is by far not as powerful as the service API.

            Imo, the easiest approach is constructing a ProcessEngine on Tomcat, where the jbpm config is pointing to the same DB as the one on JBoss.

            • 3. Re: jBPM4  - Remote Service interface
              Jim Dwyer Novice

              That is an interesting suggestion. Do you see any downside to having 2 ProcessEngines running? (1 on Tomcat and 1 on JBoss) The only thing I can think of that would be an issue is communicating with external systems. By having multiple ProcessEngines it starts to complicate the architecture. But not that much really.



              • 4. Re: jBPM4  - Remote Service interface
                Joram Barrez Master

                The only downside is that your config is repeated twice (once on tomcat, once on JBoss).

                Imo, if there is a communication problem with external systems, than there is a problem in the architecture ;-)

                The biggest plus for having separate process engines is that each instance can be controlled on its on. Say you want to migrate the tomcat version to another DB, or upgrade the tomcat version only, than this approach lets you do exactly that.

                • 5. Re: jBPM4  - Remote Service interface
                  Jim Dwyer Novice

                  Right. Unfortunately we already have jBPM3 running on the same Tomcat. We are using Alfresco and it is embedded in their product. We are trying to move away from from Alfrescos jBPM because of poor integration in our opinion.

                  As far as the communications I was referring to external systems sending notifications back to jBPM. Which ProcessEngine will receive the notifications? But it is minor.

                  Thanks for your input. We will discuss this and figure something out.

                  • 6. Re: jBPM4  - Remote Service interface
                    Joram Barrez Master

                    There should be no problem in running jBPM3 next to jBPM4.

                    For notifications, you'll need to allow for a unique endpoint for your processengine, that's all.

                    • 7. Re: jBPM4  - Remote Service interface
                      Jim Dwyer Novice

                      OK. Will look at running jBPM3 and jBPM4 on Tomcat. That might solve some other issues.

                      My fear of running two ProcessEngines is that one of them is really the main ProcessEngine the other is secondary. The main ProcessEngine would deal with all external comms, and be the central point of contact. I can see, an have too often in my 20 years or so doing this, somebody coming along in 6 months and using the secondary ProcessEngine as the main engine and totally wrecking any architecture that was set up. I realize that this is a management issue but if you don't introduce the second ProcessEngine the problem can't arise. This is one way to manage complexity. I like to keep it simple. One ProcessEngine is enough for our needs. With that said I am still going to look at using two engines because the API is better.