RE: Issue with soap-rpc:result

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 Thursday, 14 February 2002 14:08:08 UTC