June 09, 2002.
The W3C WS-Desc WG is considering the following issues:
<issue id="issue-portType-extensibility"> <head>Should portTypes be extensible?</head> Some users have asked that portTypes be extensibile. We need to carefully consider whether that is a good thing or not. <source>Sanjiva Weerawarana</source> </issue>
<issue id="issue-service-type"> <head>Should we have an abstract view of a service?</head> WSDL defines a service as a collection of ports, but there is no abstract analog. <source>Sanjiva Weerawarana</source> </issue>
<issue id="issue-multiple-services"> <head>Should a single WSDL file only define one service?</head> WSDL 1.1 suppports having multiple services in a single WSDL file. This has caused confusion amongst users. <source>Sanjiva Weerawarana</source> </issue>
This document proposes a resolution to these issue. The outline of the proposed resolution is as follows:
Add XML level extensibility to all WSDL elements (already agreed to by the WG)
Define a first-class concept of service type which is a named group of portTypes
Require all <service>s in a single document to implement the same service type
Define compatibility rules for service types
The rest of this document provides details of this proposal.
WSDL 1.1 allowed the use of "extensibility elements" in selected locations to allow one to insert elements and attributes from other namespaces to extend WSDL. The W3C WS-Desc Working Group now has a working proposal (developed by Roberto Chinnici of Sun) to generalize this to allow extensibility at any location in WSDL, not just selected locations. Furthermore, extensions will be required to be declared. The current working proposal can be found at:
It is likely that this proposal will be accepted. This addresses issue "issue-portType-extensibility" and resolves it in general for all elements of WSDL 1.2, not just the <portType> element.
There has been widespread interest in providing the abstract analog of a service. WSDL 1.1 defines the concept of a service, but does not provide a mechanism to use the type of a service without bindings for portTypes within the service. Furthermore, the semantics of a <service> element in the presense of multiple portTypes is not clear (whether one can have more than one port-per-portType or even whether at least one port-per-portType is required).
The proposal is that we define a new first-class concept called "service type." The rest of this section provides details of what that would entail. All elements are in the WSDL 1.2 namespace unless otherwise indicated. All elements are direct children of <wsdl:definitions>, unless otherwise indicated.
The proposal is to define the concept of a service type. A service type is a named collection of portTypes. It is defined using the following syntax:
<serviceType name="ncname"> <portType name="qname"/>+ </serviceType>
We require that all services defined in a single document be of a single service type. That type is indicated by inserting the following required declaration:
<definitions> ... <implements serviceType="qname"/> <service name="ncname">+ ... </service> </definitions>
Given two service types ST1 and ST2, we say that ST1 is compatible with ST2 (i.e., ST1 can be used in place of ST2) iff:
where two portTypes are said to be equivalent iff they have the same qualified name.
Multiple <service> elements are allowed within a WSDL file. Each service is effectively an alternate implementation of the service type of the document. However, it is important to note that services cannot be changed "mid-stream" for stateful services; i.e., once an interaction is started with one <service>, one cannot switch over to another <service> for further interaction with the same stateful service instance.
We also have to address the question of how many <port> declarations per <portType> are allowed within a single <service> element. WSDL 1.1 permits any number of <port>s for the same portType, but does not define the semantics for that case. We propse that each <service> element in a WSDL document would be required to provide at least one <port> declaration per portType of its service type. Alternate ports are to be considered identical, that is, that those are just different access mechanisms for the same portType.