[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
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 >>>>>> >>>>> >>>> >>>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]