[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
When you start needing to introduce double nested scopes to make the semantics work perhaps that's a warning that the semantics are too complex? Can we not simplify things by just removing the in-line fault handlers? Yaron P.S. Of course, I kinda like the in line fault handlers. Maybe we can simplify things by removing links? :) 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. > >> > > > > > > > ------------------------------------------------------------------------ > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]