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

["Yaron Y. Goland" <ygoland@bea.com>]

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.