[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
So if we have:
<process>
<flow>
<receive portType="A" createInstance="yes" operation="foo"
variable="A"/>
<receive portType="A" createInstance="yes" operation="bar"
variable="B"/>
</flow>
</process>
then isn't it impossible to ever have a situation in which a single process
instance receives messages on both receives?
For example, if a message comes in for operation foo then a new instance
will be created to handle it. If a message comes in for operation bar then a
new and separate instance will be created. So we now have two separate
instances.
What's confusing me is your comment in the original example that: "You get
one instance with the two messages in two variables."
I'm having trouble seeing how we can have a single instance that received
both messages.
Thanks for taking the time to help clarify this for me,
Yaron
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Monday, October 20, 2003 4:43 PM
> To: ygoland@bea.com
> Cc: Ugo Corda; Eckenfels. Bernd; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set
> More Than
> Once
>
>
> I fortunately didn't specify operations or message types,
> just used the same port ;-) But you are right that this
> would not work if the operations were the same.
>
> Satish
>
> -----Original Message-----
> From: Yaron Goland [mailto:ygoland@bea.com]
> Sent: Monday, October 20, 2003 4:24 PM
> To: Satish Thatte
> Cc: 'Ugo Corda'; 'Eckenfels. Bernd'; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 37 - Initiating Correlation Set
> More Than Once
>
> I'm confused about this example:
> > <process>
> > <flow>
> > <receive portTypeA initial="yes" variable=A/>
> > <receive portTypeA initial="yes" variable=B/>
> > </flow>
> > ...
> > </process>
>
> Section 11.4 states "A business process instance MUST NOT
> simultaneously enable two or more receive activities for the
> same partnerLink, portType, operation and correlation
> set(s)." I am not aware of any exception made for initial
> activities. Therefore wouldn't the previous example be
> illegal assuming that the operation (which isn't specified)
> is the same for both receives? I'm having trouble
> understanding how a single message could, as you state
> "...get one instance with the two messages in two variables."
>
> I appreciate any help you can give in clarifying the issue,
>
> Thanks,
>
> Yaron
>
> > -----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.
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.
<<attachment: winmail.dat>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]