W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2003

RE: proposal for restricting a service to a single interface

From: Glen Daniels <gdaniels@macromedia.com>
Date: Wed, 30 Apr 2003 13:51:49 -0400
Message-ID: <CB1FF0A474AEA84EA0206D5B05F6A4CB02550039@S1001EXM02.macromedia.com>
To: "'Arthur Ryman'" <ryman@ca.ibm.com>, "Amelia A. Lewis" <alewis@tibco.com>
Cc: www-ws-desc@w3.org
+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.

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


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.


Arthur Ryman
Received on Wednesday, 30 April 2003 13:52:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:42 UTC