[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
Maciej, What about the case where the "instantiating message" matches more than one activity marked with createInstance=yes? Your proposed wording does not explicitly rule that out, but in such a case the concept of "instantiating activity" would become ambiguous, in the sense that it would not be clear which one of those activities could be labeled that way. Ugo > -----Original Message----- > From: Maciej Szefler [mailto:mbs@fivesight.com] > Sent: Monday, October 18, 2004 11:22 AM > To: wsbpel@lists.oasis-open.org > Subject: [wsbpel] Issue - 168 - Proposal To Vote > > > I propose we adopt the "less magic" approach described in the > issue description. This means that the semantics of process > instantiation would be as follows: 1. The arrival of message > that matches an activity marked with > createInstance=yes/rendezvous (and not matching an existing process > instance) causes a new process instance to be created. This > message is termed the "instantiating message" for that > process instance. The createInstance=yes/rendezvous activity > that was used to justify the instantiation is termed the > "instantiating activity" for that process instance. > 2. Once a process instance is created, all its activities > are executed in the order dictated by the structure of the process. > 3. When a <receive> or <pick> activity with > createInstance=yes is executed, the message "received" will > be the "instantiating message" of the process instance. 4. > When a <receive> and <pick> activity with > createInstance=rendezvous is executed, the message "received" > will be either: > a ) the "instantiating message" if said activity is the > "instantiating activity" > b ) some other message matching the correlation key from > the "instantiating message" if said activity is not the > "instantiating activity" > > Key changes to text: > 6.4: > OLD: This is done by setting the createInstance attribute of > such an activity to "yes". When a message is received by such > an activity, an instance of the business process is created > if it does not already exist (see Providing Web Service > Operations and Pick). > NEW: This is done by setting the createInstance attribute of > such an activity to "yes". When a message that matches such > an activity is received, an instance of the business process > is created if it does not already exist (see Providing Web > Service Operations and Pick). > > OLD: To be instantiated, each business process must contain > at least one such "start activity." This must be an initial > activity in the sense that there is no basic activity that > logically precedes it in the behavior of the process. > NEW: To be instantiated, each business process must contain > at least one such "start activity." ----strike--- > > 11.4: > OLD: A receive activity annotated in this way MUST be an > initial activity in the process, that is, the only other > basic activities may potentially be performed prior to or > simultaneously with such a receive activity MUST be similarly > annotated receive activities. > NEW: -----strike---- > > > 13.5.3: > OLD: If the event handler is associated with the global > process scope, the event handler is enabled as soon as the > process instance is created. The process instance is created > when the first receive activity that provides for the > creation of a process instance (indicated via the > createInstance attribute set to "yes") has received and > processed the corresponding message. This allows the alarm > time for a global alarm event to be specified using the data > provided within the message that creates a process instance, > as shown in the following example: > > NEW: If the event handler is associated with the global > process scope, the event handler is enabled as soon as the > process instance is created. > Note: alarm time for a global alarm event /cannot/ be > specified using the data provided within the message that > creates a process instance! > > On Mon, 2004-10-04 at 17:14, ws-bpel issues list editor wrote: > > 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. Issue - 168 - Semantics of instance > > creation > > Status: received > > Date added: 4 Oct 2004 > > Categories: State management > > Date submitted: 30 September 2004 > > Submitter: Maciej Szefler > > Description: Discussions of issue 81 : Are start activities that > > aren't createInstance activities legal? have brought to light a > > certain deficiency of clarity in the current specification with > > respect to issue of instance creation. The present spec > makes various > > vague and somewhat contradictory statements as to how > createInstance > > activities should be handled. > > > > 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]