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