[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 78 - Thoughts on Multi-Start
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]