Re: RPC Style Issues (3)

"Umit Yalcinalp" <umit.yalcinalp@oracle.com> writes:
> No. Our current rules force one to accept the first out param as the 
> return value. That is not acceptable because there are two signatures to 
> support. Void return can not be supported with the current rule.

Sure- the language binding can choose to move the return value to
an out parameter and you have a void return signature.

> This is not a language binding issue. It is impossible to have two 
> different signatures. Tom's example is simple and clear. We need to be 
> able to recognize both cases as separate signatures. With the current 
> rules, there is only one mapping. Mapping to a void return value is not 
> possible. Period.

It is - its a language binding choice. If you want to map to a stored
procedure with a void return you can. If you want to map it to a UDF
with a non-void return you can. Yes, the language binding needs to
make a decision on which way to go. We do similar things in our database
products too.

> Oracle needs this to support our bindings for data base web services, 
> for our products. We need to be able to distinguish between void return 
> and return value designated by an output parameter. This is a 
> requirement for us. Please note that SOAP RPC design accomodated a 
> similar approach (namely designating a return value independent of the 
> message content). So this issue is not inherent only in our products, it 
> was required by SOAP RPC rules. Not supporting SOAP is one decision, but 
> not supporting indicating a return value is going too far.

(Who said we're not supporting SOAP??)

Did WSDL 1.1 support distinguishing between these two signatures?
IIRC SOAP v1.1 RPC rules did not support "designating a return value
independent of the message content" either.

(I'm not saying that's a reason not to do - just wondering how you
lived with it until now.)

Sanjiva.

Received on Tuesday, 28 October 2003 13:29:10 UTC