[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] RE: [ws-bpel] Issue - 119 - Transition Conditions andInvoke Fault Handlers
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. >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]