Issue 96.1 - Proposal For Vote

Issue 96.1 - filterOnPartnerRole

Proposal: Add for use on receive/pick/onEvent the 'filterOnPartnerRole' 
attribute. This specifies that any message accepted by the 
receive/pick/onEvent activity must be sent from the partner identified 
by the EPR in the partnerRole. This proposal assumes that issue 194 is 
accepted and resolved by introducing a new uninitializedPartner fault. 
This proposal also introduces a canNotFilterOnPartnerRole fault for EPRs 
that are only useful in sending but not receiving.

Rationale: One of the most common BPEL scenarios out there is that 
someone receives a message from a partner and then later on wants to 
receive another message but only from that specific partner. The issue 
139 proposal defines that the default behavior for BPEL will be that the 
partnerRole value is ignored by default on receive/pick/onEvent. This 
attribute would allow that default behavior to be overridden and for the 
partnerRole EPR to be used as a filter on incoming messages.

Section 11.4

From: Note that the value of the partnerRole on the partner link is not 
used when processing a receive activity, that is, there is no filtering 
of incoming messages based on the partnerRole’s value.

To: The value of the filterOnPartnerRole attribute determines what role, 
if any, the value of the partnerRole EPR plays in a receive. If 
filterOnPartnerRole="no" then the partnerRole EPR value is ignored in 
determining what messages to receive. If filterOnPartnerRole="yes" then 
messages accepted by the receive MUST originate from the a partner whose 
EPR matches the EPR in the partnerRole. BPEL engines MUST statically 
check if the EPR in a partnerRole cannot be used to filter incoming 
messages and reject any BPELs that use filterOnPartnerRole="yes" with 
such unsuitable EPRs. However it is not always possible to statically 
check for this error as partnerRole values can be dynamically assigned. 
In that case if a partnerRole EPR, at runtime, contains a value that 
cannot be used to filter incoming messages then the 
canNotFilterOnPartnerRole fault MUST be thrown.

Section 13.5.1.

From: As with <receive> the  partnerRole EPR is ignored for purposes of 
determining which messages to receive and may be initialized/updated as 
a consequence of receiving a message using a binding that is able to 
provide EPR information about the partner.

To: As with <receive> the partnerRole EPR is only used for filtering 
incoming messages if the filterOnPartnerRole attribute is set to yes. 
Also, the partnerRole value may be initialized/updated as a consequence 
of receiving a message using a binding that is able to provide EPR 
information about the partner.

Add to Appendix A:

canNotFilterOnPartnerRole  - Thrown when a receive/pick/onEvent 
specifies filterOnPartnerRole but the EPR in the partnerRole value 
cannot be used to filter incoming messages.

Change BNFS in 11.4 and 6.2 to:
From:
<receive partnerLink="ncname" portType="qname"? operation="ncname"
	variable="ncname"? createInstance="yes|no"?
         messageExchange="ncname"? filterOnPartnerRole="yes|no"?
	standard-attributes>
       standard-elements
       <correlations>?
	<correlation set="ncname" initiate="yes|no"?/>+
       </correlations>
</receive>

Section 12.4 and 6.2:
<pick createInstance="yes|no"? standard-attributes>
       standard-elements
    <onMessage partnerLink="ncname" portType="qname"?
	operation="ncname" variable="ncname"?
         messageExchange="ncname"? filterOnPartnerRole="yes|no">+
      <correlations>?
	<correlation set="ncname" initiate="yes|no"?/>+
      </correlations>
      activity
    </onMessage>
    <onAlarm>*
	  ( <for expressionLanguage="anyURI"?>duration-expr</for> |
	    <until expressionLanguage="anyURI"?>deadline-expr</until> )?
	    <repeatEvery expressionLanguage="anyURI"?>duration-expr</repeatEvery>?
       activity
    </onAlarm>
</pick>

Section 13.5 and 6.2:
<eventHandlers>?
        <!-- there must be at least one onEvent or onAlarm handler -->
	<onEvent partnerLink="ncname" portType="qname"?
	     operation="ncname"  messageType="qname"
	     variable="ncname"
              (messageType="qname" | element="qname")?
              messageExchange="ncname"? filterOnPartnerRole="yes|no">*
	    <correlations>?
		<correlation set="ncname" initiate="yes|no"/>+
	    </correlations>
	    activity
	</onEvent>
	<onAlarm>*
	  ( <for expressionLanguage="anyURI"?>duration-expr</for> |
	    <until expressionLanguage="anyURI"?>deadline-expr</until> )?
	    <repeatEvery expressionLanguage="anyURI"?>duration-expr</repeatEvery>?
	     activity
	</onAlarm>
</eventHandlers>