[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]