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] Incosistency in Link Join condition Evaluationspecification

Things look fine to me.  For (2) and (3), you have to realize that a control dependency exists regardless of the joinCondiiton.  If you don't want the control dependency, don't draw a link.  (4) is referring to an explicit piece of code (the Initial Example) in which your stipulation ("...is only one of the incoming links...") is not correct, since there is only one link target.


Prasad Yendluri wrote:

We have the following text dispersed in sections 12.5.1 and 12.5.2 that results in an inconsistent specification of evaluation of Link Join conditions. The spec states:

(1) Section 2.5.1: Every activity that is the target of a link has an implicit or explicit “join condition” associated with it. If the explicit join condition is missing, the implicit condition requires the status of "at least one" incoming link to be positive (see below for an explanation of link status).

So, the implicit join is an "OR" and the join condition evaluates to true as soon as the status of one of the incoming links to the activity is positive.

(2) Section 2.5.1: 
If an activity that is ready to start in this sense has incoming links, then it does not start until the status of "all" its incoming links has been determined and the (implicit or explicit) join condition associated with the activity has been evaluated.

If it is an implicit join why should the activity not start as soon as one (or more) of its incoming links goes to a positive? Why should it wait until the status of all incoming activities has been determined?

Section 2.5.1: For each activity B that has a synchronization dependency on A, check whether:
B is ready to start (except for its dependency on incoming links) in the sense described above.
o        The status of all incoming links for B has been determined.

Again why the requirement to wait until the status of all incoming activities is determined?

Section 12.5.2: If one of these invocations were to fault, the status of the outgoing link from the invocation would be negative, and the (implicit) join condition at the target of the link would be false, but the resulting bpws:joinFailure would be implicitly suppressed and the target activity would be silently skipped within the sequence instead of causing the expected fault.

If the link that was set to false (due to the failure) is only one of the incoming links to an "implicit join", shouldn't the join condition evaluate to false only when all other links to the join also evaluate to false.

It seems either the parts related implicit join in (2),(3),(4) above or incorrect or (1) itself was not correct. I believe 1 is correct.

Either way it seems we need to fix this. Comments?

Regards, Prasad


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