[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?
Ugo, Clarification: Under your description, "dispatcher policies" seem to look like a load-balancing policy? On the other hand, "implicit engine-managed correlation set" is a kind of engine-managed correlation that is bundled / encapsulated within the partnerLink. If one uses WS-A as the message correlation mechansim in a parnterLink, one would not need to mention WS-A in every single message operation. ("invoke", "receive" and etc). Make sense to you? Regards, Alex Yiu Ugo Corda wrote: I am not even sure that it makes sense to talk about "implicit correlation sets". These "implicit correlation sets" might just boil down to specific Dispatcher policies (e.g. the Dispatcher assign the incoming message to the process instance which has been the least active so far), instead of being based on actual information carried on the wire by the message itself (like our regular CorrelationSets, or like other mechanisms based on WS-Addressing). Ugo-----Original Message----- From: Alex Yiu [mailto:alex.yiu@oracle.com] Sent: Monday, June 06, 2005 10:28 AM To: Danny van der Rijn Cc: wsbpel@lists.oasis-open.org; Alex Yiu Subject: Re: [wsbpel] New Issue 215: Conflicting Receive in Parallel Foreach? After Issue 96 is closed, there will be no more spec-standardized Explicit Managed Correlation Sets. But I do envision some vendors may still have Explicit Managed Correlation Sets through the existing extension mechanism. For implicit corelation set, we may just need to have a simple boolean flag on partnerLink declaration to indicate the possibility of implicit correlation set, that may be the clarification result of either 215 or 120.1 Thanks! Regards, Alex Yiu Danny van der Rijn wrote:Hi Alex - I filed this one.. 1) There are no explicit Engine Managed Correlation Sets,now that 96is closed, correct? 2) Implicit Engine Managed Correlation Sets would still have to be portable, and so then may not run on an engine where they do not exist, or run differently. I'm not sure how you envision 120.1 ending up, but it seemsthat whatyou're suggesting is a clarification, anyway, in which casewe shouldprobably open this as a bug pending a bit more discussion? Danny Alex Yiu wrote:Hi Yuzo, IMHO, it do not necessarily create any ConflictReceivesituation, ifone uses message operation properly. Typically, it will involve a locally scoped partnerLink PLUS a locally scopedcorrelation set** (Anumber of cases, please see below) The correlation set would be initialized explicitly orimplicitly bythe <invoke> (preceding the receive) The Correlation Set would be either: * Explicit: (with a construct attached to receive) o "vanilla" correlation set o engine managed correlation set (related to Issue 96) * Implicit: (without an explicit construct by thecorrelation isactivated implicitly by deployment steps) o typically engine managed correlationset(related to Issue120.1) Since we closed Issue 96 with no change, we would need a paragraph from 120.1 to explain two cases of engine managed correlation sets. Thanks! Regards, Alex Yiu Tony Fletcher wrote:This issue has been added to the wsbpel issue list with astatus of"received". The status will be changed to "open" if theTC acceptsit as identifying a bug in the spec or decides it shouldbe acceptedspecially. Otherwise it will be closed without furtherconsideration(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> ona regularbasis. 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#c ategory_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#I ssue208>,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" operationwith my partners: operation request operation reply I have N partnerlinks, 1 for each of my N partners, onwhich I sendthe 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 intoconflict is thesimplified 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(tm) Business transaction management software for application coordination Work: tony.fletcher@choreology.com Home: amfletcher@iee.org <mailto:amfletcher@iee.org>--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]