[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
Yes, what is an implementation supposed to do in the last two cases below? It does not seem to make sense to create a second instance with the same correlation value, so it's not possible to throw a fault on a second instance. Should a fault be thrown on the first instance? Ugo > -----Original Message----- > From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] > Sent: Thursday, October 16, 2003 4:30 AM > To: wsbpel@lists.oasis-open.org > 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/le ave_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. 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]