[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
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_work > > group.php. > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]