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