[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 126 - Event Handlers with local partnerLinks & Correlation Sets
Paco, can you please file this as a new issue? As we discussed at the F2F 126 is independent of the very important questions you ask below. Thanks, Yaron > -----Original Message----- > From: Francisco Curbera [mailto:curbera@us.ibm.com] > Sent: Wednesday, June 23, 2004 7:52 AM > To: Prasad Yendluri > Cc: Dieter Koenig1; wsbpel@lists.oasis-open.org; Yaron Goland > Subject: Re: [wsbpel] Issue - 126 - Event Handlers with local > partnerLinks & Correlation Sets > > > > > > The discussion of issue 126 at the F2F meeting yesterday > seemed to indicate that in addition to the issues specific to > the use of partner links and correlation sets on event > handlers there is another generic issue affecting arbitrary > processes. It relates to the following problems: > > - how and when are partner link roles initiated in an > executing process instance. > - what error conditions derive from lack of initiation. > - whether or how the assigned partner "values" of a partner > link should be "enforced" in the case of incoming messages, > by requiring that messages be received only form a specific partner. > > Paco > > > > > > > Prasad Yendluri > > <pyendluri@webmet To: > ygoland@bea.com > > hods.com> cc: > Dieter Koenig1 <dieterkoenig@de.ibm.com>, > wsbpel@lists.oasis-open.org > Subject: Re: > [wsbpel] Issue - 126 - Event Handlers with local partnerLinks & > 06/18/2004 01:08 Correlation > Sets > PM > > > > > > > > Yaron, > > I will be at the f2f. We can pick this up during that time. I > could use a level set on this as well. > > Regards, Prasad > > Yaron Y. Goland wrote: > > > There seem to be assumptions in your analysis about how > BPEL messaging > > works that are fundamentally different than my own. Without > addressing > > those underlying assumptions I don't believe we can have further > > productive discussion on this issue. It has been my general > experience > > that e-mail is an unproductive way to try and synchronize on > > fundamental concepts. Therefore I propose that we table this > > discussion for the moment and re-start it during the F2F > when we will > > have a much higher bandwidth with which to work. > > > > Please let me know if you will be unable to make the F2F. > In that case > > we can arrange a phone call if that would be acceptable to you. > > > > Thanks, > > > > Yaron > > > > Prasad Yendluri wrote: > > > >> Yaron, > >> > >> Please see below.. > >> > >> Regards, Prasad > >> > >> Yaron Y. Goland wrote: > >> > >> > If I understand the proposal correctly then it would > make the > > >> following scenario nearly impossible to support. > >> > > >> > scope > >> > partnerLinks > >> > partnerLink name="A" > >> > eventHandlers > >> > onEvent partnerLink="A" > >> > do stuff... > >> > ... > >> > > >> > In this code partnerLink A is not initialized anywhere. > However, > >> if a > message arrives that matches the onEvent element > then it will > >> be > 'caught' by the onEvent handler and a local copy of > partnerLink > >> A will > be created and partnerRole on the local copy of > partnerLink > >> A will be > initialized to point at who ever sent the message. > >> > > >> > Now lets say that the desired semantics are that when the first > >> event > arrives the partnerLink's partnerRole initialized > to point > >> at the > sender and then future events will ONLY be accepted from > >> that specific > sender in the future. > >> > >> I don't think this is possible unless the end-point is > hardwired to > >> the partnerLink A itself at the point when messages on that link > >> should only come from a particular end-point. I am not > sure if that > >> is possible unless it is statically bound before the > process starts. > >> How do you prevent someone sending a message on a port (and > >> operation) if it is valid (authorized) for them to send it? > >> > >> The event is triggered based on the receiving endpoint side of the > >> partnerLink receiving a specific type of message and the > partnerLink > >> at that instance reflects the end-points corresponding to > both sides > >> of the link. > >> > >> I don't think we have a mechanism to retrieve the > end-point address > >> from the BPEL process for the partnerRole and selectively > reject the > >> message from a eventHandler; to reject such messages or > require that > >> messages comes from only a particular end-point etc. > >> > >> So, IMO this scenario is not possible. What is possible is > to create > >> a local copy of the partnerLink in an eventHandler so that > the reply > >> can be routed to the correct end-point by the infrastructure (by > >> caching the partnerRole end-point). This is so that multiple > >> (concurrent) activations of the EventHandler from messages > received > >> from the same or different partnerRole endpoints can > function without conflict. > >> > >> Hence putting onus on the BPEL engine infrastructure to create an > >> implicit copy of the partnerLink in the scope of the > eventHandler is > >> the right approach IMHO. > >> > >> > That's mostly impossible if a local copy of partnerLink A is > >> created > because the initialization upon receiving the > message will > >> only apply > to the local copy of A and any other instance of the > >> event handler > will not see it. > >> > > >> > But in the current proposal to resolve 126 a local copy > is only > > >> created if the programmer explicitly asks for it by > including a local > >> > partnerLink declaration as a child of the onEvent element. > >> > > >> > In other words, the current proposal gives the > programmer a choice. > >> > They can either use a common partnerLink whose state is > visible to > >> all > instances of the event handler or they can use a local > >> partnerLink > whose state is only visible to a single > instance. Both > >> choices are > required in order to support the two > scenarios defined > >> in > > >> <http://lists.oasis-open.org/archives/wsbpel/200406/msg00046.html>. > >> > > >> > Yaron > >> > > >> > Dieter Koenig1 wrote: > >> > > >> >> +0.5 :-) > >> >> > >> >> I agree with Prasad's explanation for the first part > of the issue: > >> >> > Each EventHandler instance (when it is activated) gets a > >> separate >> > copy of the already declared partnerLink with > >> initialized endpoint >> value >> >> > for the > partnerRole, in the > >> scope that is local to the EventHandler >> > instance. > If the event > >> gets triggered from message sent from >> different >> > > end-points > >> (over the life of the scope that contains the >> > EventHandler) >> > >> > or by the same end-point it would not matter. > >> >> In other words, "A private copy of all process data > and control > >> behavior >> defined within an event handler is provided to each > >> instance of an event >> handler" applies to partner links as well. > >> >> > >> >> Kind Regards > >> >> DK > >> >> > >> >> > >> >> > > >> > >> >> Prasad > >> >> Yendluri > >> >> <pyendluri@webmet > >> >> >> > >> hods.com> To > >> >> >> > >> ygoland@bea.com 16.06.2004 > >> >> 23:41 cc > >> >> >> > >> wsbpel@lists.oasis-open.org > >> >> > >> >> Subject > >> >> Re: [wsbpel] > Issue - 126 - > >> >> Event > Handlers with local > >> >> partnerLinks & > Correlation > >> >> Sets > >> >> > > >> > >> >> >> Yaron Y. Goland wrote: > >> >> > >> >> > By "@" I assume you mean attribute? > >> >> > > >> >> > So are you suggesting that if the partnerLink named in the > >> attribute > >> >> > has already been declared in an outer scope then we use that > >> >> > partnerLink and otherwise we implicitly declare it? > >> >> > >> >> No. Each EventHandler instance (when it is activated) gets a > >> separate > >> >> copy of the already declared partnerLink with initialized > >> endpoint value > >> >> for the partnerRole, in the scope that is local to the > EventHandler > >> >> instance. If the event gets triggered from message sent from > >> different > >> >> end-points (over the life of the scope that contains the > >> EventHandler) > >> >> or by the same end-point it would not matter. It is a > clone of the > >> >> global (to the EventHandler scope) partnerLink. > >> >> > >> >> > If so I am worried that such an approach would lead > to typos not > >> >> being > >> >> > caught. > >> >> > >> >> No scope for typos. The partnerLink reference in the > EventHandler > >> >> (onEvent) must reference an already declared > partnerLink that is > >> visible > >> >> to the in the scope of the EventHandler and can be > caught via static > >> >> analysis. > >> >> > >> >> > Don't we need an explicit mechanism for the BPEL > programmer to > >> say "I > >> >> > INTEND this partnerLink to be local to a single instance of > >> the event > >> >> > handler"? After all, if they don't put in the > 'intention' flag > >> and > >> >> the > >> >> > named partnerLink hasn't been declared in an ancestor scope > >> then the > >> >> > system knows that something has gone wrong. Without > the flag the > >> >> > system would just assume that the partnerLink was > intended to be > >> >> local > >> >> > to the event handler which could be an erroneous assumption. > >> >> > > >> >> > Yaron > >> >> > > >> >> > Prasad Yendluri wrote: > >> >> > > >> >> >> Yaron, > >> >> >> > >> >> >> I agree with both of your use cases (or the need > to accommodate > >> >> them). I > >> >> >> am suggesting we resolve this via the implicit > local partnerLink > >> >> >> creation approach and leave the partnerLink as an @ in the > >> >> eventHandler > >> >> >> declaration, rather than requiring to create a > local partnerLink > >> >> >> explicitly. > >> >> >> > >> >> >> Regards, Prasad > >> >> >> > >> >> >> Yaron Y. Goland wrote: > >> >> >> > >> >> >> > I'm not sure if you are agreeing or disagreeing > with my two > >> >> suggested > >> >> >> > scenarios. It sounds like you agree with #1. > But what about > >> >> #2? In > >> >> >> > that case you would intentionally not want to > use a local > >> >> >> partnerLink. > >> >> >> > > >> >> >> > Just checking, > >> >> >> > > >> >> >> > Yaron > >> >> >> > > >> >> >> > Prasad Yendluri wrote: > >> >> >> > > >> >> >> >> Hi, > >> >> >> >> > >> >> >> >> I am not seeing any conflict in creating a > local partnerLink > >> >> >> (that is > >> >> >> >> identical), when the eventHandler in its life > receives the > >> >> message > >> >> >> >> from the same end-point all the time or from different > >> >> end-points. > >> >> >> >> There is a bit of processing overhead in > creating the local > >> >> >> >> partnerLink (implicitly), which is not very > high IMO, for > >> the > >> >> >> >> convenience it offers. > >> >> >> >> > >> >> >> >> Regards, Prasad > >> >> >> >> > >> >> >> >> -------- Original Message -------- > >> >> >> >> Subject: Re: [wsbpel] Issue - 126 - Event > Handlers with > >> >> local > >> >> >> >> partnerLinks & Correlation Sets > >> >> >> >> Date: Tue, 15 Jun 2004 09:19:12 -0700 > >> >> >> >> From: Yaron Y. Goland <ygoland@bea.com> > >> >> <mailto:ygoland@bea.com> > >> >> >> >> Reply-To: ygoland@bea.com <mailto:ygoland@bea.com> > >> >> >> >> Organization: BEA > >> >> >> >> To: Prasad Yendluri <pyendluri@webmethods.com> > >> >> >> >> <mailto:pyendluri@webmethods.com> > >> >> >> >> CC: Ugo Corda <UCorda@SeeBeyond.com> > >> >> >> >> <mailto:UCorda@SeeBeyond.com>, > wsbpel@lists.oasis-open.org > >> >> >> >> <mailto:wsbpel@lists.oasis-open.org> > >> >> >> >> > >> >> >> >> > >> >> >> >> There are two different scenarios for event handlers. I > >> >> believe we > >> >> >> >> need to support both of them. > >> >> >> >> > >> >> >> >> 1) The event handler uses a new partnerLink > for each message > >> >> (thus > >> >> >> >> allowing it to accept any message that matches both > >> operation > >> >> and > >> >> >> >> correlation set) > >> >> >> >> > >> >> >> >> 2) The event handler always uses the same partnerLink > >> >> >> >> > >> >> >> >> My proposed change to BPEL would support both of these > >> >> scenarios. > >> >> >> >> > >> >> >> >> Yaron > >> >> >> >> > >> >> >> >> Prasad Yendluri wrote: > >> >> >> >> > >> >> >> >>> > >> >> >> >>> Ugo Corda wrote: > >> >> >> >>> > >> >> >> >>>> I think the difficulty I am having with your Part A > >> example is > >> >> >> that > >> >> >> >>>> the > >> >> >> >>>> BPEL spec is not very clear about the rules > for endpoint > >> >> >> >>>> initialization > >> >> >> >>>> of partnerLinks. > >> >> >> >>>> > >> >> >> >>>> In the specific case of Event Handlers, one > interpretation > >> >> >> could be > >> >> >> >>>> that, like in our resolution for issue 36, each Event > >> Handler > >> >> >> instance > >> >> >> >>>> gets a separate copy of the partnerLink with an > >> uninitialized > >> >> >> endpoint > >> >> >> >>>> value. So at Time 2 a new instance of the handler is > >> created > >> >> >> with a > >> >> >> >>>> copy > >> >> >> >>>> of partnerLink having an uninitialized > endpoint value, > >> >> which is > >> >> >> >>>> then set > >> >> >> >>>> to point to monitor B. > >> >> >> >>>> > >> >> >> >>> I like this approach better than having to declaring > >> >> >> partnerLinks in > >> >> >> >>> a scope local to the EventHandler, explicitly. > >> >> >> >>> Only thing is, the partnerLink end-point > (corresponding the > >> >> >> >>> partnerRole) would be set to the correct > value, based on > >> >> >> >>> where the message that triggered the event > originated from, > >> >> rather > >> >> >> >>> than being uninitialized and then set (by who?). > >> >> >> >>> > >> >> >> >>> Now the reply will get routed to the correct > end-point. > >> >> >> >>> > >> >> >> >>> I guess this would amount to an implicit > local partnerLink > >> >> >> >>> declaration with the same name, > >> >> >> >>> at the same time keeping the current syntax > where it is > >> >> obvious on > >> >> >> >>> which parterLink the event is expected etc. > >> >> >> >>> > >> >> >> >>> Regards, Prasad > >> >> >> >>> > >> >> >> >>>> Ugo > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>>> -----Original Message----- > >> >> >> >>>>> From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: > >> >> Monday, June > >> >> >> >>>>> 14, 2004 2:41 PM > >> >> >> >>>>> To: Ugo Corda > >> >> >> >>>>> Cc: wsbpel@lists.oasis-open.org > >> >> >> >>>>> <mailto:wsbpel@lists.oasis-open.org> > >> >> >> >>>>> <mailto:wsbpel@lists.oasis-open.org> > >> >> >> >>>>> Subject: Re: [wsbpel] Issue - 126 - Event Handlers > >> with local > >> >> >> >>>>> partnerLinks & Correlation Sets > >> >> >> >>>>> > >> >> >> >>>>> > >> >> >> >>>>> In the example the partnerLink monitor is > uninitialized. > >> >> >> Monitor A > >> >> >> >>>>> then sends a message to the BPEL process. > Monitor A's > >> >> message is > >> >> >> >>>>> caught by the BPEL process's event handler. As a > >> >> consequence the > >> >> >> >>>>> Monitor partnerLink partnerRole value > (being used for the > >> >> first > >> >> >> >>>>> time in the BPEL process) is initialized to point at > >> >> Monitor A. > >> >> >> >>>>> > >> >> >> >>>>> This then leads to time 2 where monitor B, > a separate web > >> >> >> service, > >> >> >> >>>>> also sends a message to the BPEL process. > This message > >> >> will match > >> >> >> >>>>> on portType, operation and probably even > correlation set > >> >> but it > >> >> >> >>>>> can't be caught by the event handler > because the event > >> >> handler > >> >> >> >>>>> receives messages using the partnerLink monitor and > >> that is > >> >> >> >>>>> already initialized to point to monitor A so, by > >> >> definition, it > >> >> >> >>>>> cannot be used to receive a message from monitor B. > >> >> >> >>>>> > >> >> >> >>>>> In BPEL today there is no way to write an > event handler > >> >> which can > >> >> >> >>>>> accept messages from multiple different > partners so that > >> >> simple > >> >> >> >>>>> scenarios like receiving asynchronous updates from > >> multiple > >> >> >> >>>>> sources are almost impossible to implement. > >> >> >> >>>>> > >> >> >> >>>>> Yaron > >> >> >> >>>>> > >> >> >> >>>>> Ugo Corda wrote: > >> >> >> >>>>> >>>>> > >> >> >> >>>>>> Yaron, > >> >> >> >>>>>> As I am reading your Part A, I don't fully > understand > >> what > >> >> >> you mean, > >> >> >> >>>>>> under Time 1, by "partnerLink monitor is > initialized to > >> >> point at > >> >> >> >>>>>> Monitor A" (and, as a consequence, I don't > understand > >> >> your point > >> >> >> >>>>>> about Time 2 either). Could you please clarify? > >> >> >> >>>>>> > >> >> >> >>>>>> Thank you, > >> >> >> >>>>>> Ugo > >> >> >> >>>>>> >>>>> > >> >> >> >> > >> >> >> >> Yaron Y. Goland wrote: > >> >> >> >> > >> >> >> >>> There are two different scenarios for event > handlers. I > >> >> believe we > >> >> >> >>> need to support both of them. > >> >> >> >>> > >> >> >> >>> 1) The event handler uses a new partnerLink for each > >> message > >> >> (thus > >> >> >> >>> allowing it to accept any message that matches both > >> >> operation and > >> >> >> >>> correlation set) > >> >> >> >>> > >> >> >> >>> 2) The event handler always uses the same partnerLink > >> >> >> >>> > >> >> >> >>> My proposed change to BPEL would support both of these > >> >> scenarios. > >> >> >> >>> > >> >> >> >>> Yaron > >> >> >> >>> > >> >> >> >>> Prasad Yendluri wrote: > >> >> >> >>> > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> Ugo Corda wrote: > >> >> >> >>>> > >> >> >> >>>>> I think the difficulty I am having with your Part A > >> >> example is > >> >> >> >>>>> that the > >> >> >> >>>>> BPEL spec is not very clear about the rules > for endpoint > >> >> >> >>>>> initialization > >> >> >> >>>>> of partnerLinks. > >> >> >> >>>>> > >> >> >> >>>>> In the specific case of Event Handlers, one > >> interpretation > >> >> >> could be > >> >> >> >>>>> that, like in our resolution for issue 36, > each Event > >> Handler > >> >> >> >>>>> instance > >> >> >> >>>>> gets a separate copy of the partnerLink with an > >> uninitialized > >> >> >> >>>>> endpoint > >> >> >> >>>>> value. So at Time 2 a new instance of the handler is > >> >> created with > >> >> >> >>>>> a copy > >> >> >> >>>>> of partnerLink having an uninitialized > endpoint value, > >> >> which is > >> >> >> >>>>> then set > >> >> >> >>>>> to point to monitor B. > >> >> >> >>>>> > >> >> >> >>>> I like this approach better than having to declaring > >> >> partnerLinks > >> >> >> >>>> in a scope local to the EventHandler, explicitly. > >> >> >> >>>> Only thing is, the partnerLink end-point > (corresponding > >> the > >> >> >> >>>> partnerRole) would be set to the correct > value, based on > >> >> >> >>>> where the message that triggered the event originated > >> from, > >> >> rather > >> >> >> >>>> than being initialized and then set (by who?). > >> >> >> >>>> > >> >> >> >>>> Now the reply will get routed to the correct > end-point. > >> >> >> >>>> > >> >> >> >>>> I guess this would amount to an implicit > local partnerLink > >> >> >> >>>> declaration with the same name, > >> >> >> >>>> at the same time keeping the current syntax > where it is > >> >> obvious on > >> >> >> >>>> which parterLink the event is expected etc. > >> >> >> >>>> > >> >> >> >>>> Regards, Prasad > >> >> >> >>>> > >> >> >> >>>>> Ugo > >> >> >> >>>>> > >> >> >> >>>>> >>>>> > >> >> >> >>>>>> -----Original Message----- > >> >> >> >>>>>> From: Yaron Y. Goland > [mailto:ygoland@bea.com] Sent: > >> Monday, > >> >> >> June > >> >> >> >>>>>> 14, 2004 2:41 PM > >> >> >> >>>>>> To: Ugo Corda > >> >> >> >>>>>> Cc: wsbpel@lists.oasis-open.org > >> >> >> >>>>>> <mailto:wsbpel@lists.oasis-open.org> > >> >> >> >>>>>> <mailto:wsbpel@lists.oasis-open.org> > >> >> >> >>>>>> Subject: Re: [wsbpel] Issue - 126 - Event > Handlers with > >> >> local > >> >> >> >>>>>> partnerLinks & Correlation Sets > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>>> In the example the partnerLink monitor is > uninitialized. > >> >> Monitor > >> >> >> >>>>>> A then sends a message to the BPEL > process. Monitor A's > >> >> message > >> >> >> >>>>>> is caught by the BPEL process's event handler. As a > >> >> consequence > >> >> >> >>>>>> the Monitor partnerLink partnerRole value > (being used > >> for > >> >> the > >> >> >> >>>>>> first time in the BPEL process) is initialized to > >> point at > >> >> >> >>>>>> Monitor A. > >> >> >> >>>>>> > >> >> >> >>>>>> This then leads to time 2 where monitor B, > a separate > >> web > >> >> >> >>>>>> service, also sends a message to the BPEL > process. This > >> >> message > >> >> >> >>>>>> will match on portType, operation and probably even > >> >> correlation > >> >> >> >>>>>> set but it can't be caught by the event handler > >> because the > >> >> >> event > >> >> >> >>>>>> handler receives messages using the > partnerLink monitor > >> >> and that > >> >> >> >>>>>> is already initialized to point to monitor A so, by > >> >> definition, > >> >> >> >>>>>> it cannot be used to receive a message > from monitor B. > >> >> >> >>>>>> > >> >> >> >>>>>> In BPEL today there is no way to write an > event handler > >> >> which > >> >> >> can > >> >> >> >>>>>> accept messages from multiple different > partners so that > >> >> simple > >> >> >> >>>>>> scenarios like receiving asynchronous updates from > >> multiple > >> >> >> >>>>>> sources are almost impossible to implement. > >> >> >> >>>>>> > >> >> >> >>>>>> Yaron > >> >> >> >>>>>> > >> >> >> >>>>>> Ugo Corda wrote: > >> >> >> >>>>>> >>>>>> > >> >> >> >>>>>>> Yaron, > >> >> >> >>>>>>> As I am reading your Part A, I don't > fully understand > >> >> what you > >> >> >> >>>>>>> mean, > >> >> >> >>>>>>> under Time 1, by "partnerLink monitor is > initialized to > >> >> >> point at > >> >> >> >>>>>>> Monitor A" (and, as a consequence, I don't > >> >> understand your > >> >> >> >>>>>>> point about Time 2 either). Could you please > >> clarify? > >> >> >> >>>>>>> > >> >> >> >>>>>>> Thank you, > >> >> >> >>>>>>> Ugo > >> >> >> >>>>>>> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>> >>>>> > >> >> > > >> >> > > >> >> > >> >> > >> >> 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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]