[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 37 - Proposal for vote
I agree we should discuss this at the F2F and I also agree with your reasoning as to why the behavior I describe is currently illegal and why 96 is the right place to address it. Thanks, Yaron Satish Thatte wrote: > 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:ygoland@bea.com] > Sent: Thursday, March 18, 2004 2:34 PM > To: Satish Thatte > Cc: Yuzo Fujishima; Eckenfels. Bernd; wsbpel@lists.oasis-open.org > 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: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_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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]