RE: Issue with soap-rpc:result

> 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.

I think *loads* of people think of not just the SOAP RPC model, but SOAP
as a whole this way.
 
> 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.

Agreed. I think this should be clarified in the spec so that we don't go
through another extended period debating the mapping of argument lists
to SOAP RPC messages.
 
> 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.

I'm against it too. The problem is that a lot of people working at the
WSDL level assume that an endpoint can distinguish between two
operations from different interfaces. If there is a single QName to
indicate a message's intent to a dispatcher, what does the local part of
the QName identify? For a "doc/literal" endpoint it identifies a message
based on a global element decl. For an "rpc/encoded" endpoint it
identifies an operation name, but not its interface. If this is all the
SOAP RPC model allows, the WSDL working group has to decide whether an
interface is just an illusion to make it easier to talk about whether an
endpoint processes a set of messages or whether it should have some
notation on the wire. If the latter is the case, SOAP's RPC model may
tie WSDL's hands somewhat. But, having said that, I agree with your
position and see this as something to leave ot the WSDL WG. Hopefully
they will address this issue directly and not leave it to the
implementor as WSDL 1.1 does now.

Thanks,
Tim-

Received on Thursday, 14 February 2002 15:19:11 UTC