Hi Bertrand,

I'll gladly give as much detail as I can, provided you publish the results of your investigation. Is that fair?

Each client request creates a separate JMS session, yet they share a single connection per BPEL process. I am unfamiliar with the JBossMQ implementation details, but the JMS spec suggests the JMS connection encapsulates an open socket and sessions take turns to use the transport. Therefore, the impact of mantaining k-sessions is constant in resources (1 socket) and linear in time (k sessions trying to use the transport simultaneously). In practice, even tough you have k active sessions, only a fraction of them will be contending to use the transport. Some of them will be busy preparing the message or waiting for a response.

In a jBPM BPEL process, message producers and consumers coexist in the web application where the web services are deployed. Hence, there is no reason for using a socket-based invocation layer. By using the in-JVM layer, sessions do not take turns to use the transport; they deposit messages on the queues directly.

When you use a single queue, there will be significant overhead in filtering the messages. jBPM BPEL allows for assigning a separate queue to each partner link in order to alleviate the filtering load.

Hope this helps.

-Alex

1) Well, as you know, endpoints backed by a BPEL process are stateful. In general, you will have a process instance per request, unless two or more requests correlate to the same process instance. In this case these requests will execute the same instance.

This is a consequence of the design of the BPEL language. You can expect performance similar to stateful session beans in the EJB domain.

2) In jBPM, a process instance is composed of one or more tokens. Each token represents a path of execution. Initially, a process instance contains a single token which represents the main path. When the process logic encounters an activity with more than one path of execution (the flow activity, a scope with event handlers, etc) the engine spaws one token per path.

jBPM runs these paths serially to avoid starting new threads because this is forbidden in a Java EE environment. This might look bad, but in practice it is not: jBPM stops executing a path of execution when it encounters a blocking activity (these include inbound message and time-driven activities).

When jBPM stops executing a path, a separate server thread must resume the execution of that path. This is where JMS is critical to the BPEL runtime: it allows for executing more than one path of the same process instance in parallel, while fully adhering to Java EE guidelines.

To illustrate, consider the following example:

<sequence>
 <receive name="a" createInstance="yes"/>
 <flow>
 <sequence name="b">
 <invoke name="b1"/>
 <receive name="b2"/>
 </sequence>
 <sequence name="c">
 <assign name="c1 />
 <receive name="c2" />
 </sequence>
 </flow>
 <reply name="d"/>
</sequence>