Re: [wsbpel] Issue 37 - Proposal for vote

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

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