Issue 49 - Proposal for Vote

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

I propose that this issue be closed as a duplicate of 26.

----- Original Message ----- 
From: "Danny van der Rijn" <dannyv@tibco.com>
To: "Monica Martin" <monica.martin@sun.com>
Cc: <wsbpel@lists.oasis-open.org>
Sent: Thursday, September 25, 2003 8:51 AM
Subject: Re: [wsbpel] Re: Issues 26 and 49


> reading from the issues list is a bit confusing.  assaf has relevant
> questions in issue 26 as you noted below.  issue 49 can be closed as
> irrelevant.
>
> danny
>
> ----- Original Message ----- 
> From: "Monica Martin" <monica.martin@sun.com>
> To: "Danny van der Rijn" <dannyv@tibco.com>
> Cc: <wsbpel@lists.oasis-open.org>
> Sent: Thursday, September 25, 2003 7:39 AM
> Subject: Re: [wsbpel] Re: Issues 26 and 49
>
>
> > Danny van der Rijn wrote:
> >
> > >ok, i guess i must have missed that.   sounds like my issue is
irrelevant
> > >then.
> > >
> > >danny
> > >
> > >
> > mm1: Danny, in the two comments that are extracted from Assaf below,
> > don't we still have two items to clarify either by improvement in
> > specification wording or more definition clarity. Assaf states the two
> > cases with different conditions:
> >
> >     * Where you have the same partnerLink and portType but a different
> >       correlation set.  How to match the <reply> to the <receive>.
> >     * Where you have a pick and an event handler, the portType,
> >       operation, partnerLink but the process can't deterministically
> >       decide which of the activities to send the message.
> >
> > Thanks.
> >
> > >
> > >
> > >>Arkin:.................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.
> > >>
> > >>........continued...............
> > >>
> > >>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
> > >>
> > >>
> >
> >
> > 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.
>
>