Issue - 175 - Supporting WSDL Overloading in BPEL

[ws-bpel issues list editor<peter.furniss@choreology.com>]

This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if the TC accepts it as identifying a bug in the spec or decides it should be accepted specially. Otherwise it will be closed without further consideration (but will be marked as "Revisitable")

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 - 175 - Supporting WSDL Overloading in BPEL

Status: received
Date added: 27 Oct 2004
Categories: Syntax and validation
Date submitted: 26 October 2004
Submitter: Yaron Y. Goland
Description: WSDL 1.1 explicitly supports operation overloading (section 2.5) 
although WS-I BP 1.1 eventually banned it (R2304). But since BPEL 
doesn't restrict itself to just WS-I (Issue 72) we still have to deal 
with overloading.

The problem is that when executing a message operation like a receive just specifying the partnerLink, portType and operation is not enough to uniquely identify which operation is intended in an overloaded portType. Strictly speaking one also needs to specify both the name of the input and (if present) the output elements in order to uniquely identify an overloaded operation.

There are a number of consequences to this ambiguity:

Receive/Pick & Reply - It is impossible to know which overloaded operation one is waiting for.

Even using the variable type as a tie breaker isn't guaranteed to work since it is legal to have two input elements in two overloaded operations with different names but identical types. In the case of a one-way we might just fudge things and say that the receive/pick is able to wait for two or more operations using the same variable type simultaneously but in the case of request/reply we can be in big trouble since there is no way to statically know if the reply is correct. E.g. if two operations have the same name and same inputs but different outputs.

Just to make things even more fun one could have two identically named operations whose input and output elements have different names but identical types. In that case the BPEL variable typing will work but there is no way for the WSDL binding to know which of the overloaded operations was intended since BPEL doesn't communicate the input/output element names as part of the BPEL messaging operation.

Invoke - Same issues in reverse.
Submitter's proposal: I can see two ways to solve this issue. The one I prefer is that we just declare in the spec that BPEL doesn't support overloaded WSDLs and call it a day.

But another choice is to extend our messaging operations to optionally allow for the specification of the input/output element names (we would need both in the case of request/response operations).
Changes: 27 Oct 2004 - new issue

---

To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 175 - [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 - 175 - Proposed resolution", without any Re: or similar.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).

Choreology Anti virus scan completed