Re: [wsbpel] Issue 37 - F2F Presentation Draft

[Alex Yiu <alex.yiu@oracle.com>]

Hi,

Satish ... you definitely broke the record of fastest respond time on 
BPEL TC on Saturday ... :-)

Back to the technical discussion, the semantics you suggest to model 
using scope with while-loop is not exactly the semantics that we would 
like to model about. It is kind of like comparing apple and orange.

Your suggestion would mean using a new correlation set everytime and 
initiating it everytime.

Our target semantics would keep the same CS value for each receive after 
the first initialization of the first receive. E.g. a bidder 
registration and a bidding action may be piggy-backed into the same 
message. Only the first receive of such a message should initiate the CS 
and triggers other bidder registration logic and etc.

Looks like with the proposal (1A), it is going to be unncessarily 
difficult to support a simple use case where the CS is initiated in the 
loop first iteration and just used in the subsequent iterations.

Thanks!


Regards,
Alex Yiu



Satish Thatte wrote:

>You create a scope for the correlation declaration -- the scope is inside the loop -- and most likely you want that nested scope to be "non-reversible" since the only reason you have this scope is to declare the cset -- sorry to drag issue 1/10 in but could't resist :-)
>
>________________________________
>
>From: Alex Yiu [mailto:alex.yiu@oracle.com]
>Sent: Sat 5/1/2004 10:10 PM
>To: Satish Thatte
>Cc: Yuzo Fujishima; wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue 37 - F2F Presentation Draft
>
>
>
>Hi Satish, Yuzo and others,
>
>The example that I constructed may not be not that common, which I agree ... :-) 
>The main point that I was trying to illustrate is: we cannot see any clear advantages why we pick (1A) over (1B), as it seems to us that (1A) is unnessarily more restrictive than (1B). 
>
>If there is a clear rationale of preference (1A) over (1B), please remind me again. 
>
>In fact, when we were discussing Issue 37 at Oracle, one of my coworkers (Sundari Revanur) raised a very good question for a more common usecase scenario. It seems to us that (1A) make it unnessarily complicated. 
>
>Here is what Sundari asked about: 
>
>Using an example from Yuzo's PDF slide, 
>-------------------------
><while ...>
>   ... some other logic - A ...
>   <receive partnerLink=...>
>    <correlations>
>      <correlation
>        set="correlationSet1"
>        initiate="yes"/>
>      </correlation>
>    </correlations>
>  </receive>
>   ... some other logic - B ...
></while>
>-------------------------
>
>If we choose (1A),  how do we handle the correlation violation fault the second and subsequent receive activity? Do BPEL programmers need to unroll the while loop or copy first receive related logic before the loop?
>
>
>Thanks!
>
>
>Regards,
>Alex Yiu
>
>
>[P.S.:
>Yuzo:
>I am not 100% sure that I understand you reply correctly. How do you model "initiating CS2 only once" with two service providers in a parallism situation? 
>In fact, in dynamic parallism, we may select more than one success branch out of N branches. Also, there will be a race condition going on between reaching of the complete condition to stop all other threads and other threads reaching the step of initating the CS in our future parallel for-each construct. (Details of race condition snapped here, since the above usecase situation look like more common.)]
>
>
>
>Satish Thatte wrote:
>
>
>	You are looking for a way to use timing to prioritize cset initiation - this is certainly not in the spec now and is in fact the first time I have heard of this idea.  This would seem to be pretty tricky and open the door for all sorts of non-deterministic seeming choices for cset initiation.
>
>	 
>
>	Re issue 4 it is tangentially related if one wants to make a choice among a set of RFQ responders, for instance.  But the current idea as I understand it is to choose the best responder by some process specific means.
>
>	 
>
>	Satish
>
>
>
>
>Yuzo Fujishima wrote: 
>
>	Hi, Alex, 
>	
>	In your example, op3 is invoked only after both 
>	of the two "receive op2" are completed because 
>	flow is completed only after all of its children 
>	complete. Therefore, initiating CS2 only once at 
>	either "receive op2" should be enough. Then we 
>	don't have to worry about "initiating a CS twice". 
>	
>	Yuzo Fujishima 
>	NEC Corporation 
>	
>	
>
>
>
>  
>