[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set More Than Once
if you receive 2 messages with the same correlation key to the same port, the first one will create a new instance, the second one is the problem. On the other hand, it will be allowed to receive a message on a different port, with the same correlationb key.
I am refering to the auction example: <process><flow><receive portA initial="yes"/><receive portB initial="yes" /></flow>
in this example
message cor=a port=a
message cor=a port=b
is allowed, also:
message cor=a port=a
message cor=a port=b
but not:
message cor=a port=a
message cor=a port=a
or
message cor=a port=b
message cor=a port=b
right?
Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de
-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Tuesday, October 14, 2003 11:54 PM
To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set More Than
Once
A createInstance receive activity cannot be in a loop since second iteration on it would not be an initial activity. How would it receive a second message?
-----Original Message-----
From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de]
Sent: Tuesday, October 14, 2003 8:48 AM
To: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set More Than Once
Hello,
> B) References to already initialized correlation set are treated as if initiate="no"
> regardless of the specified value.
> -- Only for start activities.
If we have 2 start activities with "initiate=Yes" and on the same correlation set, then the first activity will add a new correlation entry, and the second one is allowed to receive in the same correlation. But neigter the initial receive nor the second receive is allowed to receive another message for that correlation set? No?
Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de
-----Original Message-----
From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com]
Sent: Tuesday, October 14, 2003 8:22 AM
To: Satish Thatte; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 37 - Initiating Correlation Set More Than
Once
Satish,
Thank you for the comment.
As far as I understand, your opinion is very close to, if not the same as, my proposal
(please note the last line):
B) References to already initialized correlation set are treated as if initiate="no"
regardless of the specified value.
-- Only for start activities.
Below is my another try to capture the idea:
B') It is allowed to define a process definition such that multiple start activities
initiate the same correlation set(s). In such case, only the start activity that actually
created the process instance initiates the correlation set(s). For the remaining
start activities, the correaltion set(s) is (are) treated as if initiate="no".
For all other cases, a bpws:correlationViolation fault is thrown if an activity tries
to initiate an already-initiated correlation set.
What do you think?
(I welcome rephrasing.)
Yuzo Fujishima
NEC Corporation
----- Original Message -----
From: "Satish Thatte" <satisht@microsoft.com>
To: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>; <wsbpel@lists.oasis-open.org>
Sent: Monday, October 13, 2003 1:06 PM
Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set More Than Once
Yuzo,
After thinking about this again, my opinion is that we should stick with the intent of the original authors. I recognize the
similarity with the multiple start activities but there is also a crucial difference. In the case of multiple start activities, the
multiple initiations of the correlation are unavoidable since there is no other way to achieve the rendezvous of the multiple
non-deterministically ordered activation messages. In the cases where instance creation is not involved, there must already be a
known correlation for the message to be delivered to the instance and hence it is not a case of rendezvous-by-correlation. I cannot
think of real examples where multiple initiations of a correlation set would be meaningful other than in the multiple start
activities case. I therefore have to agree with Yaron that this is most likely to arise as a process design error.
Satish
________________________________
From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com]
Sent: Sat 9/27/2003 2:02 AM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 37 - Initiating Correlation Set More Than Once
Hi,
Here is my summary of our discussion on Issue 37 at the last F2F meeting:
Issue 37: What will happen if a correlation set is initiated more than once
during the lifetime of the corresponding scope?
The intent of the original authors was (Satish)
A) bpws:correlationViolation fault is always thrown
-- for executable processes and the situation is marked as "undefined"
for abstract processes.
My comment was:
A is somewhat incompatible with the interpreation of the Mulitple Start Activities
example described in the specification document.
My proposal was:
B) References to already initialized correlation set are treated as if initiate="no"
regardless of the specified value.
-- Only for start activities. (This line was added today.)
Danny's proposal/comment: (Please correct if wrong)
C) We may introduce an attribute value initiate="yesIfNotYet" or the like.
Somebody's proposal/comment (Sorry I forgot who)(Please correct if wrong)
D) Remove initiate attribute completely. Correlation sets are initialized
at the first use.
Yaron's comment: (Please correct if wrong)
Tolerating multiple initialization may raise the possibility of the user's
making inadvertent mistakes.
Yuzo Fujishima
NEC Corporation
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.
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]