[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
Maciej, I suggest you rewrite your initial proposal keeping "createInstance" and "initiate" separate. Right now, you are conflating the two (you are, for instance, talking about "createInstance=rendezvous"), which makes the proposed language confusing. Ugo P.S. Talking about rendezvous, shouldn't the two initial receive's in the Multiple Start Activities example (sec. 16.3.2) have initiate="rendezvous" instead of initiate="yes"? > -----Original Message----- > From: Maciej Szefler [mailto:mbs@fivesight.com] > Sent: Tuesday, October 19, 2004 5:08 PM > To: Ugo Corda > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote > > > Ugo, > > My understanding is that if in a process we find an activity > with createInstance=yes / initiate=yes, then that must be the > /sole/ createInstance activity in that process. (11.4 > suggests that only in the case of rendezvous are multiple > createInstance activities permitted). > > With createInstance="yes" / initiate="rendezvous" we can have > multiple createInstance activities, but for that case we have > (rendezvous) semantics (section 11.4 + Issue 37): > 1. all activities will synchronize on the same correlation > set 2. there will be exactly one "winner" activity that sets > the correlation, > 3. all the other activities will "lose", and respect the correlation. > How the winner is chosen is out of scope, but we know exactly > one winner will be chosen. > > -maciej > > On Tue, 2004-10-19 at 12:21, Ugo Corda wrote: > > Maciej, > > > > > I think the rendezvous issue made > > > such cases technically illegal (i.e. you can only have one > > > createInstance=yes activity). > > > > I am not sure what you are referring to. Could you please clarify? > > > > Thank you, > > Ugo > > > > > -----Original Message----- > > > From: Maciej Szefler [mailto:mbs@fivesight.com] > > > Sent: Tuesday, October 19, 2004 7:16 AM > > > To: Ugo Corda > > > Cc: wsbpel@lists.oasis-open.org > > > Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote > > > > > > > > > Ugo, > > > > > > You are correct. Although, I think the rendezvous issue made > > > such cases technically illegal (i.e. you can only have one > > > createInstance=yes activity). In the case of > > > "createInstance=rendezvous", my first instinct would be to > > > say that processes with this ambiguity are illegal and should > > > be detected by static analysis. > > > > > > -maciej > > > > > > On Mon, 2004-10-18 at 18:49, Ugo Corda wrote: > > > > 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 > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > > > the roster > > > > of the OASIS TC), go to > > > > > > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_wo > > > rk > > > > group.php. > > > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > the roster > > of the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_work > > group.php. > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]