RemoteCommandExecutor? I believe that is probably the answer.
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.
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.
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.
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.
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.
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.