RE: RPC Style Issues (3)

Sanjiva,

Since the whole RPC thing is a hint, can't we make the hint more useful to
the languages (C/C++/Java etc.) that will need to decide if it's a return
value or an output parameter?  If your WSDL2XXX doesn't need to know, it can
just ignore the attribute.

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
Sent: Tuesday, October 28, 2003 9:32 AM
To: Umit Yalcinalp; Tom Jordahl
Cc: 'Jacek Kopecky'; 'WS Description List'
Subject: Re: RPC Style Issues (3)

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

> (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.

> 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?

Sanjiva.

Received on Tuesday, 28 October 2003 10:33:51 UTC