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

Re: proposal for restricting a service to a single interface

From: Arthur Ryman <ryman@ca.ibm.com>
Date: Wed, 30 Apr 2003 11:09:32 -0400
To: "Amelia A. Lewis" <alewis@tibco.com>
Cc: www-ws-desc@w3.org, www-ws-desc-request@w3.org
Message-ID: <OF4EE8DA2A.046ECBD1-ON85256D18.00487A5F@torolab.ibm.com>

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 
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
Received on Wednesday, 30 April 2003 11:09:42 UTC

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