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,

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]