Re: [wsbpel] Issue 132 - Proposal For Vote

[Assaf Arkin <arkin@intalio.com>]

That means my fault handlers and termination handlers cannot depend on 
variables, partner links and correlation sets existing in the scope, 
even though they are locally declared.

I don't see the scope ever being terminated before the main activity 
started executing. Since nothing happened in the scope, conceptually we 
can think of all variable initialization as being atomic. Either you do 
them, start the main activity and terminate, or you do nothing and need 
no termination handler.

I don't see the scope handling a fault arising from its creation either.

Assaf

Trickovic, Ivana wrote:

>Below please find proposed amendment to issue 132 we discussed last
>week. Thanks Chris for feedback. 
>
>Regards,
>
>Ivana
>
>
>Amendment to the updated proposal for 132
>
>Proposal: Treat the scope initialization sequence as an atomic unit. 
>---------
>
>Rationale: 
>----------
>The updated proposal suggests that scope initialization is a sequence of
>instantiations including the following 4 steps:
>1) fault handlers and termination handlers
>2) partner links and correlation sets
>3) variables, including any variable initializations
>4) main activity and event handlers 
>
>However, the proposal does not require these 4 steps to be executed as
>an atomic unit (that means in an all-or-nothing manner). The proposal
>states that a fault that may occur during scope initialization, e.g.
>variable initialization failure, may be captured by one of the locally
>defined fault handlers, although the scope is not completely initialized
>and is just
>In the middle of the initialization. In this case, according to the
>semantics of fault handlers, the activity of the locally defined fault
>handler is executed in the scope which is not completely initialized
>(e.g. variables, partner links and correlation sets will be in an
>unknown state).
>
>
>This amendment suggests the following change to the proposed text.
>
>Original Proposal Text:
>=======================
>When a scope is entered the follow items are instantiated in the
>following order:
>1) fault handlers and termination handlers
>2) partner links and correlation sets
>3) variables, including any variable initializations
>4) main activity and event handlers 
>
>Items listed together in the same numbered item are created without a
>predefined order in respect to each other. Each  numbered item MUST
>complete instantiation before continuing on to the next numbered item.
>Some consequences of the previous ordering include that a variable
>initialization can refer to partner links or correlation sets defined on
>the same scope
>and that if a variable initialization throws a fault the fault handlers
>on the local scope will receive the fault. Note that in the case of a
>scope that contains the initial start activity (either directly or as a
>progeny) the initial start activity MUST complete before the event
>handlers of that scope are instantiated.
>
>Amended text:
>=============
>When a scope is entered the follow items are performed:
>1) Instantiate partner links, correlation sets 
>2) Instantiate and initialize variables
>3) Install event handlers, fault handlers and termination handlers
>4) Execute main activity
>
>Steps 1 through 3 are considered the scope initialization sequence.  The
>scope initialization sequence is an atomic unit. If any step within the
>sequence experiences a problem standard fault
>"bpws:scopeInitializationFailure" must be thrown. The fault is thrown to
>the immediately enclosing scope.  Items listed together in the same
>numbered item are performed without a predefined order in respect to
>each other. Each numbered item MUST complete instantiation before
>continuing on to the
>next numbered item. Note that in the case of a scope that contains the
>initial start activity (either directly or as a progeny) the event
>handlers of that scope are available AFTER the initial start activity
>has completed.
>
>
>
>-----Original Message-----
>From: Yaron Y. Goland [mailto:ygoland@bea.com] 
>Sent: Tuesday, March 08, 2005 9:42 PM
>To: wsbpeltc
>Subject: [wsbpel] Issue 132 - Proposal For Vote
>
>
>I have included a HTML file with change markings reflecting the changes 
>I understood us to agree to at today's F2F.
>	Thanks,
>		Yaron
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>
>  
>

begin:vcard
fn:Assaf Arkin
n:Arkin;Assaf
org:Intalio
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
email;internet:arkin@intalio.com
title:Chief Architect
tel;work:(650) 596-1800
x-mozilla-html:TRUE
url:http://www.intalio.com
version:2.1
end:vcard

S/MIME Cryptographic Signature