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 - 81 - Proposal For Vote


Ugo,

See comments below,

> > "The structure of the main processing section is defined by 
> > the outer <sequence> element, which states that the three 
> > activities contained inside are performed in order. The 
> > customer request is received (<receive> element), then processed..." 
> > 
> > suggesting that the sequence is in fact ordering the initial 
> > receive activity in a perfectly non-magical way and that it 
> > is the <sequence> that is the first activity to be /activated/. 
> 
> Again, the sentence you quote remains valid under my type of sequence.
In a previous email Paco pointed out that this is only true for <sequence>. 
If the example above had been a <flow> an analogous description would be inconsistent with your sequencing of events.


> The fact that a message initially triggers the sequence has never been
> an issue.
> The issue is whether the sequence is (your sequence):
> 
> 1) message arrives at port
> 2) instance is created
> 3) flow is activated
> 4) message is delivered to createInstance receive (which is obviously
> active at that point)
> 
> or (as suggested by the statement I quoted)
> 
> 1) message arrives at port
> 2) message is delivered to createInstance receive (which "occurs", i.e.
> is active)
> 2) instance is created
> 3) flow is activated
> 
Yup.

> > The point is that this "occurrence" constraint has absolutely 
> > no bearing on when the receive is activated/enabled WRT to 
> > its peers or enclosing activity (note the language about 
> > "delivering" messages to the "corresponding receive" 
> > effectively decouples the occurrence of events from the 
> > activation of activities that consume those events). 
> > 
> > As to the language of the spec, you have a point: I think 
> > what we have here is some sub-optimal language. I read 
> > "occurance of that activity" to mean the occurrence of the 
> > causal event, i.e. the receipt of a message on the 
> > appropriate port/operation, not the activation of the 
> > <receive> activity. 
> 
> This is the point that needs to be clarified. (The English language does
> not have many interpretations for "occur", and the one you are using is
> not one of them ;-).
I think it is the interpretation of "activity" not "occur" that is the
source of the problem. In my view of the world the <receive> activity
has two manifestations: one that "occurs" when the matching message
arrives causing instance creation, and one that "occurs" in the normal
course of evaluating that new process instance. The two manifestations
are connected through a "delivery" concept repeatedly alluded to in
spec.
 
> 
> > Finally, remember that a createInstance <receive> activity 
> > might rely on variables declared within an enclosing <scope> 
> > activity; if what you say is true then the enclosing <scope> 
> > has not "occurred" before the <receive> and presumably the 
> > variables declared in that scope would not yet exist (modulo 
> > more magic). 
> 
> Could you give an example of variables that the receive might be relying
> on?
> 

The variable I was referring to was the variable into which the <receive> puts the message: if the createInstance <receive> is enclosed in a <scope> (which does not seem to be prohibited in the spec) and we use your sequencing of events, then the scope would not be active at the time of the receive and so it would be difficult for the <receive> to write into a variable declared in that scope. 


While I remain unconvinced of the merits of the "more magic" approach,
this exchange reminded me of similar problem we had with event handlers.
In section 13.5.3 the language makes it clear that your interpretation
is far from fantastic :-( : 

"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"

So it seems the spec encourages these shenanigans. I'm not going to
pretend to like it. 

-maciej




> > This reading is supported by the language 
> > in 11.4 and similar language in section 12.4 ("the pick 
> > activity awaits the occurrence of one of a set of events and 
> > then performs the activity associated with the event that occurred") 
> 
> Not sure what this shows. For a pick activity to be awaiting, it has to
> be active first.
> 
> > 
> > Note that in the next paragraph (of 6.4) the spec states (of start
> > activities) "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." Call me presumptuous but 
> > this suggests to me that the /structured/ activities may 
> > logically "precede [a receive activity] in the behavior of 
> > the process". 
> 
> The sentence you quote remains valid under my type of sequence, so I
> don't think this clarifies much.
> 
> > 
> > Furthermore, the subsequent paragraph states (in reference to the
> > example) that:
> > 
> >  "The structure of the main processing section is defined by 
> > the outer <sequence> element, which states that the three 
> > activities contained inside are performed in order. The 
> > customer request is received (<receive> element), then processed..." 
> > 
> > suggesting that the sequence is in fact ordering the initial 
> > receive activity in a perfectly non-magical way and that it 
> > is the <sequence> that is the first activity to be /activated/. 
> 
> Again, the sentence you quote remains valid under my type of sequence.
> 
> > 
> > Finally, remember that a createInstance <receive> activity 
> > might rely on variables declared within an enclosing <scope> 
> > activity; if what you say is true then the enclosing <scope> 
> > has not "occurred" before the <receive> and presumably the 
> > variables declared in that scope would not yet exist (modulo 
> > more magic). 
> 
> Could you give an example of variables that the receive might be relying
> on?
> 
> > Same problems for compensation and fault
> > handling: it just does not make sense to think of the receive 
> > as being activated at any time except after its enclosing 
> > scope/flow/sequence has been activated. No magic required. 
> > 
> > -maciej
> > 
> > On Sat, 2004-09-25 at 16:33, Ugo Corda wrote:
> > > Maciej,
> > > 
> > > The description you give below of the sequence of events 
> > is, as far as 
> > > I can see, in contradiction with what is said in the current spec. 
> > > Sec. 6.4 states:
> > > 
> > > "The creation of a process instance in BPEL4WS is always implicit; 
> > > activities that receive messages (that is, receive 
> > activities and pick
> > > activities) can be annotated to indicate that the 
> > occurrence of that 
> > > activity causes a new instance of the business process to 
> > be created".
> > > 
> > > In other words, according to the current spec, what causes the 
> > > instance to be created is not, as you say below, the arrival of a 
> > > message at a particular port, but the actual occurrence of 
> > a receive. 
> > > So, there is magic in the receive, as you say, but there is 
> > also magic 
> > > in the flow: where else do you see a flow being activated 
> > only after 
> > > the occurrence of one of its underlying activities?
> > > 
> > > So I understand objecting to adding more magic to the flow, but 
> > > pretending that magic is not there already is, in my opinion, 
> > > incorrect.
> > > 
> > > Ugo
> > > 
> > > > -----Original Message-----
> > > > From: Maciej Szefler [mailto:mbs@fivesight.com]
> > > > Sent: Saturday, September 25, 2004 1:14 PM
> > > > To: Ugo Corda
> > > > Cc: wsbpel@lists.oasis-open.org
> > > > Subject: RE: [wsbpel] Issue - 81 - Proposal For Vote
> > > > 
> > > > 
> > > > Ugo,
> > > > Not really. Here's how I look at it from an 
> > implementation point of
> > > > view:
> > > > 1) Deploy time: Process definition is scanned for
> > > > createInstance activities
> > > > 2) When a message is received: For a message arriving at a 
> > > > port/operation that corresponds to a createInstance activity, 
> > > > create a new process instance and associate the message with 
> > > > the process instance.
> > > > 3) process activities in the process according to 
> > "conventional" order
> > > > 4) when the "winning" <receive> activity with createInstance 
> > > > flag is reached, use the message associated with the 
> > process in (2).
> > > > 
> > > > As you see, in the above implementation, the only "magic" is
> > > > in the receive activity. What you are now asking me to do is 
> > > > add magic to the "flow" activity. This makes me unhappy. 
> > > > 
> > > > As I pointed out at the F2F, I'm perfectly happy to allow
> > > > non-createInstance activities to be activated concurrently 
> > > > with "createInstance" activities. However, I feel these 
> > > > activities should not be able to presume that the 
> > > > createInstance activity has completed. If you want that, add 
> > > > a link. If it's inconvenient to add a link (as Yaron 
> > > > demonstrated), well thats a broader problem that is true of 
> > > > the non-start case as well: if we address it, we should 
> > > > address it separately.
> > > > 
> > > > -maciej
> > > > 
> > > > 
> > > > On Sat, 2004-09-25 at 14:27, Ugo Corda wrote:
> > > > > Maciej,
> > > > > 
> > > > > I understand your desire for uniform behavior of the various
> > > > > activities, but let me point out that a createInstance 
> > > > receive has, by
> > > > > definition, a special status that distinguishes it from 
> > any other
> > > > > receive. Receive activities are (like any other activities) 
> > > > supposed
> > > > > to get activated within an existent process instance before
> > > > they can
> > > > > actually do anything (in particular receive a message). 
> > But here 
> > > > > we
> > > > > have a special receive, a createInstance one, which can receive 
> > > > > messages at the time when not only it is not active, but its 
> > > > > corresponding instance does not actually exist. So, as 
> > you see, the 
> > > > > creation of a process as currently defined already forces 
> > > > non-uniform
> > > > > behavior.
> > > > > 
> > > > > Ugo
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Maciej Szefler [mailto:mbs@fivesight.com]
> > > > > > Sent: Saturday, September 25, 2004 11:24 AM
> > > > > > To: wsbpel@lists.oasis-open.org
> > > > > > Subject: Re: [wsbpel] Issue - 81 - Proposal For Vote
> > > > > > 
> > > > > > 
> > > > > > (this may be a resend, my mail server has been unhappy with
> > > > > > Oasis) Yaron,
> > > > > > 
> > > > > > Your proposed changes make me nervous as they create an 
> > > > > > aberration in the semantics of flow: while in general 
> > activities 
> > > > > > within a flow are enabled simultaneously (subject to link 
> > > > > > constraints), in your proposal we have an odd special 
> > case that 
> > > > > > seems to create implicit "multi-source" links between 
> > the start 
> > > > > > and non-start activities. This gives me
> > > > the willies.
> > > > > > 
> > > > > > This is not to say that I do not find your truck 
> > plant example 
> > > > > > compelling. However, my feeling is that it serves 
> > only to point 
> > > > > > out far broader limitations in the expressive power of BPEL 
> > > > > > structured activities and that a real solution to the problem 
> > > > > > (the problem being one of easily sending the status 
> > message as 
> > > > > > soon as one of X possible activities
> > > > > > completes) requires a more fundamental reexamination of these
> > > > > > constructs. 
> > > > > > 
> > > > > > To demonstrate my point, modify your example to eliminate the 
> > > > > > create instance issues. That is, change the truck 
> > manufacturing 
> > > > > > plant process to start not with a supplier 
> > interaction but by an 
> > > > > > operator clicking "build new truck". The rest of the process 
> > > > > > remains the same (the floor must be notified to tool-up only 
> > > > > > after the first supplier sends a message). Regardless 
> > of which 
> > > > > > of the N suppliers is first to send its message, the process 
> > > > > > will need to immediately notify the floor. Now we are back to 
> > > > > > having to duplicate the notice to the floor N times using the 
> > > > > > unsightly process you describe. Clearly, the real 
> > problem here 
> > > > > > is in link
> > > > > > semantics: we have no way to express "as soon as the first of
> > > > > > a set of activities completes do X"  in a natural way. I see 
> > > > > > no reason why we should attempt to fix one instance of this 
> > > > > > larger issue in the limited context of 81.
> > > > > > 
> > > > > > My 2c: As much as possible, activities should always 
> > behave in 
> > > > > > the same way. If one has a flow with createInstance 
> > receives and 
> > > > > > non-createInstance receives, normal rules of 
> > activation should 
> > > > > > apply. That is as soon as the process instance is 
> > created both 
> > > > > > receives are activated "concurrently". Because the 
> > correlation 
> > > > > > sets can only be assumed to be initialized after the 
> > > > > > createInstance receive completes, it is very likely that a 
> > > > > > correlation fault will be thrown from the non-createInstance 
> > > > > > receive when it attempts to use an uninitialized correlation 
> > > > > > set. This is exactly what one would expect, it is 
> > simple, and it 
> > > > > > is consistent with the behavior of receive and flow 
> > in non-start 
> > > > > > context. Multi-start activities fit into this model with only 
> > > > > > minor mental gymnastics: the key is that the losing receives 
> > > > > > (the ones that did not get the "first" message) do 
> > not "follow"
> > > > > > the correlation set in the conventional sense. In a 
> > > > > > multi-start scenario, the BPEL engine must implicitly 
> > > > > > communicates the correlation /key/ values from the winner 
> > > > > > receive to the loser receives. This gets around the question 
> > > > > > of when the correlation /set/ is initialized. The correlation 
> > > > > > /set/ is initialized only after the winning receive is 
> > > > > > finished, but its value (the correlation key) is associate 
> > > > > > with the losing receives before the process instance is even 
> > > > > > started. sudo /sbin/dhclient eth0
> > > > > > 
> > > > > > -maciej
> > > > > > 
> > > > > > 
> > > > > > On Fri, 2004-09-17 at 16:18, Yaron Y. Goland wrote:
> > > > > > > As a consequence of Paco's observations on issue 81 I
> > > > realized a
> > > > > > > few things about the spec:
> > > > > > > 
> > > > > > > 1) It never clearly specified that the start activity MUST
> > > > > > > complete executing before other activities, including 
> > > > other start
> > > > > > activities in a
> > > > > > > multiple start activity scenario, are allowed to begin
> > > > > > executing. This
> > > > > > > is heavily hinted at in section 11.4 but not explicitly 
> > > > > > > stated.
> > > > > > > 
> > > > > > > 2) The spec, near as I can tell, is not clear as to exactly 
> > > > > > > what values should be used on correlation set patterns for 
> > > > > > > start activities.
> > > > > > > 
> > > > > > > I therefore amend my previous proposal for issue 81 so as to
> > > > > > > address these two issues.
> > > > > > > 
> > > > > > > 	Thanks,
> > > > > > > 
> > > > > > > 			Yaron
> > > > > > > 
> > > > > > > 
> > > > > > > Section 6.5
> > > > > > > 
> > > > > > > Change: 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.
> > > > > > > 
> > > > > > > To: To be instantiated, each business process must 
> > contain at
> > > > > > > least
> > > > > > > one such "start activity." That is, a receive/pick activity 
> > > > > > annotated
> > > > > > > with a createInstance="yes" attribute. See section 11.4 for 
> > > > > > > more details on start activities.
> > > > > > > 
> > > > > > > Change: If exactly one start activity is expected to
> > > > instantiate
> > > > > > > the process, the use of correlation sets is unconstrained.
> > > > > > > 
> > > > > > > To: If a process contains exactly one start activity
> > > > then the use
> > > > > > > of correlation sets is unconstrained.
> > > > > > > 
> > > > > > > Section 11.4
> > > > > > > 
> > > > > > > Change: 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.
> > > > > > > 
> > > > > > > To: A receive/pick activity annotated in this way MUST
> > > > be a "start
> > > > > > > activity". A "start activity" is an initial 
> > activity that has 
> > > > > > > a
> > > > > > > createInstance="yes" attribute defined on it. An initial 
> > > > > > activity is a
> > > > > > > receive/pick activity where no other activities but scope, 
> > > > > > > flow, sequence and empty activities occur before it in the 
> > > > > > > process's execution path. While all start 
> > activities must be 
> > > > > > > initial
> > > > > > activities
> > > > > > > not all initial activities are required to be start
> > > > > > activities. If an
> > > > > > > initial activity is not a start activity then the
> > > > initial activity
> > > > > > > will only become active after the start activity 
> > has completed
> > > > > > > execution.
> > > > > > > 
> > > > > > > Change: It is permissible to have the createInstance
> > > > attribute set
> > > > > > > to"yes" for a set of concurrent initial activities.
> > > > > > > 
> > > > > > > To: It is permissible to have multiple start 
> > activities. When 
> > > > > > > a process begins execution the start activity that 
> > triggered 
> > > > > > > the
> > > > process MUST
> > > > > > > complete execution before the other start activities, now
> > > > > > turned into
> > > > > > > initial activities, and any other initial activities begin
> > > > > > execution.
> > > > > > > 
> > > > > > > Change: All such receive activities MUST use the same
> > > > > > correlation sets
> > > > > > > (see Correlation).
> > > > > > > 
> > > > > > > To: If a process has multiple start activities then all
> > > > the start
> > > > > > > activities MUST use the same correlation sets and the
> > > > > > pattern for all
> > > > > > > the correlation sets MUST be sent to "rendezvous" (see
> > > > > > > Correlation).
> > > > > > > 
> > > > > > > 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_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_workgroup.php.
> 
> 

This is a digitally signed message part



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]