RE: [wsbpel] Issue - 37 - Initiating Correlation Set More Than Once

["Satish Thatte" <satisht@microsoft.com>]

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.