Issue - 301 - Uninitialized Partner Links

[ws-bpel issues list editor <peter.furniss@erebor.co.uk>]

This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if a motion to open the issue is proposed and that motion is approved by the TC. A motion could also be proposed to close it without further consideration. Otherwise it will remain as "received".

The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 301 - Uninitialized Partner Links

Status: received
Date added: 15 Jun 2006
Date submitted: 12 June 2006
Submitter: Monica J. Martin
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.
Changes: 15 Jun 2006 - new issue

---

To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 301 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - 301 - Proposed resolution", without any Re: or similar.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).