RE: proposal for restricting a service to a single interface

+1 and +1.
 
I was writing up a longer response to Amy's earlier post, but then I got really confused because she seemed to be arguing first for multiple ports in a service, and then for a service to represent a single "state machine" (instance)... after a few minutes I may have figured it out. :)
 
So I think (please correct me if I'm wrong here) that Amy does want a single "instance" behind a <service>, but she wants the ability to specify different portTypes in order to support things like an "extra" registerForCallback() API which is needed on an asynchronous binding/endpoint and not required for a synchronous HTTP endpoint to the same service.  In other words, the API differences which the multiple ports in the <service> might evince are more about the binding-specific semantics (QoS, asynchrony) than they are about actual application semantics.  Is that at all accurate, Amy?
 
I'd strongly prefer to keep things simple, only allow one interface per <service>, but then let the binding specifications (or SOAP Module specifications, or other extensions) determine the "middleware" messages which might be accepted in order to control things such as asynchronous callbacks/subscriptions/etc.  For higher level concepts of association like management interfaces, I think it really should be a higher-level specification which makes those associations.  A service as defined in WSDL should represent (IMHO) a single interface - if you want a management interface at one endpoint to your service, then either all endpoints to your service should implement the management interface as well (i.e you aggregate to a single interface with both management + application APIs), or if you really want a separate endpoint for management, you should have two services with external linkage.
 
A real-world example of this kind of thing - when I call up the sales number for a software vendor, I do not expect them to be able to solve my technical support problems.  There are two different numbers for a reason, despite the fact that I'm calling the same company.  From the point of view of a person needing to make a phone call to accomplish a task (buying software, getting help with software), the fact that the two numbers happen to both connect to the same company isn't particularly relevant.
 
Bottom line - don't force developers who want to do the simple stuff to handle the potentially complex stuff.  Keep the simple stuff simple and add complexity as needed in a modular fashion.
 
--Glen

-----Original Message-----
From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Wednesday, April 30, 2003 12:57 PM
To: Amelia A. Lewis
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: Re: proposal for restricting a service to a single interface



Amy, 

My reading of "alternative ways to invoke the service" is that there is one state machine as you call it. I interpret semantic equivalence to mean that the operations have the same effect on the state of the service. Please forgive the following somewhat facetious example. In the following I assume that the telephone number URI problem has been solved. 

I can order pizza from Pizza, Pizza  in Toronto either by phone, or online [1]. Therefore I have one PizzaInterface, two bindings, but one <service>. I could place my order on the Web and then later phone in a correction. I'd still get just one pizza delivered. 

Putting 17 vendors into the same <service> violates that. For example, there may be 17 pizza companies that all decide to implement the PizzaInterface. They shouldn't be placed in some pizza portal <service> element. If I order a pizza from Pizza Pizza, I don't have to pay Momma's Pizza. 

You may regard the proposed restriction as silly and of no value, but I hope you'll grant that it is at least simple and clear.

[1]http://pizzapizza.com/indexlanguage.htm 

Arthur Ryman