Yuzo,
Please see my responses below.
Ugo
> -----Original Message-----
> From: Yuzo Fujishima [mailto:]
> Sent: Wednesday, March 10, 2004 9:27 PM
> To: Ugo Corda; Eckenfels. Bernd;
> 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" <>
> To: "Yuzo Fujishima" <>; "Eckenfels.
> Bernd" <>; <>
> 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:]
> > Sent: Wednesday, March 10, 2004 6:30 PM
> > To: Eckenfels. Bernd;
> > 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" <>
> > To: <>
> > 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: - http://www.seeburger.de
> > >
> > >
> > > -----Original Message-----
> > > From: Yuzo Fujishima [mailto:]
> > > Sent: Wednesday, March 10, 2004 12:04 PM
> > > To:
> > > 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.
