RE: Issue with soap-rpc:result

 Noah, I agree with your analysis completely.
 I also agree that SOAP RPC need not (and should not) talk about 
interfaces (groups of procedures).
 I also agree wholeheartedly that we must not preclude any kind
of implementation, although for some people we will always seem
_like_ we mandate some implementation, whereas others will always
understand that however they implement a given interface, as long
as they keep the contract, they are free to do anything they
want.
 I always thought SOAP RPC followed your option #1 (although 
quite vaguely and implicitly). It might be useful if the RPC 
section were reworded to be explicitly closer to it.
 Best regards,

                   Jacek Kopecky

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



On Thu, 14 Feb 2002 noah_mendelsohn@us.ibm.com wrote:

 > On the specific question of interfaces, I don't think we should go there. 
 > SOAP used to have them, and they were taken out.  Naming methods with 
 > QNames (effectively with URI's) is sufficient to let you build notions of 
 > interface above SOAP if that's what you need. 
 > 
 > That said:  I think you're exposing a deeper question that does need 
 > attention, and as you say it's not primarily a WSDL question.  I think 
 > it's fair to say that SOAP RPC is generally intended to provide a 
 > "method-like" abstraction on the wire.  There are a number of ways to 
 > introduce this, and I think we've been too vague.  Here are the choices I 
 > see:
 > 
 > -----
 > Option 1) Postulate in the recommendation a specific abstract model of 
 > what a procedure or method is, and explain how to map to the wire.  For 
 > example, we could say something along the lines of:  "this specification 
 > models communicating programs as follows:  the provider of a service is 
 > modeled as a programming language or other system with the following 
 > characteristics:
 > 
 >         - methods which can be invoked by name (here is where you
 >           would introduce your assumptions about overlapping
 >           interfaces, though as I say, I myself would prefer not)
 >         - a list of arguments which are ordered and optionally
 >           named (or however you model generalized argument lists)
 >         - a set of errors carrying XXX information
 >         - etc., etc.  this list is meant to convey the
 >           general idea, not to have details correct
 > 
 > You then say:  for each method invocation, return result, and error, this 
 > specification provides a mapping between the abstract programming system 
 > described above and the corresponding representation in SOAP.   It is 
 > anticipated that particular SOAP implementations will map the abstract 
 > SOAP method model to appropriate programming structures within that 
 > implementation.  For example, SOAP method calls will typically (but not 
 > necessarily) result in corresponding method calls at the receiver.
 > 
 > Option 2) DO NOT try to model the programming systems at the endpoints. 
 > Merely say:  this SOAP RPC specification introduces a set of SOAP message 
 > formats and conventions for their exchange.  These are intended to be 
 > convenient to map to a reasonable broad range of programming languages and 
 > systems;  the nature of such mappings is outside the scope of this 
 > specification.  The QName of the element which is the immediate child of 
 > body indicates the nature of the request being performed.  The element 
 > information item children of that element convey data that parameterizes 
 > the request.  In cases where a single (possibly structured) datum is to be 
 > returned from the request, the representation in soap is soap-rpc:result, 
 > etc.  In other words, steer clear of trying to say much about the 
 > abstractions at the endpoints.  Just talk about what goes on the wire.
 > -----
 > 
 > I had originally seen SOAP 1.1 as being closer to #2. I now see lots of 
 > discussion and proposed text that seems to presume model #1.  We seem to 
 > be freely talking about "interfaces" (an endpoint construct), or from 
 > Gudge's note:
 > 
 > "For example, given the following COM IDL method signature:
 > 
 >         void Add ( [in] long x, [in] long y, [out] long* sum );"
 > 
 > which is very much an option #1 way of looking at the world.
 > 
 > Bottom line:  I think option #1 is OK, but if we're going to do it, we 
 > should do it explicitly, unambiguously, and concisely.  If we are talking 
 > about how to map an argument list, we need to say something about what we 
 > think an argument list is.  We MUST NOT do this in a way that seems to 
 > preclude implementations that do not in fact map to methods.  If I want to 
 > handle all your SOAP RPC methods in one C switch statement, what's it to 
 > you?  The spec should not appear to preclude that.
 > 
 > Returning to your original query on interfaces:  In the course of modeling 
 > the abstract programming system at the endpoints (option #1) we have the 
 > option to state:  "the provider of a service is modeled as offering 
 > methods grouped into interfaces.  In cases where methods with the same 
 > name appear in two or more interfaces offered by the same endpoint it {is 
 > (Java), is not (COM)} presumed to represent the same underlying method." 
 > Although we _could_ introduce interfaces in this manner, I am against it. 
 > Let's talk about services or endpoints offering sets of methods.  How they 
 > are grouped should be treated above the SOAP layer, I think.
 >  
 > 
 > ------------------------------------------------------------------
 > Noah Mendelsohn                              Voice: 1-617-693-4036
 > IBM Corporation                                Fax: 1-617-693-8676
 > One Rogers Street
 > Cambridge, MA 02142
 > ------------------------------------------------------------------
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > "Tim Ewald" <tjewald@develop.com>
 > Sent by: xml-dist-app-request@w3.org
 > 02/13/2002 02:28 PM
 > Please respond to tjewald
 > 
 >  
 >         To:     "'XMLDISTAPP'" <xml-dist-app@w3.org>
 >         cc: 
 >         Subject:        RE: Issue with soap-rpc:result
 > 
 > 
 > >  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;
 > 
 > I know you'll tell me this is an issue for the WSDL group, but you have
 > to be careful here. One of the problems with WSDL is that it wants to
 > create the notion of portTypes (interfaces) and operations. Most
 > traditinal RPC and ORPC models support this, and the interface ID and
 > operation ID are send in a request message along with the input
 > parameters. If the SOAP RPC model mandates that dispatching is based on
 > the QName of the first immediate child of the body, what happens if two
 > interfaces have operations of the same name?
 > 
 > ICowboy::Draw
 > IArtist::Draw
 > 
 > Do the two interfaces have to be defined in different namespaces? Is
 > that only necessary when there is a method with the same name?
 > 
 > The problem with delegating this issue to the WSDL working group is that
 > they won't be able to change the SOAP RPC rules. If there is going to be
 > a SOAP RPC model and we want to support the notion of interfaces as
 > collections of operations, this should be addressed at the protocol
 > level and not solely at the description level.
 > 
 > To that end, I'd love to see attributes for annotating a Body with an
 > interface's and operation's QName specifically for dispatching. This
 > could be done in the WSDL working group, but only if the SOAP RPC model
 > doesn't mandate that dispatching be accomplished based solely on the
 > QName of the first child of the body.
 > 
 > Thanks,
 > 
 > Tim-
 > 
 > 
 > 
 >

Received on Friday, 15 February 2002 07:36:20 UTC