RE: Issue with soap-rpc:result

 Noah,
 the following things would be left in the RPC section:
 1) that the dispatch is based on the QName of the first 
immediate child of Body, and that its local name is based on the 
procedure's name;
 2) that the parameters' names are based on the names in the
procedure's declaration and that the parameters' actual values
are elements in the procedure element (see 1) in the same order 
as in the procedure's declaration (if available);
 3) that the result is an first child element of Body (its name 
being irrelevant)
 4) that the return value is the first out parameter, named 
enc:result.

 The pros of this change: we can serialize parameters using other
encodingStyles (even different ones), we can keep ordering
restrictions (unavailable in the Encoding's structs), we don't
have to worry about serialization roots in the Body.
 The cons: we'd probably have to duplicate some stuff from the 
Encoding regarding null parameter values and completely 
descriptive messages would probably have to contain encodingStyle 
attribute on each of the parameters.

 It seems to depend on the respective values of the pros and 
cons. I can have it both ways. 8-)

 Best regards,

                   Jacek Kopecky

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



On Tue, 12 Feb 2002 noah_mendelsohn@us.ibm.com wrote:

 > Jacket Kopecky writes:
 > 
 > >> Therefore I vote yes on 2 - decoupling RPC from 
 > >> the graph data model
 > 
 > It's interesting to ask what's left of RPC when we do this.  We've already 
 > separated out request/response as an exchange pattern, so we've got that. 
 > By leaving out the data model, we're eliminating any fixed notion of how 
 > arguments are results are modeled, except to say that they are XML.  The 
 > only thing I can think of that's left is to indicate that the QName of the 
 > immediate child of <Body> is the key to dispatching the service to be 
 > performed (keep in mind that our default rules for handling bodies are now 
 > looser than that.)  What else would be left of RPC in your proposal (I'm 
 > neither endorsing nor disagreeing with it, just asking for clarification). 
 >  Thanks.
 > 
 > ------------------------------------------------------------------
 > Noah Mendelsohn                              Voice: 1-617-693-4036
 > IBM Corporation                                Fax: 1-617-693-8676
 > One Rogers Street
 > Cambridge, MA 02142
 > ------------------------------------------------------------------
 > 
 > 
 >

Received on Wednesday, 13 February 2002 04:45:32 UTC