Sanjiva Weerawarana, January 18, 2003
This document proposes a mechanism for eliminating the <message>
construct from WSDL. The proposed approach attempts at a compromise between
the two extreme positions possible (keep message and replace with just a
single complex type).
The proposal is written using the shortcut syntax, but can easily be re-written using the interaction patterns syntax if desired.
The <message> construct in WSDL was created to address the requirement that messages often consist of more than one "thing" that needs to be sent. These "things" are typically related, but not logically part of one large structure. The most prevalent example is that of some request sent along with related information (documents). The related information may be sent as attachments, but that's a question of the message serialization used and not an issue at the abstract level of service description.
I believe that the concept of a message consiting of multiple parts
is very real and very much required. However, the use of a new construct,
<message>, to represent such messages have caused much grief.
As things stand today, the <message> construct defines a message
as consisting of a set of parts, where each part is typed by some type system.
The immediately supported type system is XML Schema, using the attributes
"type" or "element".
The new syntax proposal is as follows:
1 <portType name="ncname">
2 <operation name="ncname">+
3 <input [name="xsd:string"] type-indicator [cardinality-indicator]/>*
4 <output [name="xsd:string"] type-indicator [cardinality-indicator]/>*
5 <fault type-indicator/>*
6 </operation>
7 </portType>
Lines 2-6 define an input-output or input-only operation. Operations have
names and indicate zero or more things that may be sent as input (line 3),
zero or more things that the service may generate in response (line 4) and
zero or more fault types, one of which the service may send instead of a response
(line 5). Each "thing" is typed using some type system and indicates its
cardinality. Each "thing" may optionally be named so as to allow bindings
to be selective about which parts go where in building a wire format. Note
that at least one input or output must be specified and that the lack of
any inputs indicates that the
How does one specify the type? WSDL 1.1 supported XML Schema types and
elements and left room for other type systems. I propose WSDL 1.2 explicitly
support XML Schema and the MIME type systems. The proposed syntaxes for
type indicators are as follows:
xsdType="qname"
xsdElement="qname"
mimeType="string"
Thus, any input, output or fault could be typed using XML Schema or MIME.
Other type systems will be supported via extensibility.
How does one specify the cardinality? One of the issues we've had with the <message> construct is that it did not allow one to specify that a part is optional, or that a part may repeat and so on. While it is not desired to re-invent XML Schema's mechanisms for indicating cardinality, it is indeed useful to be able assert some of that information. I propose we select a compromise position whereby we allow any input, output or fault to indicate its "minOccurs" and "maxOccurs" cardinality, where minOccurs and maxOccurs are defined as per XML Schema. The proposed syntax is as follows:
As with XML Schema, the default value for minOccurs and maxOccurs will be 1 and "unbounded" is used to indicate infinity.<(input|output|fault) [name="xsd:string"] type-indicator [minOccurs="int"] [maxOccurs="int"]/>
The following portType fragment illustrates how this functionality will
be expressed using the proposed new syntax:
<portType name="ArchivalService">
<operation name="StoreRecords">
<input name="patient" xsdType="x:PatientIdentificationType"/>
<input name="xrays" mimeType="image/jpg" minOccurs="0" maxOccurs="unbounded"/>
<input name="reports" xsdElement="y:LabReport" minOccurs="0" maxOccurs="unbounded"/>
<output xsdType="anyURI"/>
<fault xsdType="z:SomethingWrong"/>
</operation>
... other operations ...
</portType>