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

 Pete,
 I'll try to explain my position by a sort of look from aside.

 For building a client or a service, we need to know what the
supposed contract of the service, i.e. the formats of the in and
out messages.
 This can be accomplished using XML Schema (or any other xml 
schema language). That's the lower level we don't want in RPC.
 Otherwise this can be accomplished by stating the procedure
signature and by having a model of a signature and clear rules 
for mapping such signatures to XML data in SOAP Messages. 

 The current version has these clear rules and some kind of a 
signature model (not explicitly described) for the struct case. 
 The first part of my proposal aims to clarify the rules for the
array case, too.

 The second part of my proposal is more radical in that it
simplifies the model of a procedure by removing the in/out
parameters and return value terms.

 Now let me analyze the differences between the three version:

 Currently a message is able to say whether there is a return 
value and what arguments are present (for the struct case) and 
the spec is unclear (if not broken) for the array case.

 The first part of my proposed rewrite keeps it the same for the
struct case and makes it clear that there is no distinction
between a return value and an out parameter in the array case
(because in my optinion there really *is no distinction* between
a return value and positional out parameters - they both don't
have a name and it doesn't really matter whether you start
counting the parameters from 0 or from 1). So effectively, this
first part of my proposal has no notion of a return value.

 The full proposal goes further - removing in/out parameters 
and the return value altogether. Now let me explain why I 
don't think we're losing anything:
 IMHO the notion of in/out parameters need not be in the protocol
since we don't have the explicit model of a procedure and an
in/out parameter in fact means one value going there and one
going back. When the parameter is named, they probably share the
name. In any case, only the language bindings are concerned with 
this and we cannot help them here. Not every language supports 
in/out params.
 With return values it's a little more complex. It's already not
really there in the array case so let me only think about the
named parameters case. If we want a struct (as opposed to
multistructs which IMO would be dirtier to spec out) we have to
give a name to the return value. Currently we give it the full 
name but many people complain this doesn't really play well with 
XML Schema, which is true but which I don't think should concern 
us at all. 
 There were proposals to only specify the local name (but the
possibility of various conflicts arises here which would have to
be solved in the language bindings).
 There were proposals to keep the name in the application domain, 
which is exactly what I've done in my full proposal.

 I think either way (only first part or the full proposal) is an
improvement over the current state, with the second part only
going further in the direction of the first part. The first part 
will not solve the issue 195, but that can be solved by saying 
"we think mandating the full ns-qualified name is better than 
only mandating the local name", please see my subsequent email on 
this (it will have the subject "Issue 195: why not only specify 
the local part" or something alike).

 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Sun, 14 Apr 2002, Pete Hendry wrote:

 > 
 > 
 > 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 Tuesday, 16 April 2002 07:35:29 UTC