Issue 139 - Proposal For Vote

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

Here is the new text for 139 based on the discussions held today in the 
F2F. Please note that this HTML file can be loaded in Word which will 
recognize it as a Word file and allow you to do things like remove 
change marking.

	Thanks,

		Yaron

Title: Issue 139 - PartnerLink Semantics

Issue 139 - PartnerLink Semantics

 

Proposal:

Change to section 6.3:

 

From: Extensions MUST NOT change the semantics of any element or attribute from the WS-BPEL namespace.

 

To: Extensions MUST NOT contradict the semantics of any element or attribute defined by the WS-BPEL specification. Extensions that affect the semantics of WS-BPEL processes MUST appear in the BPEL process definition or its directly referenced WSDL portTypes, property alias definitions or property definitions.

 

Change to section 7.2:

 

Add after the end of the following sentence: "See Assignment for the mechanisms used for dynamic assignment of endpoint references to partner services."

 

Once an assign activity has been used to change the value of the EPR in a partnerRole the partnerRole's value MUST NOT be altered via any mechanism but another assign activity. Note however that an extension MAY override the previous rule.

 

Change the following text in section 11.4:

 

From: A receive activity specifies the partner link it expects to receive from, and the port type (optional) and operation that it expects the partner to invoke.

 

To: A receive activity specifies the partner link that contains the myRole used to receive messages, the port type (optional) and operation that it expects the partner to invoke. Note that tThe 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. Also note, that the value of the partnerRole EPR MAY be initialized or updated when a message is received if the underlying binding is able to transport EPR information about the partner.

 

Change the following text in section 13.5.1:

 

From: The partnerLink attribute defines the partner link on which the request is expected to arrive; the partnerLink must be defined in the partnerLinks section.

 

To: The partnerLink attribute defines the partner link that contains the myRole EPR on which the request is expected to arrive; the <partnerLink> must be defined in the <partnerLinks> section.  As with <receive> the partnerRole EPR is ignored for purposes of determining which messages to receiveexecuting the receive semantics of an event handler 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.

 

Rationale: An unanswered question in the BPEL specification is what part, if any, do partnerLink roles play in message filtering/correlation? Specifically:

 

1. If a <receive> is executed on a partnerLink with an initialized partnerRole value is there a requirement that incoming messages accepted by that receive MUST/SHOULD/MAY be sent by the endpoint identified by the partnerRole EPR?

 

1. If a message arrives on a <receive> and the message (through an undefined mechanism) contains an EPR for the partner MUST/SHOULD/MAY the partnerRole on the partnerLink be set to that EPR?

 

1. When sending a <reply> on a partnerLink with an initialized partnerRole EPR MUST/SHOULD/MAY the reply message be required to be sent to the endpoint identified by the partnerRole EPR?

 

1. When using <invoke> on a partnerLink with an initialized myRole EPR MUST/SHOULD/MAY the response to the request be required to be sent to the myRole EPR?

 

Without a consistent answer to question #1 it will be impossible to write portable BPEL code. After all, some implementations may pay attention to the partnerRole as a filter for receiving incoming messages and others may not and the result will be chaos. I believe the only reasonably portable answer to question 1 is – partnerRole is ignored on <receive>/<pick>/<onEvent>. Implementations are free to override that with a mandatory extension where it makes sense but as a default, portable behavior, I think ‘ignore’ is as good as it will get.

 

#2 however is a very different issue. Imagine you are using WS-Addressing or some other protocol that provides EPR data. In that case you would expect that when you receive a message on that partnerLink then the partnerRole EPR will be initialized and you will be able to send messages in return. In that case you wouldn’t bother manually setting EPRs. On the other hand if your program is switched to something like XML over HTTP where there is no WS-Addressing and thus no automatic EPR setting support then suddenly your program’s key assumption falls apart and your code will fail as soon as it tries to use what it thought was an initialized partnerLink.

If, your program was originally written with XML over HTTP in mind then you would do your own EPR management. But imagine that your BPEL is rebound to a transport using WS-Addressing, in that case you would set the EPR on a partnerRole (from data you got in an application message that is part of your protocol design and has nothing to do with WS-Addressing), send a message and then receive a message from the partner only to find that the EPR on the partnerRole may have been changed as a consequence of receiving the message! On the other hand the EPR would only be changed because the underlying transport said “I have a more up to date EPR”. So shouldn’t the change have happened? The only place things can really explode is if at some later point the BPEL process really needs to send a message to the original (now altered) EPR, which the code thinks is still in the partnerLink, and instead ends up sending a message to the new EPR. But this sounds to me like a flaw in the underlying binding layer. If a binding allows an existing EPR to be overwritten it better know what the heck it’s doing.

So the only problem case would be if a BPEL that was designed to assume it was running on something like WS-Addressing was switched to something like XML over HTTP. In that case the program’s key assumption, that the EPR of a partner will be sent any time a message from that partner is received, will prove to be false and the program will fail when it tries to send a message on what will turn out to be an un-initialized partnerLink.

            My best guess is that a process will have deployment information that declares if the process requires a transport that can set EPRs. I suppose we could stick in some kind of flag but I’m not 100% convinced it’s necessary. To me the key difference between Q1 and Q2 is that in Q1 the chaos results from a characteristic of how the BPEL engine works – does it accept messages by filtering on the partnerRole? That is something under the control of the BPEL engine and therefore something we need to specify in the standard. But in Q2 the behavior is out of control of the BPEL engine itself, it is a consequence of the underlying binding. That’s something that I think we can safely stay away from.

            Therefore my best guess is that we should just make it clear in the spec that receiving a message can cause a partnerRole to be initialized/updated and leave it at that.

 

Questions 3 & 4 on the other hand I think we can let slide. BPEL explicitly forbids users from setting myRole EPR values. So when a myRole is initialized or how it is used is completely out of the hands of the programmer, so there doesn’t appear to be a portability issue.