To clarify the point - at a 'global model' level, when we talk about parallelism, really what we are saying is that we don't care what order activities are performed in - so given the previous example, messages M1 and M2 could be sent in either order, or both at the same time (if the service implementation supports this).

When we talk about concurrency at an implementation level, this usually involves thinking about threads. However, in the case of services implemented as components in an app server, use of threads is restricted.

Therefore, thinking of an ESB service is the same context, we don't want ESB actions to use threads - although it is possible for one ESB service descriptor to initiate asynchronously two (or more) other ESB service descriptors to represent the concurrent paths - this is how the ParallelAction works in the 'stateful' version of the conversational actions.

Given that the 'global model' (or choreography) is simply defining that the order of the activities in the parallel construct is not important, then given our aim to make the 'stateless' version of the conversational actions as simple as possible, then I think we should simply allow the ESB service developer to list the relevant activities in any order (but sequentially), rather than introducing the concurrency mechanism into the actions.