RE: [wsbpel] Issue - 168 - Proposal To Vote

[Maciej Szefler <mbs@fivesight.com>]

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_workgroup.php.
> 
>

This is a digitally signed message part