[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 49 - Proposal for Vote
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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]