[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 37 - Proposal for vote
Yuzo, > 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. Yes, that's exactly what I believe should happen. Not much different than the case where a message is sent to a process and there is no receive downstream that could get it. Ugo > -----Original Message----- > From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] > Sent: Thursday, March 11, 2004 5:48 PM > To: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org > 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/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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]