[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 193: Clarify why the spec mandates that JoinConditionsmust always be evaluated only after all source activities complete
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
The BPEL specification currently requires that ajoinCondition on a target activity be evaluated only>after all sources activities for the links cominginto 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