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:]
>Sent: Tuesday, March 08, 2005 2:24 AM
>To:
>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:
>>For additional commands, e-mail:
>>
>>
>>
>>
>
>
>
>
