OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]