[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 126 - Proposal For Vote
The point I was making is that it is not the same set of functionality -- it is a very specific subset -- local declarations of entities. But no handlers of any kind, no ability to override things like suppressJoinFailure default, etc. We have no syntactic base for the subset we are replicating. -----Original Message----- From: Assaf Arkin [mailto:arkin@intalio.com] Sent: Tuesday, March 08, 2005 5:40 AM To: Satish Thatte Cc: ygoland@bea.com; wsbpeltc Subject: Re: [wsbpel] Issue 126 - Proposal For Vote Satish Thatte wrote: >I think this would go a bit too far -- for instance we don't want to >compensate event handler instances. > > I'm not too concerned about allowing compensation of event handlers, or even enclosing event handlers within event handlers. You can already do that by enclosing the main activity in a scope. The shortcut I'm looking for is to have less text in the spec to provide the same set of functionality. Assaf >-----Original Message----- >From: Assaf Arkin [mailto:arkin@intalio.com] >Sent: Tuesday, March 08, 2005 2:24 AM >To: ygoland@bea.com >Cc: wsbpeltc >Subject: Re: [wsbpel] Issue 126 - Proposal For Vote > >Why don't we just define onEvent as an extension of scope? > >That would allow us to have local partner links, local variable >declarations and local correlation sets, all of which seem quite useful >for event handlers that can be invoked more than once. And it will >simplify the specification if we don't have to explain how >links/variables/correlations are used in two different contexts, when >the usage is identical. > >assaf > >Yaron Y. Goland wrote: > > > >>Note: This new proposal adds text to the original proposal to provide >>a more robust model to explain exactly how the local message variable >>and inline correlation sets on an onEvent handler actually work. But >>this proposal does not add or remove any functionality from the >>original proposal. >> >>Issue 126 - Event Handlers with local partnerLinks & Correlation Sets >> >>Disclaimer: This proposal is contingent on my propose for 139 passing >> >>Proposal: Add the ability to declare correlation sets inside of an >>onEvent handler for use within a specific onEvent instance. >> >>Rationale: Issue 126 brought up two questions. The first question was >>based on my assumption that partnerRoles are used to filter incoming >>messages on receives/picks/onEvent handlers. My proposal for issue 139 >> >> > > > >>would make that assumption invalid and so remove my first question. >>My second question had to do with correlation set initialization on >>event handlers. In some cases, such as the example I gave in the issue >> >> > > > >>list, we want to be able to have a correlation set whose value is >>local to a single event handler instance. >> >>Section 13.5.1 >> >>From: The usage and interpretation of correlation is exactly the same >>as for receive activities. >> >>To: The usage and interpretation of correlation is exactly the same as >> >> > > > >>for receive activities with the addition that it is possible to >>declare correlation sets inline to an onEvent handler instance. These >>inline correlation sets can then be used as part of onEvent's receive. >> >> > > > >>In effect something like a virtual scope is declared around the >>onEvent handler which contains a local variable declaration for the >>variable used to receive the incoming message, a local correlation set >> >> > > > >>declaration for any correlation sets declared inline to the onEvent >>handler and a sequence with a receive, reflecting the receive >>parameters of the onEvent handler, and finally the actual activity >>contained within the onEvent handler declaration. However this virtual >> >> > > > >>scope is fundamentally different than a real scope in that it has >>neither fault nor compensation handlers, default or otherwise, it also >> >> > > > >>has no name. The scope exists, such as it can be said to exist at all >>given that it is only intended as a model to understand the onEvent >>handler's variable behavior and not as an actual entity, only to >>provide lexical scoping for the local message variable and inline >>correlation sets. For example: >> >>... >><scope name="S1"> >><compensationHandler> >><sequence> >><compensate scope="S2"/> >></sequence> >></compensationHandler> >><eventHandlers> >><onEvent partnerLink="travelAgency" >>portType="ns:agent" >>operation="travelUpdate" >>messageType="ns:travelStatsUpdate" >>variable="travelUpdate"> >><correlationSets> >><correlationSet name="updateCode" properties="ns:updateCode"/> >></correlationSets> >><correlations> >><correlation set="travelCode" initialize="no"/> >><correlation set="updateCode" initialize="yes"/> >></correlations> >><scope name="S2"> >>... >></scope> >></eventHandlers> >>... >></scope> >>... >> >>In this example a process is managing travel reservations for a >>customer and needs to handle reservation updates from the travel >>booking system. The onEvent handler is used to receive the update >>messages which are correlated using the travelCode property, which is >>defined and initialized elsewhere in the process. However sometimes >>the event handler needs to contact the travel booking system to follow >> >> > > > >>up on an update message. To do that the outgoing message needs both >>the value in the travelCode property but also the value in an update >>code included in the travel update message. This is where the >>updateCode correlation set, declared locally to the onEvent handler >>comes in. When the update message is received the updateCode >>correlation set is initialized and its value made available only to >>the onEvent handler instance. Note that the compensation handler on >>scope S1 directly invokes the compensation handler on scope S2 defined >> >> > > > >>inside the onEvent handler. This invocation is legal because the >>'notional' virtual scope described above to handle lexical scoping >>issues for the onEvent handler does not exist for purposes of >>determining which scopes are considered a child of the parent scope >>S1. Therefore, from the perspective of the compensation handler scope >>S2 is a child of scope S1. Note however that if S2's compensation >>handler was invoked the variable used to receive the message for the >>onEvent handler as well as any in-line correlation sets would be >>visible as the 'notional' virtual scope does have existence for the >>purpose of defining the lexical scope for the onEvent handler's >>variables. >> >>The BNF for eventHandlers needs to be updated in sections 6.2 and 13.5 >> >> > > > >>to the following: >><eventHandlers>? >><!-- Note: There must be at least one onEvent or onAlarm handler. --> >><onEvent partnerLink="ncname" portType="qname"? >>operation="ncname" messageType="qname" variable="ncname" >>messageExchange="ncname"? >* >>* <correlationSets>? >>* <correlationSet name="ncname" properties="qname-list"/>+ >>* </correlationSets> >><correlations>? >><correlation set="ncname" >>initiate="yes|rendezvous|no"?/>+ >></correlations> >>activity >></onEvent> >><onAlarm>* >>( <for expressionLanguage="anyURI"?>duration-expr</for> | >><until expressionLanguage="anyURI"?>deadline-expr</until> )? >><repeatEvery expressionLanguage="anyURI"?>duration-expr</repeatEvery>? >> >> > > > >>activity >></onAlarm> >></eventHandlers> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org >>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org >> >> >> >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]