[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
Ugo Corda wrote: I like this approach better than having to declaring partnerLinks in a scope local to the EventHandler, explicitly.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. 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 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 MonitorA" (and, as a consequence, I don't understand your point about Time 2either). Could you please clarify? Thank you, Ugo |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]