Do we want/need a concurrency construct in the stateless con

[objectiser]

In the stateful conversational ESB actions, there is a ParallelAction construct that enables concurrent paths to be specified and enacted at runtime. This also enables the concurrent behaviour in the service to be checked against a 'parallel' construct in a choreography.

In the 'stateless' conversation ESB actions, where we are trying to simplify the definition of a service, but at the same time enable its behaviour to be checked for conformance against a choreography, do we still need to explicitly represent concurrency in the ESB service descriptors?

My first impression is that we don't want this type of action in the simplified stateless notation. For example, in a choreography, if we had:

parallel {
 send M1;
} and {
 send M2;
}

i.e. so these two messages are sent concurrently, from a conformance perspective, this is equivalent to:

send M1;
send M2;

or

send M2;
send M1;

So the ESB actions could represent the SendMessageActions for the messages being sent in either order, and theoretically they would conform to the parallel activity in the choreography.

Thoughts?

[objectiser]

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.

[marklittle]

Hi Gary. I think what you're suggesting is right. We shouldn't force the use of threads, particularly in environments where they will be restricted. But in terms of the parallel notation all we need do is ensure that the message flow "seen" on the bus conforms to some serializable representation of the flow description.