[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
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]