OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue 37 - F2F Presentation Draft


+1

On second thought, this applies to implicit session based correlation as
well as to explicit correlation.  You always want to know unambiguously
when a session is being initiated.

Satish

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Wednesday, May 05, 2004 5:10 PM
To: Alex Yiu
Cc: Satish Thatte; Yuzo Fujishima; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 37 - F2F Presentation Draft

I believe a programmer needs to be able to look at their code and 
quickly determine exactly when they initiated a correlation set. The 
initiation of a correlation set is an important act in the definition of

the semantics of a BPEL process as it creates the context in which all 
further communications occurs.

1B would make it nearly impossible to determine exactly when a 
correlation set was initiated as programmers will quickly grow used to 
just shoving in 'initiate='true'' on all of their correlation sets. In 
other words, in practice there is really no difference between 1B and 
1C. [1]

I therefore view requiring programmers to unroll the first iteration of 
their while loop in order to explicitly initialize their correlation 
sets not as an inconvenience but as a feature. It highlights and 
distinguishes the once in a correlation set's lifetime act of initiating

the correlation set and so, I believe, improves the clarity of the code.

		Yaron

[1] <http://lists.oasis-open.org/archives/wsbpel/200403/pdf00000.pdf>

Alex Yiu wrote:

> 
> 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
<mailto: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
<mailto: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 
>>>	
>>>	
>>>
>>>
>>>
>>> 
>>>
>>>    
>>>
>>  
>>
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]