Re: Issues 26 and 49

[Danny van der Rijn <dannyv@tibco.com>]

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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>