RE: [wsbpel] Issue 37 - Proposal for vote

["Ugo Corda" <UCorda@SeeBeyond.com>]

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