missing

[mgommeringer]

AFAIK, there is only one default destination for all async nodes (see org.jbpm.graph.def.Node and org.jbpm.command.ExecuteNodeCommand).
Since I'd like to use multiple CommandExecutorThread instances on different machines, I can configure them so that every CommandExecutorThread has its own destination:

CommandExecutorThread cet = new CommandExecutorThread(JbpmConfiguration.getInstance());
cet.setDestination("myDest");
cet.start();

But at the current state, this CommandExecutorThread will never receive a message because all generated async messages have the destination "CMD_EXECUTOR" (see org.jbpm.command.Command.DEFAULT_CMD_DESTINATION).
Is it planned to add an additional "destination" attribute to the "node" class which can be set for async nodes?
I would find this very useful.

[kukeltje]

Why would it be useful? Maybe I miss something, but if you could elaborate on this, we can see if it is indeed a musthave, couldhave, .... and what the priority is.

[mgommeringer]

Here is my scenario:

I have three computers in a network. The first 'computer1' initiates the workflow. The other two (computer2 and computer3) have different specific tasks which have to be executed at a specific node in the workflow (by the CommandExecutor). After these nodes were executed asynchronously (on computer2 and computer3), the CommandExecutor will give control back to computer1 which does the further processing.

(I did not find out how to upload an image to the forum pages, so I will write down the sequence of workflow steps as text here):

1. computer1: initialize workflow
2. computer1 <sends message to> computer2: execute specific node on computer2
3. computer2 <sends message to> computer1: process results on computer1
4. computer1 <sends message to> computer3: execute other specific node on computer3
5. computer3 <sends message to> computer1: process results again on computer1
6. computer1 does the further processing up to the end state

<?xml version="1.0" encoding="UTF-8"?>

<process-definition xmlns="" name="example">
 <!-- Initiate the workflow on computer1 -->
 <start-state name="start">
 <transition name="" to="node-external-computer2"></transition>
 </start-state>
 <!-- This node will be executed by the CommandExecutor on computer2 -->
 <node name="node-external-computer2" async="true" destination="computer2">
 <transition name="" to="process-result1"></transition>
 </node>
 <!-- This node will be executed on computer1 (the 'main-processor') -->
 <node name="process-result1" async="true" destination="computer1">
 <transition name="" to="node-external-computer3"></transition>
 </node>
 <!-- This node will be executed by the CommandExecutor on computer3 -->
 <node name="node-external-computer3" async="true" destination="computer3">
 <transition name="" to="process-result2"></transition>
 </node>
 <!-- This node will be executed on computer1 again -->
 <node name="process-result2" async="true" destination="computer1">
 <transition name="" to="end"></transition>
 </node>
 <end-state name="end"></end-state>
</process-definition>

Conceptually, i thought that all three computers have a CommandExecutor running with their specific destination.
In the current implementation of the asynchronous continuation, it is supposed that every node can be executed by an arbitrary CommandExecutor (if a clustered CommandExecutor would be implemented). In a distributed system, there are several external systems/services that only can execute the task they are made for (e.g. "get forecast for San Francisco"). So I think, that it should be possible to address a specific destination from the workflow so that only adequate CommandExecutors will receive the message.

It seems to be related to the jBPM Task, assigning different actors for every external computer. Only the way back from the external services to the "computer1" is not clear for me. Could I implement it on that way?

Thanks and regards,
Matthias

[kukeltje]

I would advise against doing it this way. What you are conceptually building then is an ESB with distributed services etc... it is better then to build a generic actionhandler which connects to an ESB which in turn knows where to find the services.

Look at the concepts of an SOA/ESB and you will see what I mean (unless I understood you completely wrong)

[mgommeringer]

Thank you very much. That's exactly what i meant. I'll check this out :-)

[mgommeringer]

...one thing that came into my mind just now is, that - when using a SOA/ESB - the thread that executes the workflow (the generic ActionHandler you mentioned) is blocked until the response of the service is received.
In the proposal that I made, all threads continue their work, which is a great advantage for me. Tell me if I'm wrong - I'm not familiar with ESBs (yet).