|
Alex,
My point is that,
once we rule out regular CorrelationSets (already addressed by the current spec)
and WS-A (ruled out, at least for this BPEL version, by 96), what is left is any
possible way by which a Dispatcher might decide to establish the association
between incoming messages and existing process instances (load-balancing
being just one possibility). That's why I would not be comfortable
with classifying that whole variety of possible strategies under the label of
"implicit correlation set".
Ugo
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 96
is 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 seems
that what
you're suggesting is a clarification, anyway, in which case
we should
probably open this as a bug pending a bit more discussion?
Danny
Alex Yiu wrote:
Hi Yuzo,
IMHO, it do not necessarily create any ConflictReceive
situation, if
one uses message operation properly. Typically, it will involve a
locally scoped partnerLink PLUS a locally scoped
correlation set** (A
number of cases, please see below)
The correlation set would be initialized explicitly or
implicitly by
the <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 the
correlation is
activated implicitly by deployment steps)
o typically engine managed correlation
set(related to Issue
120.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 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#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" 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(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_workgr
oups.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
|