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