- From: Pete Hendry <peter.hendry@capeclear.com>
- Date: Sun, 14 Apr 2002 17:05:56 +1200
- To: xml-dist-app@w3.org
- CC: Noah Mendelsohn/Cambridge/IBM <noah_mendelsohn@us.ibm.com>, Jean-Jacques Moreau <moreau@crf.canon.fr>, Jacek Kopecky <jacek@systinet.com>, Herve Ruellan <ruellan@crf.canon.fr>
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