[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
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/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.
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]