[ebBP] 11/23/2004: WSDL Overloading References (as promised)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

In last week's call, I indicated I would provide some details when we 
spoke about WSDL overloading. Here is a brief segment about a related 
discussion in WS-BPEL TC re: supporting WSDL v1.1 overloading. There was 
some indication from the TC that they would not allow overloading and 
site the WS-I BP v1.1 as rationale. However, no formal decision has been 
made.


    =============================================================


    Issue - 175 - Supporting WSDL Overloading in BPEL

***.....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).