Issue - 78 - Thoughts on Multi-Start

["Yaron Y. Goland" <ygoland@bea.com>]

WARNING: If my thoughts on issue 63 were rough then my thoughts on issue 
78 are jagged. I am hesitant to release my thinking in such an unformed 
state but issue 78 is on the agenda so I figure it was best to get out 
an initial e-mail then try to explain this all for the first time at the 
meeting. Given how ill conceived these thoughts are I probably will have 
disavowed everything I've written here before you have finished reading 
this paragraph.

There are a number of reasons I haven't been very happy with 
Multi-Start. One reason is that the initiate attribute behavior is 
strange. The other reason is that being able to sprinkle multi-start 
activities throughout a process (assuming only flows and sequences are 
between the activity and the root) seems like a dangerous idea to me.

I have been looking for a solution that would maintain all the power of 
today's multi-start model but have a simpler to understand syntax. What 
I have been thinking is that we should require that all BPEL processes 
start with a special activity called start. This means that all BPEL 
processes would look like:

process
    ...
    start standard-attributes
       standard-elements
       startHandlers
          correlations ?
             correlation set="ncname" +
          (startPick | startReceive) +
       nonStartHandlers ?
          (Pick | Receive) +

In other words, each process would have a start activity as a child. 
This would be the only place a start activity could be used.

The start activity would contain two different sub-elements, a mandatory 
startHandlers and an optional nonStartHandlers.

The startHandlers element contains an optional correlations definition 
and one or more of either startPick or startReceive activities. The only 
difference between startPick and startReceive from Pick and Receive is 
that startPick and startReceive do not contain correlation definitions. 
Instead they MUST use the correlation definition, if any, defined as a 
child of startHandlers. Also, if there is more than one child activity 
of startHandlers or if a startPick is used with more than one onMessage 
entry then correlations child element of startHandlers MUST be defined.

The purpose of the startHandlers is to define what messages can be used 
to create a new instance of a process. Once a new instance of a process 
is created all remaining activities in the startHandlers are treated 
like normal Pick/Receives whose correlation sets are as defined by the 
correlations child of the startHandlers element with initiate="no" for 
all correlation entries.

The nonStartHandlers are fundamentally different than the startHandlers 
in that they are only available for use once a new instance is created. 
nonStartHandlers are equivalent to the case in BPEL where an initial 
activity is not a start activity. The only legal children of 
nonStartHandlers are the Pick and Receive activities.

It's worth pointing out that one can do some fairly interesting static 
analysis on the children of nonStartHandlers. For example, at least one 
of the correlation sets on each child within a nonStartHandler MUST be 
initiate="no" otherwise it wouldn't be possible for the router to know 
when to route a message to that handler on a particular instance.

In a very loose sense start can be thought of as a very special case of 
flow. Once the process starts each of the activities starts executing in 
parallel waiting for a message to arrive.

It is my intention that the start activity be able to map every possible 
combination of start and initial activity behavior in the current BPEL 
spec. If you find an example of a start/initial activity combination 
that cannot be replicated with the start activity is it not because I 
intended to exclude that case but because I screwed up.

I'm sure there are tons of things wrong with this proposal but one of 
the most glaring is - what possible use is startReceive/Receive? Unlike 
Pick, whose onMessage handlers each contain an activity and thus be the 
root of an arbitrary complex definition, Receive does not. So once the 
Receive fires, no further processing is possible. I originally solved 
this problem by essentially making startHandlers and nonStartHandlers 
into special cases of Pick and having each one contain onMessage 
handlers. Unlike Pick, however, these onMessage handlers would all 
execute in parallel and therefore it was interesting to be able to 
define links that had them as the source. But once you add links to the 
onMessage handlers then the onMessage handlers are effectively full 
fledged activities. That just seemed a little too messy to me. I can't 
help but wonder if perhaps we shouldn't just ban Receive (which anyway 
is a degenerate case of Pick) from the start activity and just use Pick. 
Otherwise we can either add an activity as a child of Receive or come up 
with a variant of Receive that includes an activity as a child.

As you can tell, my thinking is still very rough but I hope this gives a 
flavor for the direction in which my thinking is going. I look forward 
to discussing this with everyone at the F2F!

	Yaron