OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-bpel] Issue - 119 - Transition Conditions and Invoke FaultHandlers


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.
> 
> 

This is a digitally signed message part



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]