RE: Issue with soap-rpc:result

 Tim,
 of course I'll tell you this is an issue for the WSDL group. 8-)

 No, seriously, I'll try here to explain why I think the SOAP 
part of the issue is solved by the current rules and that the 
WSDL part of the issue can be built on top of this with no 
problem at all. BTW, I'm on the WSDL group, too, and I think I'm 
aware of the issues with IDL languages.

 For remote procedure calls system, the basic notion is a
procedure with parameters. There is no inherent notion of groups
of procedures because procedures can be grouped in various ways
and in multiple levels (even WSDL has services containing M
portTypes containing N operations - procedures).

 In SOAP RPC, the dispatch is two-level right now - on the access
URL of the request and on the RPC element's qualified name. The 
dispatch on the qname can be split to dispatching on the 
namespace and on the local name.

 You want to add an operation ID and an interface ID - terms of
an IDL language. I think they translate to operation's input name
and portType name in WSDL. (Operation's input name as opposed to 
operation name - because operations need not have unique names, 
it's their inputs and outputs that identify the operations. We 
can choose only one because that's sufficient, and in RPC we can 
assume there will be an input, I think.)

 To solve your issue, WSDL can mandate that the soap:body
namespace attribute's value somehow identify the portType. The 
local part can then identify the operation (for overloading, I 
actually suggest that this be the operation's input name, again).

 So SOAP already gives you three levels of dispatch and WSDL can
easily map these levels to its terms like port, portType,
operation. And I think this should be done.

 Do you still think that something need be added to the SOAP RPC 
convention?

                   Jacek Kopecky

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



On Wed, 13 Feb 2002, Tim Ewald wrote:

 > >  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 07:20:06 UTC