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