Regarding Asynchronous Continuations

[kazam]

In regards to modelling Asynchronous Processes,
I have read through

Chap 9 Process Modelling
Chap 13. Asynchronous Continuations and
Tom Bayen's Blog Entry "All you ever wanted to know about Workflow and how it relates to Java, Continuations and Transactions."

My perhaps silly question is that why isn't async used for Tasks, I have used Oracle BPEL Workflow before and Tasks response or completion used to be asynchronous having a callback association in the process when the Task was completed.

My other question is that under JBPM, I am not entirely clear as what Client thread [Is it JBPM thread ? ]and the server thread[ Is it DBMS Thread for transaction processing ? ] means, this terminology has been used in the JBPM Documentation.

Also, under what scenarios or examples would this piece of functionality might come in handy.

Thanks Very Much, Kazam.

[kukeltje]

"kazam" wrote:

My perhaps silly question is that why isn't async used for Tasks, I have used Oracle BPEL Workflow before and Tasks response or completion used to be asynchronous having a callback association in the process when the Task was completed.

Simple, jBPM has (human) task functionality by default. Oracle had to make a proprietary extension to BPEL to achieve the same. So tasks are already 'async'

"kazam" wrote:

My other question is that under JBPM, I am not entirely clear as what Client thread [Is it JBPM thread ? ]and the server thread[ Is it DBMS Thread for transaction processing ? ] means, this terminology has been used in the JBPM Documentation.

Could you elaborate on this? Besides the async continuations, jBPM runs in the client thread (e.g. the webapp, fat client or whatever). It is a library, not a full separate server

"kazam" wrote:

Also, under what scenarios or examples would this piece of functionality might come in handy.

Async conituations? Mainly in the case of long running automated actions which you do not want to block a thread, transaction etc.

[kazam]

Thanks Roland that clarifies everything pretty much.

Could you elaborate on this? Besides the async continuations, jBPM runs in the client thread (e.g. the webapp, fat client or whatever). It is a library, not a full separate server

Am I correct in saying that,

Under Asynchronous processes, the transactions seem to be handled by the JBPM Messaging system, is the messaging system the server thread.
Similarly, under synchronous processes, the transactions seem to be forwarded off to the database server and hence, no multithreading is required on the JBPM side.

Thanks, Kazam.

[koen.aers]

Kazam,

You are partly right. If you use the async functionality, the signal behaviour that puts the token from one node into the next will be broken into two transactions instead of one. The first transaction will put a message on a message queue (the default jbpm messaging system out of the box, or you can configure jbpm to use JMS if you want something more robust). The second transaction will execute the logic that is specified in the node's action...

Hope this helps,
Koen