Re: [wsbpel] Issue 37 - Proposal for vote

["Yuzo Fujishima" <fujishima@bc.jp.nec.com>]

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

In my view,  m1'  should be delivered because in the above scenario
the destination activity (and process instance) can be determined
unambiguously.

What if instance i1 completes before Event 4? You might think
m1' should be delivered in this case.

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?

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