Re: [wsbpel] Issue 37 - F2F Presentation Draft

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

Satish, Yaron and others,

Again, the core of the issue is we (including Sundari, me and others) don't see there is any clear advantage of (1A) over (1B).  Could you guys shed some light on why we should lean towards 1A,2A combo and why we should lose the flexibility/simplicity that 1B offers?


Back to the "session-like" situation discussion, ....
I tend to think: "session-like" scenario is one of scenarios which (1B) semantics fits better compared with (1A).

I don't think "session-like" initiation is necessarily through implicit / opaque / engine-managed correlation set (that is Issue 96). The "session-like" initiation pattern can be done through typical message properties mechanism also.

As mentioned in my previous email, the session-CS-initiation (e.g. a bidder registration message part) and post-session-initiation activities (e.g. a bidder's bid message part) can be combined and piggy-backed into one message in one receive activities. The CS initiation would come from a message property of the bidder registration message part.

About Issue 96, if I understand Yaron's motivation correctly, I think the engine-managed CS would still go through the same CS lifecyle initiation restriction, when compared with a vanilla / typical CS. That is, once the opaque CS is initialized, it cannot be initialized to another value [if we can pick (1B)]. What is the special about the opaque activities, the values of CS do not come from the message body. It may come from some protocol dependent headers. E.g., a special cookie for HTTP (jsessionid) and JMS correlation ID.


What do you guys think?
Thanks.



Regards,
Alex Yiu



Satish Thatte wrote:

If I understand correctly, you are describing a "session-like" scenario
where the session initiator sets the correlation token (session ID) and
then sends an indeterminate number of messages on the session.  I would
suggest approaching this via implicit correlation (issue 96).

-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com] 
Sent: Monday, May 03, 2004 2:06 PM
To: Satish Thatte
Cc: Yuzo Fujishima; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 37 - F2F Presentation Draft


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