OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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 fact that the instance already created cannot, on the same receive, receive the new message with same correlation value might be obvious to you but not necessarily to everybody else. (Developers at my company, for instance, took the interpretation that something like that would be allowed if the receive happened to be in a loop and active at the time the second message arrives).

We might need to say something very explicit about this point.

Ugo

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Friday, October 17, 2003 9:20 AM
> To: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set 
> More Than
> Once
> 
> 
> The instance already created will obviously not receive the 
> second message if it has no second <receive> corresponding to 
> it.  There is also no fault in that instance since there is 
> no violation within its behavior.  If there is a *second* 
> compatible receive in the process with the same correlation 
> then the second message will be delivered to the same 
> instance (although there is an obvious race in establishing 
> the correlation).  The initial <receive portTypeA 
> createInstance="yes" initiate="yes" /> can obviously not be 
> executed twice just because a second message is available.
> 
> In cases where the message is not received by the original 
> instance, BPEL has nothing to say about what happens.  Note 
> that BPEL does not even say that a message delivered to a 
> process instance is delivered to it exclusively.  In pub/sub 
> architectures that is not in general true.  In queued 
> delivery systems it tends to be true.  We have platforms 
> represented here in the TC for both possibilities.  BPEL does 
> not mandate either delivery mechanism.
> 
> Satish
> 
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
> Sent: Friday, October 17, 2003 8:22 AM
> To: Satish Thatte; Eckenfels. Bernd; wsbpel@lists.oasis-open.org
> 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/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]