Re: Proposal for cleanup of RPC section (issue 195)

Noah Mendelsohn/Cambridge/IBM wrote:

>An emphatic +1.  One of the very important things about SOAP RPC messages 
>is that they are to a significant degree self describing.  This is a great 
>importance for use of SOAP in dynamically typed languages, for which use 
>of WSDL is often inappropriate.  It's highly desirable, IMO, if I can 
>inspect a SOAP RPC message and tell by looking only at that message "this 
>is a call on a method named X with arguments named A1, A2, .. (or supplied 
>by position, which I can determine from the use of the array 
>construction).  I believe we have this today.
>
I completely agree that being able to examine a message and understand 
exactly what is required by the recipient is desirable. However,  

P2 S4.1

    Applications MAY process invocations with missing parameters
    but also MAY result in a fault

means that the message content may be missing so much information it is 
impossible to understand the requirements of the recipient. Also

P2 3.1.3 point 4.

    If a graph edge does not terminate in a graph node then it can 
either be
    omitted from the serialization or it can be encoded as an element 
information
    item with an xsi:nil attribute information item

I think both of these inclusions in 1.2 add unrequired complexity to 
SOAP processing (especially the first - but this has been debated 
before) and, as noted, make for the possibility of sending messages that 
cannot reliably be read by us humans to see the requirements of a service.

>
>Similarly, I think it is important to be able to understand and RPC 
>response without reference to WSDL.  I am concerned that proposal for void 
>returns does not have this self describing characteristic.
>
Not only for human readability but also to allow abstracting the soap 
processing at lower levels to be able to deduce information about what 
is the return value without any external knowledge of the call. For 
example, take the example of

    int doSomething( inout int value )

Then I use an API (such as the old Apache 2.x Call api) to make a call. 
The API is generic in the sense that you tell it everything to send

   Create request
   add argument Holder(value)
   invoke request

Assume the response object has methods such as

  Object getOutParam( int index )         // response as array
  Object getOutParam( String name )    // response as struct

If the response is modelled as an array then this is simply a case of 
the caller knowing whether there should be a return value and using the 
indexes 0 and 1 for the 2 values (knowing that 0 is the return value).

If the response is modelled as a struct then the caller can use 
getOutParam("value") to get the inout parameter, but how to get the 
return value in this case? There is no standard name (as per Jacek's 
proposal) so would the caller then also have to treat the response as if 
it were an array and use getOutParam(0)? This is not consistent with the 
response being a struct and mixes the array and struct views?

Jacek wrote:

> 3) add a note somewhere which says: "Note: many languages have
>    the notion of a return value - an unnamed [out] parameter. Such
>    can be dealt with by inventing a name like 'result' or using the
>    array serialization of RPC result. Also some languages have
>    [in/out] parameters which can be dealt with as couples of [in]
>    and [out] parameters in SOAP RPC. None of this affects
>    interoperability.



What if I am using a programming language such as Java and I want to 
model the exchange in a more java friendly manner. So now I have the methods

  Object getReturnValue()
  Object getOutParam( String name )    // response as struct

Now, I want to be able to know which return parameter is the return 
value. There needs to be a way to identify this without external 
information in this case (by name being the easiest way).

Also take the case where I have the combination

  Object getReturnValue()
  Object getOutParam( int i )

and I want to have the return value separate from the out params and the 
out params to be indexed from 0 (i.e. getOutParam(0) returns the value 
of 'value' - making the interface consistent whether there is a return 
value or not). There is no indication from the message whether the first 
value is the return value (this is a weakness in the array encoding of 
results as there is no way to indicate whether the first item is the 
return value or not).

Although this may not be the view that each programming language has of 
the results, and the SOAP spec should be neutral to the implementation 
language, I think it is the most common view and the encoding should not 
prohibit support for this kind of processing.
 
Sorry if this is not explained very well. I think a major omission in 
1.1 was the lack of a clearly marked return value and was glad to see 
its inclusion in 1.2.

Pete



>
>------------------------------------------------------------------
>Noah Mendelsohn                              Voice: 1-617-693-4036
>IBM Corporation                                Fax: 1-617-693-8676
>One Rogers Street
>Cambridge, MA 02142
>------------------------------------------------------------------
>
>
>

Received on Sunday, 14 April 2002 01:06:28 UTC