[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 168 - Semantics of instance creation
This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if the TC accepts it as identifying a bug in the spec or decides it should be accepted specially. Otherwise it will be closed without further consideration (but will be marked as "Revisitable")
The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.
On the one hand, the spec suggests that process creation is "implicit" and that the createInstance flag is merely an annotation that defines which message events cause an instance to be created and that once created the process instance processes all activities in the same manner largely oblivious to the value of that annotation.
On the other hand, the spec restricts the set of activities that are "initial" activities, and establishes exceptional semantics (for process-level event handlers) that could be construed to imply that createInstance activities are actually activated before any other activities, irrespective of their actual location in the process.
I posit that the former interpretation provides a concise and manageable view of the instance creation process. By making the spec consistent with it we can define execution semantics of a single process instance without reference to instance creation. We can handle instance creation simply and separately by stipulating that a process instance is created when a message event that would match one of the createInstance activities is received. This message event is "allocated" to that activity, so that when that activity is actually activated (in the normal course of process instance evaluation) it will receive the said event.
The major implication of this model on execution semantics is the elimination of the notion of "initiate" activities. This concept becomes unnecessary. One might object on the basis that without the initiate activity restrictions the following process would be perfectly legal:
<sequence>
<invoke .../>
<receive createInstance="yes" .../>
</sequence>
Such a process certainly seems objectionable. However, the details of normal execution semantics would make such a process unlikely. That is to say, the <invoke> would need to use a message variable (for the request), and that variable could not have been initialized unless some activity preceded the <invoke>. One might then object with the
following:
<sequence>
<receive createInstance="no" .. var="foo"/>
<invoke ... inVar="foo"/>
<receive createInstance="yes" ..>
</sequence>
However, in this process the first receive is invalid unless a correlation set is used. But in order to use the correlation set, it first needs to be initialized, and the only way to do that is with an invoke or a receive/pick that precedes it, so you're back to needing a <receive> to precede the <invoke>. This receive would have to have createInstance="yes" lest it run into the same problem. But if this receive had createInstance="yes" then the same annotation on the second <receive> would be invalid.
Now, one might get cleverer still and object based on the following somewhat convoluted process:
<sequence>
<assign>
<copy>
<to variable="foo"/>
<from> literal </from>
</copy>
</assign>
<invoke ... inVar="foo">
<correlation name="cset1" initiate="yes" pattern="in"/>
</invoke>
<receive createInstance="no" ..>
<correlation name="cset1" initiate="no" />
</receive>
<receive createInstance="yes" ..>
</sequence>
However the above construct would result in ALL process instances having the same correlation set value, which does not make any sense.
But one could still object by changing the pattern to "out" on the invoke, and asserting that the partner generates unique output messages for each invocation thereby yielding unique correlation keys. But even this very brink of the edge case forces us to change nothing in the semantics. The only significant implication is that in certain unlikely circumstances, the implementation might have to handle <invoke>s and non-createInstance <receive> before it has a chance to offload the createInstance message to the createInstance <receive> (i.e. it needs to provide a "memory" for the message that created the instance). The only plausible use case for this kind of behavior is for initialization of static content.
Finally, adopting uniform execution semantics would lead us to elimination of the exceptional language in the spec that requires that process-level alarm handlers can use data that would normally only be valid after a receive activity completes. This is not so onerous, as it is possible to move a process-level event handler into a scope following the initial receives.
Changes: 4 Oct 2004 - new issue
To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 168 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - 168 - Proposed resolution", without any Re: or similar.
To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).
Choreology Anti virus scan completed
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]