Issue 193: Clarify why the spec mandates that JoinConditions must always be evaluated only after all source activities complete

Title: Message

This issue has been added to the 
wsbpel issue list with a status of "received". The status will be changed to 
"open" if the TC accepts it as identifying a bug in the spec or decides it 
should be accepted specially. Otherwise it will be closed without further 
consideration (but will be marked as "Revisitable") 

The issues list is posted as a Technical Committee 
document to the OASIS WSBPEL TC pages on a regular 
basis. The current edition, as a TC document, is the most recent version of the 
document entitled in the "Issues" folder of the WSBPEL TC document list - 
the next posting as a TC document will include this issue. The list editor's 
working copy, which will normally include an issue when it is announced, is 
available at this constant URL.    

Issue 193: Clarify why the spec mandates 
that JoinConditions must always be evaluated only after all source activities 
complete

Status: received
Date added: 27 Feb 
2005
Categories: State 
management
Date submitted: 26 February 2005
Submitter: 
Prasad 
Yendluri
Document: WS-BPEL Working Draft, December, 
2004
Description: This is a follow on to issue 189 which we classified 
as a new feature request. 

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. 

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. An example scenario is a private auction, 
where the auction tracking activity needs a bid to be placed by only one of the 
N bidders possible, to start. 

The only text in the specification that speaks to this major constraint is 
hidden in one sentence in the text in section 12.5.1: "If an activity that is 
ready to start ..., 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." 

Issue 189 called for lifting this constraint but the TC decided to not to 
address this in this version of the specification. Different justifications for 
not incorporating the change were alluded to by the TC members during the 
discussion of issue 189, including increased implementation complexity and the 
amount of changes needed to the specification. 

However since this is a major constraint, the specification must minimally 
clarify why this constraint is imposed by the specification.
Submitter's 
proposal: I request that text be added to section 12.5.1 around the area 
where this constraint is specified.
Changes: 27 Feb 2005 - new 
issue

 Best 
Regards,

Tony                           

  
  

    
      

    
      
Tony 
      Fletcher

      
Technical 
      Advisor 
      
Choreology 
      Ltd.
68, Lombard Street, London EC3V 9L J  
       UK

  

    
      
Phone:  
      

    
      
+44 
      (0) 1473 729537

  

    
      
Mobile: 
      

    
      
+44 
      (0) 7801 948219

  

    
      
Fax:    
      

    
      
+44 
      (0) 870 7390077

  

    
      
Web:

    
      
www.choreology.com

  

    
      
Cohesions™

  

    
      
Business 
      transaction management software for application 
      coordination

  

    
      

      

Work:  
      

  

    
      
Home: