Re: proposal for restricting a service to a single interface

Amy,

I'd like to summarize some of the points.

1. In WSDL 1.1, there is virtually no semantics associated with putting 
several <port>s in a <service>. See http://www.w3.org/TR/wsdl#_services :

Ports within a service have the following relationship:
None of the ports communicate with each other (e.g. the output of one port 
is not the input of another). 
If a service has several ports that share a port type, but employ 
different bindings or addresses, the ports are alternatives. Each port 
provides semantically equivalent behavior (within the transport and 
message format limitations imposed by each binding). This allows a 
consumer of a WSDL document to choose particular port(s) to communicate 
with based on some criteria (protocol, distance, etc.). 
By examining it's ports, we can determine a service's port types. This 
allows a consumer of a WSDL document to determine if it wishes to 
communicate to a particular service based whether or not it supports 
several port types. This is useful if there is some implied relationship 
between the operations of the port types, and that the entire set of port 
types must be present in order to accomplish a particular task. 

The only claim is that IF two or more ports implement the same portType, 
then they are semantically equivalent and are alternate ways to access the 
service.
2. In WSDL 1.2, I believe there is a desire to put more semantics into 
<service>. So we have two directions to go in. We can either strengthen 
the above statement so that ALL <port>s must implement the same portType 
and represent alternative ways to access the service, or we can add ways 
to state more semantics, e.g. that a set of the <port>s share state. IHMO 
either direction is preferrable to the status quo. The reason is that 
<service> is a modularization construct, and good modules should have 
cohesion, i.e. there should be a good reason for putting things in the 
same module. At present, the only reason is that somehow, the <port>s are 
"related". We should be able to be cleared than that.
3. You raise the example of a service that has no request-response 
operations, which presents a problem for operations like 
getNotificationService. You probably will not like this suggestion, but 
why not define a parent request-response service that has getXXXService 
operations for all of its component services? You can have <service> 
elements for the parent service and each of the component services.

Arthur Ryman