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

[Maciej Szefler <mbs@fivesight.com>]

Rania, 
Yes, very close, attached PDF shows what I was getting at using our
favorite notation. The location of the compensation handler is the only
difference. In my diagram, the comp. handler stays on the inner scope,
while you attach it to the outer scope. This really should not matter,
as the default compensation handler of the outer scope will compensate
the inner scope. We just have to make sure that it is the outer-most
scope that gets named after the <invoke> in case we want to use explicit
compensation.

-maciej
 
On Fri, 2004-10-08 at 12:02, rkhalaf wrote:
> 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.
> >>
> > 
> > 
>

issue119.pdf

This is a digitally signed message part