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