Re: [wsbpel] RE: [ws-bpel] Issue - 119 - Transition Conditions andInvoke Fault Handlers

[rkhalaf <rkhalaf@watson.ibm.com>]

Hi Maciej,

I think you and I are thinking on the same lines.
I had been playing with this ppt diagram:


The solution on the right hand is what makes more intuitive sense, but 
introduces two scopes if you have sj or comphandler. I think that what 
you're proposing below as well ?



Maciej Szefler wrote:
> Rania,
> 
> I was waiting for someone to mention suppressJoinFailure.  Let me try to
> rephrase what I think you are trying to say. In the following:
> 
> <invoke suppressJoinFailure="yes" >
>     <target linkName="l1" />
>     <source linkName="l2" tcond="t2()" />
>     <catcAll> ... </>
> </invoke> 
> 
> We would expect that l1 = false --> l2 = false (basic DPE)
> Using the current implicit scope scheme we get:
> <scope>
> 
>   <catch faultName="bpws:suppressJoinFailure"> <empty/> </>
>   <catchAll> ... </>
> 
>   <invoke >
>     <source linkName="l2" tcond="t2()" />
>     <target linkName="l1" />
>   </invoke>
> </scope>
> 
> this works as expected: l1=false will cause fault which will be caught
> by the scope, which will set the outgoing link l2 to false. This is fine
> when l1 = false, but when l1 = true, and if t2() faults, the catchAll
> unexpectedly catches the fault (i.e. issue 119). 
> 
> However, with the re-write I alluded to:
> <scope>
>   <source linkName="l2" tcond="t2()" />
> 
>   <catch faultName="bpws:suppressJoinFailure"> <empty/> </>
>   <catch faultName="someInvokeFault"> ... </>
> 
>   <invoke >
>        <target linkName="l1" />
>   </invoke>
> </scope>
> 
> the issue 119 problem is eliminated, (that is when l1 = true and t2()
> faults, the catchAll will not catch it) but a DPE problem is introduced.
> Here, if l1 = false, we get a joinFailure fault which will be caught by
> the enclosing scope. This will cause scope to "complete" (although
> unsuccessfully) which will result in the (unexpected) evaluation of
> t2(), but we were expecting l2 to be set false through DPE. 
> 
> To actually get the effect that I think we want to get, we'd need to do
> the following:
> <scope>
>   <catch faultName="bpws:suppressJoinFailure"> <empty/> </>
> 
>   <scope>
>     <source linkName="l2" tcond="t2()" />
>     <catch faultName="someInvokeFault"> ... </>
>     <invoke >
>         <target linkName="l1" />
>     </invoke>
>   </scope>
> </scope>     
> 
> So, two implicit scopes. 
> 
> This has implications not only on invoke, but also on scope itself:
> 
> <scope suppressJoinFailure="yes" >
>     <target linkName="l1" />
>     <source linkName="l2" tcond="t2()" />
>     <catchAll> ... </>
>     
>     <any-activity/>
> </scope> 
> 
> would have to be interpreted as:
> 
> <scope>
>   <catch faultName="bpws:suppressJoinFailure"> <empty/> </>
> 
>   <scope>
>     <target linkName="l1" />
>     <source linkName="l2" tcond="t2()" />
>     <catchAll> ... </>
> 
>     <any-activity/>
>   </scope> 
> </scope>
> 
> -maciej.
> 
> On Wed, 2004-10-06 at 15:39, rkhalaf wrote:
> 
>>You bring up an interesting point. I always assumed from the wording of 
>>the spec that the implicit scope doesn't touch the links.. ie, they stay 
>>on the wrapped invoke .
>>
>>The scope not touching the link is in-line with what happens for the 
>>implicit scopes that handle suppressJoinFault. In fact, the dpe 
>>semantics are based on that assumption.
> 
> 
>>The interesting bit comes when you read section 12.5.2 regarding the two 
>>together:
>>
>>"In case this is an invoke activity (see Invoking Web Service 
>>Operations) with an inlined fault or compensation handler, the implicit 
>>scope for the fault and compensation handlers is merged with the 
>>implicit scope described here, which adds an additional fault handler 
>>for the bpws:joinFailure. "
>>
>>So if the link *is* moved to the boundary then this breaks its 
>>suppressJoin handling, as the spec currently stands.
>>However, I agree with you that if the fault is handled (not by the 
>>suppress join handler) and the invoke's links go negative then this 
>>might come as a surprise to the process modeler. If we go the way of 
>>moving the links to the scope boundary then we need to modify the 
>>phrasing of the implicit scope merges definied in 12.5.2.
>>
>>Another interesting case:
>><invoke ...>
>>    <catch faultname="...:suppressJoinFailure">
>>    <sources><source linkName="blabla"/> </sources>
>>    <targets><target linkName="out1"/><target linkName="out2"/></targets>
>></invoke>
>>
>>vs.
>><invoke suppressJoinFailure="yes"> ...</invoke>
>>
>>I don't think the first one is allowed! Again my understanding is that 
>>you can only add catches that are WSDL faults on the operation you are 
>>trying to invoke - but I think the spec's wording is a bit loose on 
>>that(section 11.3) and making that restriction clear would be helpful.
>>
> 
>

119.ppt