[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Issues 26 and 49
ok, i guess i must have missed that. sounds like my issue is irrelevant then. danny ----- Original Message ----- From: "Assaf Arkin" <arkin@intalio.com> To: "Danny van der Rijn" <dannyv@tibco.com> Cc: <ygoland@bea.com>; "Peter Furniss (E-mail)" <Peter.Furniss@choreology.com> Sent: Friday, September 05, 2003 2:20 PM Subject: Re: Issues 26 and 49 > Page 56 includes the following text in the definition of the > receieve/reply activities: > > "The correlation between a request and the corresponding reply is based > on the constraint > that more than one outstanding synchronous request from a specific > partner link for a > particular portType, operation and correlation set(s) MUST NOT be > outstanding > simultaneously." > > This is the most precise the spec is on this particular point. The > features change section (page 13) actually clarifies the intent, but not > in a normative way: > > "Correlation sets have now been added to the uniqueness requirement so > that it is not > legal to have two web service interactions outstanding if they have the > same partner, > port type, operation and correlation set(s)." > > So my understanding is that a synchronous operation starts with the > <receive> and ends with the <reply>, unless a reply has been sent, the > operation is still outstanding, and so no other <receive> is allowed at > that point in time. So the following sequence: > > sequence > receive X > receive Y > reply X > reply Y > > is illegal if X and Y are the same partner/operation/correlation. > However, if X and Y are the same partner/operation but different > correlations, then the sequence is legal, but only if one could figure > out how to match the reply to the receive. Which in my opinion should be > spelled out more clearly. > > There is another restriction imposed on both synchronous and > asynchronous receives, and that is that two receives cannot be enabled > at the same time (outstanding or not). This is intended to deal with a > situation like: > > scope > . . . > pick > onMessage X > . . .. > eventHandler > onMessage Y > > where X and Y are the same partner/operation/correlation. In this case > once the <pick> activity is performed, it competes with the enabled > event handler for the same message. The process cannot decide which of > these activities to forward the message to, and so this definition is > undeterministic. > > arkin > > > Danny van der Rijn wrote: > > >>My "interpretation" of the spec is that you can't enable the second > >>receive until after you're done with the reply, but it's just because I > >>understand "outstanding" to mean the request have been received but no > >>reply has been generated yet. > >> > >> > > > >note that what your interpreting is *my* wording of my issue. the spec > >doesn't use any wording that can be interpreted like that, as far as i can > >tell. it says: > > > >"A business process instance MUST NOT simultaneously enable two or more > >receive > >activities for the same partnerLink, portType, operation and correlation > >set(s)." > > > >which in my reading doesn't even come close to the "multiple outstanding" > >issue i'm raising. which is why i think that the spec either needs to be > >tightened to disallow "multiple outstanding", or to state how they are to be > >disambiguated. > > > >danny > > > >----- Original Message ----- > >From: "Assaf Arkin" <arkin@intalio.com> > >To: "Danny van der Rijn" <dannyv@tibco.com> > >Cc: <ygoland@bea.com>; "Peter Furniss (E-mail)" > ><Peter.Furniss@choreology.com> > >Sent: Thursday, September 04, 2003 7:24 PM > >Subject: Re: Issues 26 and 49 > > > > > > > > > >>Got it. > >> > >>Those are two different issues, the case I am talking about may occur in > >>combination with the case Danny is talking about, but they may also > >>occur separately and independently of each other.. > >> > >>My "interpretation" of the spec is that you can't enable the second > >>receive until after you're done with the reply, but it's just because I > >>understand "outstanding" to mean the request have been received but no > >>reply has been generated yet. If the receive is for a one-way message > >>then the request is not "outstanding". > >> > >>But even that logic is not supported from the language of the spec. > >> > >>arkin > >> > >>Danny van der Rijn wrote: > >> > >> > >> > >>>they may be the same, they may not. if they're not, we might be able to > >>>roll them together anyway. i think that i did a less-than-stellar job > >>>wording my original issue, and because of that, it got answered the wrong > >>>way. and i didn't see that at the time. > >>> > >>>i mention "outstanding" receives not in the sense of the spec: > >>>"A business process instance MUST NOT simultaneously enable two or more > >>>receive > >>>activities for the same partnerLink, portType, operation and correlation > >>>set(s)." > >>> > >>>but in the sense of request/replies that have been received, but not yet > >>>replied to. i don't see anything in the current spec that forbids that, > >>> > >>> > >and > > > > > >>>in that case, <reply> will not be able to disambiguate. i'll send some > >>>followup mail to get the discussion rolling again. > >>> > >>>arkin's issue arrives at the same problem, but gets there a different > >>> > >>> > >way. > > > > > >>>if, for instance, it is desirable to solve his, but disallow mine, it may > >>> > >>> > >be > > > > > >>>useful to keep them separate. > >>> > >>> > >>> > >>>danny > >>> > >>> > >>> > >>>----- Original Message ----- > >>> > >>>From: "Assaf Arkin" <arkin@intalio.com> > >>>To: <ygoland@bea.com> > >>>Cc: "Danny van der Rijn (E-mail)" <dannyv@tibco.com>; "Peter Furniss > >>>(E-mail)" <Peter.Furniss@choreology.com> > >>>Sent: Thursday, September 04, 2003 2:37 PM > >>>Subject: Re: Issues 26 and 49 > >>> > >>> > >>> > >>> > >>> > >>> > >>>>The spec does not allow two outstanding receives unless they can be > >>>>disambiguated. Period. If they cannot, then a fault is thrown, so I'm > >>>>not so sure about issue 49. > >>>> > >>>>However, the spec does allow them to be disambiguated using the > >>>>correlation set for the <receive> but provides no guidance for the > >>>><reply>. So my issue is that, assuming it is the intent of the text to > >>>>allow that, to include more specific text that provides some guidance > >>>>and the appropriate restrictions on using such a combination of > >>>>receive/reply. > >>>> > >>>>arkin > >>>> > >>>> > >>>>Yaron Goland wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Are these two issues repeats of each other? > >>>>>Just Curious, > >>>>>Yaron > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]