RE: [wsbpel] Issue 6 - Rough draft of proposal for vote

Alex,

Regarding the 
proposed semantics: Would you elaborate how the fault 
(bpws:earlyCompletionFault) will be 
signaled to other incomplete flow activities? Those activities are enclosed 
within the flow activity. If I understand the fault handling model 
correctly there is no possibility to communicate faults to nested 
activities/scopes except canceling the enclosing activity (in this case, the 
flow activity). 

Regards,

Ivana

  
-----Original Message-----
From: Alex Yiu 
  [mailto:]
Sent: Mittwoch, 1. September 2004 
  04:28
To: Satish Thatte
Cc: ; 
  ; Alex Yiu
Subject: Re: [wsbpel] Issue 6 
  - Rough draft of proposal for vote

Hi, Yaron and 
  others, 

I agree with the concern of Edwin and Satish. We should define 
  a general mechansim to express early completion condition. Then, define the 
  "orJoin" attribute or other syntax as a macro/special syntax short 
  cut.

If you guys don't mind, I can supplement some alternative ideas to 
  this issue. I am in the thinking-out-loud mode again. That means, I need to 
  verify whether this idea makes sense to other people at Oracle.  [ But, 
  as Ron said, this thinking-out-loud mode has worked quite well for me in the 
  past. ;-) ]

We should allow a <completeCondition> subelement 
  attached to parallel-flow-starter activity (e.g. <flow> or future 
  potential parallel <forEach>). 

Syntax of 
  completeCondition:
It has two forms:
(1) 
  <completeCondition>a_boolean_expr</completeCondition> 
(2) 
  <completeCondition minFlow="a_number" /> 
    
          ...  or ...
    
     <completeCondition 
  countMinFlow="yes">a_number_expr</completeCondition> 

The 
  first form is the most generic form of completion condition. 
The second 
  form provides a convienent shorthand to achieves the N out of M semantics. 
  

The suggested orJoin="yes" is equivalent to: 
  
<flow>
    <completeCondition minFlow="1" /> 
  
     ... 
</flow>

Semantics of 
  completeCondition:
The complete condition will be evaluated at the 
  completion of each flow. If the condition is true, a standard fault 
  bpws:earlyCompletionFault will be signaled to other incomplete flow 
  activities. Each incomplete flow activity can potentially be compensated if 
  each flow is a scope activity. (Potentially, we can add static analysis to 
  enforce that when a completionCondition is used in <flow>, <scope> 
  must be used as activities within the flow.) 

The completeCondition 
  itself is executed in the same scope context of the <flow> 
  activity.  [ And, the completeCondition should be executed serially, to 
  avoid racing condition among flows (?)]

I hope this rough draft of 
  ideas serves as a good base of discussion for this 
  issue.

Thanks!

Regards,
Alex 
  Yiu

Satish Thatte wrote:

  
    
    
    
    

    
I echo Edwin's 
    second question.  Yaron, your proposal clearly doesn't address the 
    intent of 6.  It seems too narrow to just address this corner case of 
    completion of one among many (corner case from my 
    perspective).

    

    
Satish

    

    

    

    

    

    
    

    
From: Edwin 
    Khodabakchian [mailto:] 
Sent: Friday, August 27, 2004 
    5:38 PM
To: 
Subject: RE: [wsbpel] Issue 6 - Rough 
    draft of proposal for vote

    

    

    
Hi 
    Yaron,

    
2 
    questions:

    
1) are we sure that termination 
    is the desired behavior for the non completed 
    activity?

    
2) what happens if the join rule 
    is: "the first search result which is non empty or includes at least 3 
    entries with more than 85% accuracy"? The point here is that a lot of join 
    patterns might have logic in them. I know that in the past we talked about 
    having something like <break> for flow. (This is something that a lot 
    of our customers are asking us and might address the same us case is a more 
    flexible way specially if the <break> can be configure to tell the 
    engine to compensate or terminate).

    
Best,

    
Edwin