RE: [wsbpel] Issue 37 - Proposal for vote

["Satish Thatte" <satisht@microsoft.com>]

Yuzo,
 
Issue 37 does not relate to process instance creation as far as I can tell, only to correlation set initiation and matching.  Instantiation continues to be controlled by the createInstance attribute.  Note that correlation sets can be initiated at arbitrary points since they can be declared and initiated  inside arbitrarily nested scopes of running instances.  Uninitiated sets cannot therefore in general cause process instantiation.
 
Define a correlated message relative to a receive activity to mean that 
 
A.  The receive activity has at least one correlation set with initiate="no", 
 
B.  Every correlation set for the receive activity with initiate="no" is already initialized, and 
 
C.  The message contains property values matching those initialized correlation sets.  
 
In other words, the routing infrastructure has every reason to associate that message with that receive activity in that instance.
 
The rule on which the correlation mechanism has been designed has two parts.
 
1.  A receive activity can receive an uncorrelated message only if the receive activity is marked with a createInstance="yes" attribute.  In this case the receive activity occurs in a new instance of the process.
 
2.  An instance can receive messages for receive activities marked with a createInstance="no" attribute if and only if the message is correlated to the receive activity.
 
All of this is reflected in the current specification, though probably not this explicitly.  The ambiguity you pointed out in Issue 37 relates narrowly to the "multi-start activity" case.  In this case, the multiple start activities may have no correlation set with initiate="no" and thus they may all fail the A condition for correlated message delivery.  And yet for all but one of them, the message delivery needs to occur based on the correlated message rules rather than the createInstance rules.
 
Thus the problem is in condition A above.  In my view a good way to approach this is to address it via the createInstance attribute.  Add another value: createInstance="yes | no | alternate" where the alternate value signals the multi-start case.  We could then explain that in the case createInstance="alternate" the setting of initiate is "yes" for the receive that follows rule 1 and "no" for the receives that follow rule 2.  Therefore we should reserve the use of the initiate attribute for receives with createInstance="no" and disallow it for the "start activities".
 
Regards,
 
Satish
 

________________________________

From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com]
Sent: Wed 3/10/2004 6:29 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/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.
>
>
>


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.