OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue 139 - Proposal For Vote


Issue 139 - PartnerLink Semantics

Proposal: 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 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. 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 
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.

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?

2.	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?

3.	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?

4.	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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]