[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]