[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, 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/leave_workgroup.php >> >> . >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]