[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 37 - Proposal for vote
Ugo, > Then, assuming that process p1 has the following structure, > sequence > flow > same as the original example, i.e., two receive's here. > assign > invoke > what if the first flow completes before Event 4? > <uc> Isn't this the same situation we were talking about? </uc> <yf> I should have described it more clearly. What if invoke of i1 is running (i.e., i1 is still alive) on Event 4? According to your rule, m1' is not delivered because i1 is alive and holds the matching correlation set. In my view, m1' should be delivered to a newly created instance. </yf> Yuzo Fujishima NEC Corporation. ----- Original Message ----- From: "Ugo Corda" <UCorda@SeeBeyond.com> To: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>; "Eckenfels. Bernd" <B.Eckenfels@seeburger.de>; <wsbpel@lists.oasis-open.org> Sent: Friday, March 12, 2004 1:35 AM Subject: RE: [wsbpel] Issue 37 - Proposal for vote Yuzo, Please see my responses below. Ugo > -----Original Message----- > From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] > Sent: Wednesday, March 10, 2004 9:27 PM > To: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue 37 - Proposal for vote > > > Hi, Ugo, > > Intersting point. > > Let's assume the original event sequence, that is, Event 1, > 2, 3, then 4. > > If I follow your logic correctly, m1' is not delivered also > in this sequence (as far as intance i1 still exists). > <uc> Yes, at that point the flow in i1 is completed, and there is no receive waiting for m1'. </uc> > In my view, m1' should be delivered because in the above > scenario the destination activity (and process instance) can > be determined unambiguously. > <uc> Since they are determined unambiguously, it is clear that the relevant process instance is i1, and it's clear that i1 is not in the position to receive on r1. </uc> > What if instance i1 completes before Event 4? You might think > m1' should be delivered in this case. > <uc> Yes, if i1 does not exist any more, I would create a new instance with correlation value v1, and I would deliver m1' to this new instance. </uc> > Then, assuming that process p1 has the following structure, > sequence > flow > same as the original example, i.e., two receive's here. > assign > invoke > what if the first flow completes before Event 4? > <uc> Isn't this the same situation we were talking about? </uc> > To summarize, my position is to allow bpws:conflictingReceive > to happen rather than to be too restrictive (and ruling out > unambiguously deliverable cases). > > Yuzo > > > ----- Original Message ----- > From: "Ugo Corda" <UCorda@SeeBeyond.com> > To: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>; "Eckenfels. > Bernd" <B.Eckenfels@seeburger.de>; <wsbpel@lists.oasis-open.org> > Sent: Thursday, March 11, 2004 11:45 AM > Subject: RE: [wsbpel] Issue 37 - Proposal for vote > > > Hi Yuzo, > > My expectation for Event 4 is different than what you state > below. I would say instead: > > Event 4. Message m1' that has value (pl1, pt1, op1, v1) > arrives. Because r1 of i1 already received a message, m1' > cannot be delivered to it, so the delivery of m1' fails. > > In other words, I would not create a new instance with same > correlation value as an existing instance. > > Ugo > > > -----Original Message----- > > From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] > > Sent: Wednesday, March 10, 2004 6:30 PM > > To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] Issue 37 - Proposal for vote > > > > > > Bernd, > > > > Thank you for your comments. > > > > == As for part-2: > > > > I am personaly not hesitant to drop part-2. I propsed part-2 in > > respect of the TC discussion at the September F2F. > > > > == As for correlateOrCreate: > > > > I think the following rule should be natural. > > * If there is a pending receive/onMessage activity that references a > > matching initiated correlation set, then the message is delivered > > to that activity. > > * If not, if there is a receive/onMessage activity that specifies > > matching partner link, port type, operation, the message is > > delivered > > to that activity, possibly triggering creation of a new process > > instance > > and/or initiating correlation sets. > > * An activity can receive at most one message per run. That is, it > > must > > be started twice (e.g. by using while activity) to receive two > > messages. > > This excludes the possibility of delivering another message to a > > start activity > > that actually triggered the creation of the instance. > > > > Example: > > > > process p1 > > flow > > receive r1 partnerLink="pl1" portType="pt1" operation="op1" > > correaltion set="cs" > > receive r2 partnerLink="pl2" portType="pt2" operation="op2" > > correaltion set="cs" > > > > Event 1. Message m1 that has properties (partnerLink=pl1, > > portType=pt1, operation=op1, > > cs=v1) arrives. An instance i1 of p1 is created, m1 is > delivered to > > r1 of i1, > > and cs of i1 is set to v1. > > Event 2. Message m2 that has properties (pl2, pt2, op2, v2) > arrives. > > Because r2 of i1 > > is now waiting for a message with properties (pl2, pt2, > op2, v1), > > m2 cannot > > be delivered to it. A new instance i2 is created, m2 is > delivered > > to r2 of i2, > > and cs of i2 is set to v2. > > Event 3. Message m3 that has value (pl2, pt2, op2, v1) arrives. > > Because r2 of i1 > > is waiting for a message with matching properties, m3 is > delivered > > to it. Event 4. Message m1' that has value (pl1, pt1, op1, v1) > > arrives. > > Because r1 of i1 already received a message, m1' cannot be > > delivered to it. > > A new instance i3 is created and m1' is delivered to r1 of i3. > > > > Note: If the events occur in the order of Event 1 then Event 4, > > skipping Event 2 and 3, a conflictingReceive will result > because r2's > > of both i1 and i3 wait for a samely specified message (pl2, > pt2, op2, > > v1). > > > > Sincerely, > > > > Yuzo Fujishima > > NEC Corporation > > > > ----- Original Message ----- > > From: "Eckenfels. Bernd" <B.Eckenfels@seeburger.de> > > To: <wsbpel@lists.oasis-open.org> > > Sent: Thursday, March 11, 2004 2:24 AM > > Subject: RE: [wsbpel] Issue 37 - Proposal for vote > > > > > > > Hello, > > > > > > I like part-1 if it would be enough, but it does not solve > > the problem > > > of "correlateOrCreate" type of receives, which might be > > desireable? > > > > > > > > > Part-2 allows this feature again, but I dont realy see a > > big change to > > > the current attribute, then. The same semantic could be > > achieved by changing the default value of initiate to yes. > > > > > > A more radical solution would be to use another construct > > like pick, > > > if you want to pick multiple possibilities to initiate the > > instance and the correlation. So this would be part-1, all > > correrlations are initiated if none exist, and by the use > of control > > flow you have to ensure that no receive is activated before its > > expected correlation is. > > > > > > Mit freundlichen Grusen > > > Bernd Eckenfels > > > Chief Architect > > > -- > > > SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany > > > Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256 > > > mailto:b.eckenfels@seeburger.de - http://www.seeburger.de > > > > > > > > > -----Original Message----- > > > From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] > > > Sent: Wednesday, March 10, 2004 12:04 PM > > > To: wsbpel@lists.oasis-open.org > > > Subject: [wsbpel] Issue 37 - Proposal for vote > > > > > > > > > Dear WSBPEL members: > > > > > > In hope of expediting the discussion, I would like to propose a > > > resolution for Issue - 37 - Initiating Correlation Set More > > Than Once. > > > http://lists.oasis-open.org/archives/wsbpel/200307/msg00070.html > > > > > > The proposed resolution has two parts. The second part is > > viable only > > > when the first part is accepted. In my opinion, the first > > part should > > > accomodate the multiple start activity scenario and the > second part > > > lends itself to avoid inadvertent errors. > > > > > > Proposed resolution part-1: > > > Abolish the "initiate" attribute of the "correlation" element. A > > > correlation set is initiated by the first activity that > > references it > > > and completes. All the pending and future activities in the same > > > process instance referencing the same correlation set will > > not receive > > > any messages that do not match the correlation set. > > > > > > Proposed resolution part-2: > > > Introduce "noInitiation" attribute with default value > > "false" to the > > > correlation element. If the attribute is set to "true", the > > > correlation set must be already initiated when the referencing > > > activity starts. If the correlation set is not initiated, the > > > bpws:correlationViolation fault must be thrown. > > > > > > Sincerely, > > > > > > 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/le > ave_workgroup.php. > > > > > > 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/le ave_workgr oup.php. > > > 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. 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. 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. 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_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]