[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] New Issue 215: Conflicting Receive in Parallel Foreach?
I don't believe there is an issue here. The situation described below is exactly identical to using a flow with multiple partnerLinks whose EPRs are pulled out of a single variable. All the same issues apply and those issues are, in my opinion, well specified in the existing spec. Thanks, Yaron Tony Fletcher wrote: > > > This issue has been added to the wsbpel issue list with a status of "received". > The status will be changed to "open" if the TC accepts it as identifying a bug > in the spec or decides it should be accepted specially. Otherwise it will be > closed without further consideration (but will be marked as "Revisitable") > > The issues list is posted as a Technical Committee document to the OASIS WSBPEL > TC pages <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular > basis. The current edition, as a TC document, is the most recent version of the > document entitled **in the "Issues" folder of the WSBPEL TC document list > <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - the next > posting as a TC document will include this issue. The list editor's working > copy, which will normally include an issue when it is announced, is available at > this constant URL <http://www.choreology.com/external/WS_BPEL_issues_list.html>. > > > -------------------------------------------------------------------------------- > > > Issue 215: Conflicting Receive in Parallel Foreach? > > *Status:* received > *Date added:* 4 Jun 2005 > *Categories:* Partner Links > <http://www.choreology.com/external/WS_BPEL_issues_list.html#category_partner_links> > *Date submitted:* 03 June 2005 > *Submitter:* Danny van der Rijn <mailto:dannyv@tibco.com> > *Description:* > > A la Yuzo's issue 208 > <http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue208>, we now > have another case that I'm confused about. Consider the following: > > foreach parallel="yes" > receive partnerlink="foo" operation="bar" > > This will be more likely if, say, I have an "asynchronous" operation with my > partners: > > operation request > operation reply > > I have N partnerlinks, 1 for each of my N partners, on which I send the request > operation, but I only need 1 partnerlink to receive "reply" on. > > So the loop would really look like: > > foreach parallel="yes" > scope > partnerlink name="foo" > assign from="$partnerEPRArray[$foreachIndex]" to="foo" > invoke parterlink="foo" > receive partnerlink="me" > > or something like that. But the part that comes into conflict is the simplified > pseudo-code snippet above. > > Q1: Wouldn't that cause a conflicting receive fault? > Q2: If not, why not? > Q3: If so, do we solve this? > Q4: If not, do we put text in the spec explaining the problem, and why we don't > fix it? > *Changes:* 4 Jun 2005 - new issue > > -------------------------------------------------------------------------------- > > // > > > > > Best Regards, > > Tony/ / > > / <http://www.choreology.com/>/ > > > > Tony Fletcher > > Technical Advisor > Choreology Ltd. > 68, Lombard Street, London EC3V 9L J UK > > Phone: > > > > +44 (0) 1473 729537 > > Mobile: > > > > +44 (0) 7801 948219// > > Fax: > > > > +44 (0) 870 7390077 > > Web: > > > > /www.choreology.com <http://www.choreology.com/>/ > > Cohesions™ > > Business transaction management software for application coordination > > Work: tony.fletcher@choreology.com > > Home: amfletcher@iee.org <mailto:amfletcher@iee.org> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]