There is no mechanism today to allow the use of invisible correlation.
Therefore the answer to
is it ever legal to have a receive with
createInstance="no", a single uninitialized correlation set and
initiate="yes"?
is NO according to my reading of the current spec.
We have the unresolved issue 96 for this very question. A good one for
the F2F.
Satish
-----Original Message-----
From: Yaron Y. Goland [mailto:]
Sent: Thursday, March 18, 2004 2:34 PM
To: Satish Thatte
Cc: Yuzo Fujishima; Eckenfels. Bernd;
Subject: Re: [wsbpel] Issue 37 - Proposal for vote
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_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_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_workgr
oup.php.
