Issue - 139.1 - Proposal For Vote

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

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

Proposal: Put in a switch to specify if the programmer is depending on 
the BPEL processor to initialize a partnerRole value on a partnerLink. 
Put in another switch which specifies if the binding used with the 
partnerLink must be able to set the partnerRole value when receiving a 
message.

Rationale: As discussed in the group we need to enable programmers to 
make their intentions clear so that they can be properly enforced. After 
discussing the matter it appears that there are two areas that need 
clarification in the spec.
	The first is - who is responsible for initializing a partnerRole? Today 
the programmer has no explicit way of stating that they expect the BPEL 
processor to handle initialization. Making it possible to state that 
clearly in the code will make deploying BPELs much easier.
	The second is - when is the BPEL processor allowed to overwrite a 
partnerRole value? Some bindings (WS-Addressing comes to mind) have the 
ability to carry updated EPR data. If a programmer doesn't know they 
have been bound to such a binding they would be very surprised to find 
out that their partnerRole value has been overwritten. We need a way to 
let the programmer explicitly define their expectations.

Section 7.2

Change the BNF to read:

<partnerLinks>
      <partnerLink name="ncname" partnerLinkType="qname"
           myRole="ncname"? partnerRole="ncname"?
           initializePartnerRole="yes|no"? partnerRoleSet="yes|no|may"?>+
      </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."

The initializePartnerRole attribute specifies if the BPEL processor is 
required to initialize a partnerLink's partnerRole value. The attribute 
has no affect on the partnerRole's value after its initialization. The 
initializePartnerRole attribute MUST NOT be used on a partnerLink that 
does not have a partner role; this restriction MUST be statically enforced.

If the initializePartnerRole attribute is set to "yes" then the BPEL 
processor MUST initialize the EPR for the specified 
partnerLink/partnerRole combination before that partnerRole is first 
referenced by the BPEL process. If initializePartnerRole is set to "yes" 
and for whatever reason the BPEL processor is unable to initialize the 
partnerRole then the bpws:cannotInitializePartnerRole fault MUST be thrown.

If the initializePartnerRole attribute is set to "no" then the BPEL 
processor MUST NOT initialize the EPR for the specified 
partnerLink/partnerRole combination before that partnerRole is first 
referenced by the BPEL process.

If the initializePartnerRole attribute is set to "may" then the BPEL 
processor MAY initialize the EPR for the specified 
partnerLink/partnerRole combination before that partnerRole is first 
referenced by the BPEL process.

If the initializePartnerRole attribute is omitted then its value MUST be 
treated as "may".

The partnerRoleSet attribute specifies if the binding used with the 
partnerLink is required to be able to provide the EPR for the sender and 
to then assign that EPR to the partnerLink's partnerRole. The 
partnerRoleSet attribute MUST NOT be used on a partnerLink that does not 
have a partner role; this restriction MUST be statically enforced.

If the partnerRoleSet attribute is set to "yes" then the binding used 
for the partnerRole MUST be able to retrieve the EPR of the sender of a 
message received on that partnerLink and MUST use that EPR to set the 
value of partnerRole on the partnerLink every time a message is received.

If the partnerRoleSet attribute is set to "no" then the binding used to 
receive messages on the specified partnerLink MUST NOT be used to set 
the EPR on the partnerLink's partnerRole when a message is received even 
if such EPR information is available.

If the partnerRoleSet attribute is omitted then its value MUST be 
treated as "no".

Even if partnerRoleSet="yes" it is still possible for a programmer to 
manually set the partnerRole value. However, if partnerRoleSet="yes", 
then the next time a message is received the partnerRole EPR will be 
overwritten by whatever EPR is specified in the received message.

Appendix A:

Add:

bpws:cannotInitializePartnerRole - Thrown when 
initializePartnerRole="yes" but for some reason the BPEL processor 
doesn't have an initialization value.