Concurrency within the process deals with parallel flows (flow activity, parallel foreach, event handlers) and the complexity that comes from synchronization (links, faults, isolated scopes, completion conditions).
The trick is to reduce the apparent complexity ;-)
time it takes to implement a foreach activity is a good measure, since foreach can execute multiple branches in parallel, yet has several points for synchronization (completion of all branches, completion conditions, termination, faults).
indeed
Separately from that, there are threads dedicated to executing activities and threads dedicated to sending/receiving messages. This architecture allows some threads to keep executing activities, while other threads are waiting to send and receive messages. It helps with tuning, since the activity executing threads are load on the server (CPU, database), while the threads sending/receiving messages are I/O bound. Processes that are very I/O bound will require a lot of send/receive threads, and only a few execution threads.
In a modern "managed code environment", threading is orthognal to the component being managed. Only a properly designed process model wil reduce concurrency *if* the "thing" executing the process is simple enough and is not trying to do too much.
That has nothing to do with BPEL, it's just a better architecture for messaging, especially for supporting low-latency operations. You'll find the same behavior in Axis2, .Net and many other modern messaging frameworks. Right now this is handled by PXE code, but if we switch to Axis2 we would still prefer to use decoupled sender/receiver threads, we'll just delegate their lifecycle to Axis.
"We" don't need to swith to anything. That was the point about the simplicity of BPE today...the current BPE implementation already delegates messaging and does not care what the thing is it is delegating to.
And of course there's thread management, time scheduling, service lifecycle, etc which we delegate to the app server layer.
BPE does the same thing for thread management and service lifecycle. Quartz is used for timing in BPE today but that could be anything. Why do all of this work you are talking about if there is a solution that exhibits that behavior today - unless the issue is simply where that solution originally came from?
