OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel] Issue 126 - Proposal For Vote

I think this would go a bit too far -- for instance we don't want to
compensate event handler instances.

-----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.


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]