Hi Burr. burrsutter wrote : Do you also find the need for synchronous processing within jBPM? Where the calling thread should be blocked as each node (assumes no wait-states) is executed and control is returned to the calling thread when the process instance is completed? | I see this being a main advantage of jBPM over other architectures. It makes it easily usable in a lot of different scenarios, like even 2-tier architectures or Seam Pageflow. Since you can easily change the behaviour to use JMS to decouple it from the client thread (something I think the most process engines do) by just adding a "async=true" flag, I don't see any downside of it. If you want to get rid of the async flag you could even introduce a global configuration property in jbpm to change the default, should be a too big problem. Despite the value for different use cases of jbpm I think "borrowing the client thread" has the big advantage, that java developers can easily understand what is going on. And it is easy to write Unit-Tests (since you do exactly know what happened after a call returns). So actually I am a big fan of it! And I know quite some projects or developers who are on my side I think :-) I think, this is one of the unique selling points of jbpm. Don't make it as unnecessary complex as other big unhandy process engines (unless there is a very good reason to ;-)). Hence, the interessting question is, with the async flag in place, why should it be changed? What would be the advantage of it? Cheers Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198375#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...