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

(this may be a resend, my mail server has been unhappy with Oasis)

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

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

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


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

This is a digitally signed message part

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