Re: [wsbpel] Issue 193: Clarify why the spec mandates that JoinConditionsmust always be evaluated only after all source activities complete

[Prasad Yendluri <pyendluri@webmethods.com>]

Hi Andrew,

>I will hazard a guess.....

>I will assume the current execution model obeys ..

Yes there have been guesses and assumptions on why this constraint had been placed. The issue is not arguing against the constraint being in the spec (that was 189). All it is asking for is that some clarifying text to be added to justify the purpose of the constraint, instead of leaving it up for guesses or assumptions.

>However I believe that coding this type of flowactivities will be more complicated and more >prone to coding error, especially by the naive programmer.

Agree that this could be one of the reasons (again a guess / assumption), though IMO BPEL is not necessarily always directly manipulation by a programmer. It could be generated from a tool (a typical case IMO).

Prasad

andrew.francis@mail.mcgill.ca wrote:

The BPEL specification currently requires that a
    

joinCondition on a target activity be evaluated only>after all sources activities for the links coming
      

into it are complete, even for an implicit OR
<joinCondition> where the status of only one of the
incoming links needs to be positive.
    

I will hazard a guess.....

I will assume the current execution model obeys properties
conforming what David Luckham calls "ordered observation."Having the ability to make certain casuality guarantees make
it easier to reason about the system and code correctly.
I also suspect it makes things like compensation way easier
to implement. Simple example: If activity B can start only
after activity A finishes, and activity A and B both share avariable X, one has a guarantee that when activity A
is finished, it cannot affect the state of X (i.e., get
into a race with activity B).

  

This is a major constraint that disables
straight-forward modeling of a large class of processes
where the target activity needs only one of its
source activities to complete successfully.
    

N out of M joins (aka discriminators) could be added to
WS-BPEL. However I believe that coding this type of flowactivities will be more complicated and more prone
to coding error, especially by the naive programmer. Issues
have to be addressed. For instance, what happens to
the ignored execution threads? Are they allowed to run
to completion and ignored (problem, if they share variables,
they can potentially cause race conditions with activities
beyond the "synchronization" point)? Or are they terminated
(so now we need new fault handlers)?

However I believe these issues have been raised in the
past.

Cheers,
Andrew