RE: [wsbpel] Issue - 81 - Proposal For Vote

[Maciej Szefler <mbs@fivesight.com>]

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