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


The point Yaron (I believe) is making is that the intention to initiate
correlation or session must be explicitly stated, and thus if in a
specific execution you get to an initiation point with the cset already
initiated you know something is wrong with the model or the interaction.

-----Original Message-----
From: Goran Olsson [mailto:goran.olsson@oracle.com] 
Sent: Thursday, May 06, 2004 1:58 PM
To: Satish Thatte; ygoland@bea.com; Alex Yiu
Cc: Yuzo Fujishima; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 37 - F2F Presentation Draft

I'm confused, by the same token, one would expect the same expectation
with
respect to the creation of a business process. Also I don't see how the
present resolution will allow a programmer to determine from the code
where
the session was initialized. It may be different in each execution.
Goran
----- Original Message ----- 
From: "Satish Thatte" <satisht@microsoft.com>
To: <ygoland@bea.com>; "Alex Yiu" <alex.yiu@oracle.com>
Cc: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>;
<wsbpel@lists.oasis-open.org>
Sent: Wednesday, May 05, 2004 10:39 PM
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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

To unsubscribe from this mailing list (and be removed from the roster of
the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.





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