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 132 - Proposal For Vote


-1

-----Original Message-----
From: Danny van der Rijn [mailto:dannyv@tibco.com] 
Sent: Tuesday, March 15, 2005 5:26 PM
To: Trickovic, Ivana
Cc: ygoland@bea.com; wsbpel@lists.oasis-open.org;
chris.keller@active-endpoints.com
Subject: Re: [wsbpel] Issue 132 - Proposal For Vote

The implication of this are that a faulty variable initialization in 
nested scope N will cause parent scope P to fail.  I don't like that 
implication.  Doesn't do wonders for modular programming.  I would 
prefer to leave the order that was there.  However, the addition of your 
"bpel:scopeInitializationFailure" fault gives someone the chance to 
catch it in scope, *knowing that the variables don't exist*.  There is 
still the problem that they could have a catchAll that uses the 
variables, but I think that the tradeoff is reasonable.

Danny

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

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