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:]
> Sent: Thursday, October 16, 2003 9:02 PM
> To: Ugo Corda; Eckenfels. Bernd;
> 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:]
> Sent: Thursday, October 16, 2003 7:05 PM
> To: Eckenfels. Bernd;
> 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:]
> > Sent: Thursday, October 16, 2003 4:30 AM
> > To:
> > 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: - http://www.seeburger.de
> >
> >
> > -----Original Message-----
> > From: Satish Thatte [mailto:]
> > Sent: Tuesday, October 14, 2003 11:54 PM
> > To: Eckenfels. Bernd;
> > 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:]
> > Sent: Tuesday, October 14, 2003 8:48 AM
> > To:
> > 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: - http://www.seeburger.de
> >
> >
> > -----Original Message-----
> > From: Yuzo Fujishima [mailto:]
> > Sent: Tuesday, October 14, 2003 8:22 AM
> > To: Satish Thatte;
> > 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" <>
> > To: "Yuzo Fujishima" <>;
> > <>
> > 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:]
> > Sent: Sat 9/27/2003 2:02 AM
> > To:
> > 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.
