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/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.
