[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
My question was actually different. I have a single <receive portTypeA createInstance="yes" initiate="yes" />, and it gets a message with correlation value X. So a new instance is created with correlation value X. Now along comes this second message on the same portTypeA with identical correlation value X. What do I do: 1. create a second instance with same correlation value X 2. do not create a new instance, and throw fault on the already existing instance with correlation value X 3. consider it a legitimate message for existing instance X and ignore the initiate="yes". Ugo > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Thursday, October 16, 2003 9:02 PM > To: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set > More Than > Once > > > The specification does not prevent something like > <process> > <flow> > <receive portTypeA initial="yes" variable=A/> > <receive portTypeA initial="yes" variable=B/> > </flow> > ... > </process> > > You get one instance with the two messages in two variables. > It also does not currently prevent > > <process> > <flow> > <receive portTypeA initial="yes" variable=A/> > <receive portTypeA initial="yes" variable=A/> > </flow> > ... > </process> > > Although one of the two messages will be lost to the process > instance which receives them. I think it is unnecessary to > eliminate this by restriction. There are many useless things > people can do with a notation as powerful as BPEL and it is > not possible to eliminate all of them by making more rules. > > Satish > > -----Original Message----- > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > Sent: Thursday, October 16, 2003 7:05 PM > To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org > 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/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]