Forwarded message 1
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-