Improper behavior for RPC call with no return value

["William A. Nagy" <na...@watson.ibm.com>]

Hi,

I was attempting to access a service, via SOAP-RPC, that has no return
value, but instead uses "output" parameters.  I have my own provider,
which creates the response in the following manner:

Response resp = new Response(targetObjectURI, methodName,     
			     (Parameter)null, returnparams,   
		    	     null, respEncStyle, respContext);

Notice the null where the return value parameter usually sits.  When
the client unmarshalls the response, the first parameter from
returnparams is used as the return value (fetchable via
Response.getReturnValue()) while the remaining ones can be retrieved
by Response.getParams().  This is clearly incorrect behavior, but the
real question is what is the correct way to fix it?

In its usual ambiguous fashion, the SOAP spec, section 7.1 says:

The method response is viewed as a single struct containing an
accessor for the return value and each [out] or [in/out]
parameter. The first accessor is the return value followed by the
parameters in the same order as in the method signature.

This leads me to believe that a return "value" should always be
present within the response message.  So what should happen?

1) Should the Response constructor simply not allow for a null value
   for the return value parameter? (Thus forcing the user to create a
   parameter with a null value to mimic the same behavior.)

2) Should the SOAP implementation automagically replace the null with
   a Parameter of type Object, which has a null value?

3) Should some delineator be added to distinguish the return value
   from the rest of the parameters, so that if a null was passed into
   the Response constructor on the server side, that a call to
   Response.getReturnValue() on the client side would also return
   null?

I'm not particularly fond of 2 (nor 1 since it forces the user to come
up with a solution like 2,) because there is a difference between
getting back a typed parameter with a null value, i.e. (Object)null,
and not getting back a return value at all.  But I'm also afraid that
3 would create interoperability problems.

Comments?

-Bill

Re: Improper behavior for RPC call with no return value

[Scott Nichol <sn...@computer.org>]

I don't find the section you quote from the SOAP spec to be ambiguous at
all.  My read is that it places the restriction that you cannot have [out]
or [in/out] parameters without having a return value.  It's an unnecessary
restriction, but I believe the spec is clear.  FWIW, my experience with
Microsoft's SOAP Toolkit has been that it behaves similar to the Apache SOAP
client in its handling of the first value in the response as the return
value.

Scott Nichol

----- Original Message -----
From: "William A. Nagy" <na...@watson.ibm.com>
To: <so...@xml.apache.org>
Sent: Thursday, May 10, 2001 2:14 PM
Subject: Improper behavior for RPC call with no return value


> Hi,
>
> I was attempting to access a service, via SOAP-RPC, that has no return
> value, but instead uses "output" parameters.  I have my own provider,
> which creates the response in the following manner:
>
> Response resp = new Response(targetObjectURI, methodName,
>      (Parameter)null, returnparams,
>          null, respEncStyle, respContext);
>
> Notice the null where the return value parameter usually sits.  When
> the client unmarshalls the response, the first parameter from
> returnparams is used as the return value (fetchable via
> Response.getReturnValue()) while the remaining ones can be retrieved
> by Response.getParams().  This is clearly incorrect behavior, but the
> real question is what is the correct way to fix it?
>
> In its usual ambiguous fashion, the SOAP spec, section 7.1 says:
>
> The method response is viewed as a single struct containing an
> accessor for the return value and each [out] or [in/out]
> parameter. The first accessor is the return value followed by the
> parameters in the same order as in the method signature.
>
> This leads me to believe that a return "value" should always be
> present within the response message.  So what should happen?
>
> 1) Should the Response constructor simply not allow for a null value
>    for the return value parameter? (Thus forcing the user to create a
>    parameter with a null value to mimic the same behavior.)
>
> 2) Should the SOAP implementation automagically replace the null with
>    a Parameter of type Object, which has a null value?
>
> 3) Should some delineator be added to distinguish the return value
>    from the rest of the parameters, so that if a null was passed into
>    the Response constructor on the server side, that a call to
>    Response.getReturnValue() on the client side would also return
>    null?
>
> I'm not particularly fond of 2 (nor 1 since it forces the user to come
> up with a solution like 2,) because there is a difference between
> getting back a typed parameter with a null value, i.e. (Object)null,
> and not getting back a return value at all.  But I'm also afraid that
> 3 would create interoperability problems.
>
> Comments?
>
> -Bill
>