Below you say "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."
When you say 'correlated' do you mean correlated via a correlation set
or through some unspecified mechanism that is known to the message
infrastructure? Put another way, is it ever legal to have a receive with
createInstance="no", a single uninitialized correlation set and
initiate="yes"?
For example, imagine a new instance is created. Further imagine that the
new instance has been assigned a unique URI and that this unique URI has
been communicated through an out of band mechanism to other web
services. Finally, imagine that the new instance contains within it a
receive activity with createInstance="false", an uninitialized
correlation set and initiate="yes".
My expectation was that if another web service should send a message
directly to the instance's uniquely assigned URI and if the message
matched the portType/operation described in the receive then the
instance would receive the message and initiate the correlation set.
Is your understanding different?
Thanks,
Yaron
Satish Thatte wrote:
> 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:]
> Sent: Wed 3/10/2004 6:29 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/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.
>
>
>
>
> 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.
>
