Re: RPC Style Issues (3)

Sanjiva,

Sanjiva Weerawarana wrote:

>"Umit Yalcinalp" <umit.yalcinalp@oracle.com> writes:
>  
>
>>>I think this is the key on this issue.  Do we care if an RPC style WSDL
>>>      
>>>
>can come out with two different signature?
>  
>
>>> void f([out] int x)
>>> int f()
>>>
>>>      
>>>
>
>That's a design choice in languages that support out parameters
>and hence the person defining the language binding for such
>languages need to make the choice.
>
>+1 to Jack's comments.
>
>  
>
>>(1) Being able to designate a void return as well as designating an
>>output parameter as the return value (your example).
>>    
>>
>
>I think this is going too far - its one thing to support RPC
>signatures but its another to support all possible combinations
>in all languages.
>
>We can support a way to indicate a return value. There can be out
>parameters. If a language binding wishes to make the return
>value an out parameter that's its business. Think Pascal vs. C
>vs. C++ vs. Java - there are different "right" answers. (I don't
>know enough about C#'s rules.)
>
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.

>
>  
>
>>(2) Allowing SOAP rpc return value convention to coexist in the RPC style.
>>    
>>
>
>Definitely -1 for this. We cannot make the abstract RPC style rules
>SOAP specific. SOAP, IMO, has gone way overboard in allowing
>dynamic indication of the "return value" concept. There's no way
>I'm going to support that for WSDL abstract RPC signatures.
>
>  
>
>>The WG can make an explicit decision not to allow (2). Lets not mix the
>>two.
>>
>>I would like to solve problem (1). We should decide whether (2) is
>>acceptable or not, but (1) must be solved and yield two different
>>signatures. This is NOT a 80/20 problem. From our perspective, they both
>>exist and *are* different.
>>    
>>
>
>Language binding can make that decision - its not up to us.
>


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.

>
>  
>
>>I propose another approach to solve (1) which was mentioned but not
>>clearly spelled out in my message starting this thread.
>>
>>-- Define an attribute "result" in the rpc namespace. Its value is a
>>    
>>
>QName.
>  
>
>>-- Use the attribute in the output element to designate the return value
>>in the output message (body) itself.
>>
>><interface name="whatever" ...>
>>     <operation name="foo" pattern="..."
>>style="http://www.w3.org/@@@@/@@/wsdl/style/rpc" >
>>        <input.../>
>>        <output messageReference="..."
>>                     body="..."
>>                     rpc:result="tns:myValue"/>
>></interface>
>>
>>-- If the attribute does not exist, then there is no return value. You
>>infer that it is void.
>>-- It is an error to have this attribute in the output element when the
>>style is not rpc.
>>
>>Basically, it is functionally equivalent to defining the result without
>>using the SOAP convention inside the message. Further, the message is
>>not changed. Instead it is defined in WSDL, but allows one to infer two
>>distinct signatures as needed.
>>    
>>
>
>As needed by what requirement?
>

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.


>
>Sanjiva.
>
>
>
>  
>
--umit

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com