Maybe it will be better not to use jBPM's fork and join. I can use topic and aggregator instead, or static router and aggregator...
But still I am wonder how to implement that in jBPM's fork and join....
There is no reason why you could not have the services called concurrently, using the jBPM fork/join mechanism. This is as valid a solution as using split/aggregator within the bus.
The answer to the question really depends on which part of your process is the most natural place to host this functionality, whether it is in the business process or the implementation of an ESB service.
The current jBPM integration code will handle this using synchronous invocations on the ESB bus, therefore blocking a jBPM thread. Kurt is currently rewriting this code so that it uses asynchronous messaging on the ESB side, resuming the jBPM process through a subsequent signal. This will no longer block threads while still providing the semantics of synchronous invocations to the jBPM process.
The new integration code will also support a timeout mechanism specified within the jBPM process definition, allowing the process definition to control each aspect of the invocation.
This is something that I've not tried (caution)...
jBPM by default actually processes all transitions out of a fork
synchronously. They have an async continuation feature:
Which I think is keyed by async=true on the fork node.
However, as Kevin pointed out, our ESBActionHandler that is invoking the actual ESB Service needs to properly handle the async call down into the ESB.
bpm_orchestration3 illustrates what the jboss-esb.xml and the jpdl need to look like in 4.2.1, after we get this new capability/fix in place this may change slightly.