Issue 139.1 - Proposal For Vote

["Yaron Y. Goland" <ygoland@bea.com>]

Issue 139.1: How/when BPEL can change partner role EPR

NOTE: This proposal has a dependency on 96.1

Proposal: Put in a switch which specifies if the BPEL engine is required 
to use a binding that can set the EPR on partnerRole when receiving a 
message.

Rationale: As discussed in the group we know there will be situations 
where some bindings (e.g. WS-Addressing) can set partnerRole EPR 
information and BPEL programmers will depend on that ability. In other 
cases bindings (such as XML over HTTP) don't support setting partnerRole 
EPR information and programmers will rely on the fact that their EPRs 
won't be changed from underneath them. This proposal gives programmers a 
way to make their expectations explicit without having to say anything 
about which bindings are used. In other words this proposal specifies an 
aspect that a binding used with the BPEL must have but doesn't specify 
how that aspect is achieved.

Section 7.2

Change the BNF to read:

<partnerLinks>
      <partnerLink name="ncname" partnerLinkType="qname"
           myRole="ncname"? partnerRole="ncname"? partnerRoleSet=anyURI?>+
      </partnerLink>
</partnerLinks>

From: In the degenerate case where a partnerLinkType has only one role, 
one of these attributes is omitted as appropriate.

To: In the case where a WSDL binding is only specified for one of the 
two roles then one of these attributes is omitted as appropriate.

Insert the following as a new paragraph after the paragraph that ends 
with " See Assignment for the mechanisms used for dynamic assignment of 
endpoint references to partner services."

Some bindings provide EPR information about the sender of a message. 
When receiving a message the BPEL processor could potentially use this 
EPR information to set the EPR value in the partnerRole of a 
partnerLink. However if the author of the BPEL process was not expecting 
such a binding to be used then they could be surprised to find that an 
EPR they have set on a partnerRole has been changed from under them as a 
consequence of receiving a message. To prevent such surprises the 
partnerRoleSet attribute is introduced. The value of the partnerRoleSet 
attribute is a URI. Two URIs are defined as part of this specification, 
http://schemas.xmlsoap.org/ws/2004/03/business-process/partnerLink/mustSet 
and 
http://schemas.xmlsoap.org/ws/2004/03/business-process/partnerLink/mustNotSet. 
If the partnerRoleSet attribute is not specified then its value MUST be 
treated as 
http://schemas.xmlsoap.org/ws/2004/03/business-process/partnerLink/mustNotSet. 


partnerRoleSet can be extended by defining new URIs for use with it. If 
a BPEL processor encounters a URI value for partnerRoleSet that it does 
not support then the BPEL processor MUST reject the BPEL process, the 
previous requirement MUST be statically enforced.

The semantics of the 
http://schemas.xmlsoap.org/ws/2004/03/business-process/partnerLink/mustSet 
URI is that the binding used to receive messages on the specified 
partnerLink MUST be able to retrieve the EPR of the sender of the 
message and MUST use that EPR to set the value of partnerRole on the 
partnerLink.

The semantics of the mustNotSet URI is that the binding used to receive 
messages on the specified partnerLink MUST NOT be used to set the EPR on 
the partnerLink's partnerRole even if such EPR information is available.