Re: [wsbpel] Issue - 301 - Uninitialized Partner Links

["Monica J. Martin" <Monica.Martin@Sun.COM>]

From Ron and Monica:

On issue 301, Ron and I had an offline discussion with a few other TC 
members (in hopes of answering any questions Dieter may have). Here is a 
restatement of the issue we have raised which poses two related questions:

   1. Unused partnerLinks: Are they allowed?
   2. Assuming the answer to (1) is "yes": What kind of fault should
      assignment from an uninitialized partnerLink cause?

We believe that the specification implicitly allows (1). This has caused 
some confusion with reviewers of the specification within Sun, since 
there is no explicit statement to this effect.

Assuming that (1) is true (we saw one use case where that could be 
true), a further issue was identified. There is no statement in the 
specification what sort of fault should be thrown if an uninitialized 
partnerLink is used as the source (<from>) in an assignment operation. 
Partner links are distinct from variables (so bpel:uninitializedVariable 
isn't applicable), and this involves the whole partnerLink, not one role 
within it (thus bpel:uninitializedPartnerRole doesn't apply).

In point of fact, the lack of any language addressing the second 
question caused some reviewers to question the assumption contained in 
the first. Surely the lack of a defined fault in (2) implies that 
partnerLinks MUST always be uninitialized?

Therefore, by resolving (2), we should make (1) appear to hold 
consistently throughout the specification. We can consider some type of 
fault to handle (2), permit (1) to be allowed implicitly, and ensure 
consistency with (1) because of (2).

Thanks.

>> ....Issue - 301 - Uninitialized Partner Links
>> *Status:* received
>> *Date added:* 15 Jun 2006
>> *Date submitted:* 12 June 2006
>> *Submitter:* Monica J. Martin <mailto:Monica.Martin@Sun.COM>
>> *Description:* Background: Questions were raised if it is valid to 
>> have partnerLinks declared in a BPEL process which are not referenced 
>> by any messaging activity (receive, invoke, onMessage, onEvent, etc) 
>> whereby they are declared but not referenced. If they are to be used, 
>> they need to be initialized to be used (and of course referenced in a 
>> message activity). The specification talks about in Section 6.2 that 
>> partner links can be dynamically bound outside of the process as 
>> well. If the partner role is uninitialized a fault will occur (see 
>> Section 10.3):
>>
>>    If an <invoke> activity is used on a partnerLink whose partnerRole 
>> EPR is
>>    not initialized then a bpel:uninitializedPartnerRole fault MUST be 
>> thrown."
>> In reviewing this question, we uncovered a potential gap when copying 
>> one partner link to another in an assign where a partnerLink role is 
>> unitialized.
>>
>> Example:
>>
>> <?xml version="1.0" encoding="utf-8" ?>
>> <process name="fhMatchingCatches1"
>>        
>> targetNamespace="http://www.seebeyond.com/eInsight/MatchingCatches1";
>>        
>> xmlns:tns="http://www.seebeyond.com/eInsight/MatchingCatches1";   
>>        
>> xmlns:bpel="http://schemas.xmlsoap.org/ws/2004/03/business-process/";  
>>        xmlns:ns0="http://stc.com/FaultTest/MatchingCatches1";
>>        xmlns="http://schemas.xmlsoap.org/ws/2004/03/business-process/";>
>>   <import namespace="http://stc.com/FaultTest/MatchingCatches1";
>>        location="MatchingCatches1.wsdl"
>>        importType="http://schemas.xmlsoap.org/wsdl/";></import>
>>   <partnerLinks>
>>       <partnerLink name="faulttestLink" partnerLinkType="ns0:SLT" 
>> myRole="server"/>
>>       <partnerLink name="unusedPartnerLink1" 
>> partnerLinkType="ns0:PLT2" myRole="role1"/>       <!-notice that 
>> these are not used in the business process -->                   
>> <partnerLink name="unusedPartnerLink2" partnerLinkType="ns0:PLT3" 
>> partnerRole="role2"/>
>>   </partnerLinks>
>>    <variables>
>>       <variable name="MatchingCatches1_Output" 
>> messageType="ns0:FaultTest"></variable>
>>       <variable name="MatchingCatches1_Input" 
>> messageType="ns0:FaultTest"></variable>
>>    </variables>     <sequence>
>>      <receive name="MatchingCatches1" partnerLink="faulttestLink" 
>>             portType="ns0:FaultTest" 
>> operation="MatchingCatches1"                        
>> variable="MatchingCatches1_Output" createInstance="yes"/>
>>      <assign name="Assign">
>>           <copy>
>>               <from>'Scenario Passes Thru'</from>
>>               <to>$MatchingCatches1_Input.part/retString</to>
>>           </copy>
>>      </assign>
>>       <reply name="Reply"
>>       partnerLink="faulttestLink" portType="ns0:FaultTest"
>>           operation="MatchingCatches1"
>>           variable="MatchingCatches1_Input"/>
>>   </sequence>                       Use cases: One use case was 
>> identified that may explain why this was allowed (if only 
>> indirectly): A partner link (not used by any messaging activity) can 
>> be used as the source for an endpoint reference. A set of unused 
>> partner links, and some BPEL logic to choose one of them to be 
>> assigned to a partner link that is actually used. The unused partner 
>> links would be bound to concrete addresses during deployment.
>>
>> <process>
>>  partnerLink alpha
>>  partnerLink beta
>>  partnerLink gamma
>>  sequence    ...
>>    if some-condition
>>      assign from beta to alpha
>>    else
>>      assign from gamma to alpha
>>    invoke operation bar on alpha ...
>> </process>
>>
>> However, the example and use case uncover the potential gap. 
>> UninitializedVariable and UnitializedPartnerRole faults exist but 
>> neither really applies to copying one partner link to another in an 
>> assign. What if we execute: assign from beta to alpha
>>
>> And, beta (for the selected EPR) is not initialized? The 
>> UninitializedVariable fault still works, but Variables are 
>> distinction from PartnerLinks in BPEL. This is a problem that exists 
>> and should be addressed regardless of the declaration and referencing 
>> question that prompted this discovery.
>>
>> Question: In Section 12, we discuss partner links in several 
>> contexts, such as for example, that any partner links defined in the 
>> <scope> must be set before variables defined in the same <scope> 
>> whose initialization logic refers to those partner links. However, 
>> unless identified, I don't see any restrictions for a partner link to 
>> be declared but remain unused, nor any restrictions on assignment.
>> *Submitter's Proposal:* (conceptual) Suggest we consider two explicit 
>> restrictions that specify that it is invalid: 1) to have partnerLinks 
>> declared in an executable BPEL process which are not referenced by 
>> any messaging activity (receive, invoke, onMessage, onEvent, etc). If 
>> they are to be used, they need to be initialized to be used. 2) for 
>> an assignment from an uninitialized partnerLink role. It causes an 
>> UninitializedVariable fault.
>