Issue - R13 - BPEL partner link assignments

This issue has been added to the wsbpel issue list with a status of "received".
The status will be changed to "open" if a motion to open the issue is proposed and that
motion is approved by the TC. A motion could also be proposed to close it without
further consideration. Otherwise it will remain as "received".

The issues list is posted as a Technical Committee document to the 
OASIS WSBPEL TC pages
on a regular basis. The current edition, as a TC document, is the most recent version of 
the document entitled  in the 
"Issues" folder of the WSBPEL TC document list
- the next posting as a TC document will include this issue.
The list editor's working copy, which will normally include an issue when it is announced, is available at 
this constant URL.

Issue - R13 - BPEL partner link assignments
Status: received

Date added: 20 Sep 2006

Origin: Public comment from Andi Abes

Date submitted: 20 September 2006

Description: I'm trying to understand the semantics of assignment to and from partner links in BPEL, and the spec left me with a few open questions.

For the purpose of discussion, I'm considering a simple "router" process (R). 
The one operation exposed by this process includes 2 parts:

an amount (xsd:int)

the EPR of the requesting process (process REQ)

This operation is one way.

Based on content in the incoming request, the router chooses a process (process B) to "forward" the request to. Process B is expected to invoke an agreed upon operation on Process REQ, using the EPR information in the message.

There are 2 possible implementations:

The router process assigns from the receiving partner link to a variable (or message part) which is then relayed to process B. Process B then performs its activities and assigns this value to the a partner link which it uses to invoke an operation on REQ.

REQ is responsible to assign from "myrole" on the partner link facing the router into the a message it eventually sends it.

Based on my reading of the 8/23 draft, both implementations are supported.

The questions for which I have no clear answer are:

Is implementation option a) supported ?

Assuming it is, the spec in silent on IMA activities affecting the partner link for the purpose of assign activities, and the lifetime of the partner link value.

My expectation would be that once an IMA activity has completed, assigning from the partner link would yield the reply-to EPR. 

Would this also require the partner link variants of the Assign activity to include a messageExchange attribute.

Assuming the above is valid, what would the schema type of the variable( or message part) into which the EPR is assigned be?  serf:service-reference  - in the case of message part, this would cause BPEL specific types to be "leaked" into the abstract WSDL.  wsa:endpoint-reference - this would bind the BPEL process to a specific addressing scheme.

In either case, it would be useful for the spec to be specific about this point (and an example would be great).

Section 6.3 ("Endpoint References")states:

The <sref:service-ref> element is not always exposed to WS-BPEL process definitions. For example, it is not exposed in an assignment from the endpoint reference of myRole of partnerLink-A to that of partnerRole of partnerLink-B. On the contrary, it is exposed in an 
wsbpel-specification-assignment from a messageType or element based variable through expression or from a literal <sref:service-ref>.

Section 8.4.3 states that the following is not a valid assignment: the selection result of the from-spec is a variable of a WSDL message type and that of the to-spec is not, or vice versa (parts of variables, selections of variable parts, or endpoint references cannot be assigned to/from variables of WSDL message types directly).

It is not clear if these to sections are contradicting.

If assignments to/from partner links is allowed (which is explicitly stated in section 8.4), what are the valid combinations? 

Changes: 20 Sep 2006 - new issue

To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the 
 list (replying to this message should automatically send your message to that list), or ensure
the subject line as you send it starts "Issue - R13 - [anything]" or is a reply
to such a message. If you want to formally propose a resolution to an open issue, please start the subject line 
"Issue - R13 - Proposed resolution", without any Re: or similar.

To add a new issue, 
see the issues procedures document