Issue 119 - Proposal For Vote

[Maciej Szefler <mbs@fivesight.com>]

This issue has been explained pretty well in the list. It relates to
implicit scopes (for invokes), links, suppressJoinFailure and the
interaction between these things. The current behavior is a bit
inconsistent. Please refer to the list archives for details. In the
proposal I make the following departures from the current spec:

1. Current spec states that the "implicit scope" for an <invoke> assumes
the name, comp handler and fault handlers of the <invoke>; proposal adds
that this "implicit <scope> activity" also assumes the links (sources,
targets, and join condition) as well as the value of the
suppressJoinFailure attribute of the <invoke>.

2. Current spec states that when join failure suppression is applied to
<invoke>s, that a fault handler for catching the bpws:joinFailure is
"merged" with the implicit scope of the <invoke> activty; the proposal
abandons this and instead states that a completely separate scope
dealing only with the suppressing the join failure fault is created to
enclose the "implicit <scope> activity" of the invoke.
3. Current spec is a bit unclear as to the behavior of when a <scope>
activity has the suppressJoinFailure set to "yes"; proposal specifies
that such scopes behave like all other activities: i.e., they bahave as
if they were wrapped by a new scope that has an empty faulthandler for
bpws:joinFailure. 

The effect of the above changes is to produce behavior that is a little
more cumbersome to specify but quite a bit more reasonable and
consistent with the rest of the specification (in particular the
resolution of issue 27). 

Here are the particulars:

11.3: Invoking Web Service Operations

CHANGE: Semantically, the specification of local fault and/or
compensation handlers is equivalent to the presence of an implicit scope
immediately enclosing the activity and providing those handlers. The
name of such an implicit scope is always the same as the name of the
activity it encloses. 

TO: Semantically, the specification of local fault and/or compensation
handlers is equivalent to the presence of an implicit <scope> activity
immediately enclosing the <invoke> activity providing those handlers.
The implicit <scope> activity assumes the name of the <invoke> activity
it encloses, its suppressJoinFailure attribute, its join condition, as
well as its link sources and targets. For example, the following:
<invoke name="purchase"
       suppressJoinFailure="yes" 
       partnerLink="Seller"
       portType="SP:Purchasing"
       operation="SyncPurchase"
       inputVariable="sendPO"
       outputVariable="getResponse">
      <targets>
          <target linkName="linkA"/>
      </targets>
      <sources>
          <source linkName="linkB">            
             <transitionCondition>
                   ...
             </transitionCondition>
           </source>
      </sources>
      <compensationHandler>
            <invoke partnerLink="Seller" portType="SP:Purchasing"
                   operation="CancelPurchase"
                   inputVariable="getResponse"
                   outputVariable="getConfirmation">
      </compensationHandler>
</invoke>

is equivalent to:

<scope name"purchase" 
      suppressJoinFailure="yes" >
     <targets>
         <target linkName="linkA"/>
     </targets>
     <sources>
         <source linkName="linkB">            
            <transitionCondition>
                 ...
            </transitionCondition>
          </source>
     </sources>
     <compensationHandler>
       <invoke partnerLink="Seller" portType="SP:Purchasing"
            operation="CancelPurchase"
           inputVariable="getResponse"
           outputVariable="getConfirmation">
     </compensationHandler>

     <invoke name="purchase"
            suppressJoinFailure="no"
            partnerLink="Seller" 
            portType="SP:Purchasing"
            operation="SyncPurchase"
            inputVariable="sendPO"
            outputVariable="getResponse"/>
</scope>


12.5.2: Dead-Path Elimination

CHANGE: ... Suppressing the bpws:joinFailure is equivalent to the fault
being logically caught by a special default handler attached to an
implicit scope that immediately encloses just the activity with the join
condition. ...

TO: ...<-Para-> Suppressing the bpws:joinFailure is equivalent to
surrounding each affected activity with a <scope> activity that defines
an "empty" fault handler for the bpws:joinFailure fault. For example,
the following:

<process suppressJoinFailure="yes" ..>
   <invoke name="invokeA" ... />
</process>

is equivelent to:

<process...>
   <scope name="invokeA"> 
       <faultHandlers>
           <catch faultName="bpws:joinFailure">
                <empty/>
            </catch>
       </faultHandlers>
       <invoke name="invokeA" ... />
   </scope>
</process>
 
CHANGE: Note that the name of the implicit scope (created to suppress
the bpws:joinFailure) that immediately encloses an activity with a join
condition is exactly the same as the name of the activity itself. 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.

TO: Note that the name of the scope created to suppress the
bpws:joinFailure fault that immediately encloses an activity with a join
condition is exactly the same as the name of the activity itself. In
case this is an invoke activity (see Invoking Web Service Operations)
with an inlined fault or compensation handler, join failure suppression
is applied to the implied scope of the <invoke> activity; i.e.
effectively two scopes are implied: an outer scope containing an empty
fault handler for the bpws:joinFailure fault and an inner scope
containing the links, fault handlers, and compensation handlers of the
original <invoke> activity. Identical rules apply to <scope> activities:
a <scope> with join failure suppression enabled implies an /additional/
surrounding scope. 


--maciej