Proposal for the Removal of the Message Construct from WSDL 1.2

Roberto Chinnici, Sun Microsystems, Inc.
Martin Gudgin, Microsoft
Jeffrey Schlimmer, Microsoft

October 21st, 2002

Introduction

The <wsdl:message/> construct has an unenviable status in WSDL 1.1 and 1.2. Underpowered and sandwiched between more interesting and semantically rich constructs (operations and types), it often appears to exist for purely syntactic reasons.

In this proposal, we explore how the removal of message from WSDL 1.2 would pleasantly affect the language, giving tangible benefits to spec editors, extensions writers, service authors, tools writers and more.

Problem Statement

The <wsdl:message/> construct describes a message as a list of parts of arbitrary types.

The first problem that WSDL authors face is the limited expressiveness of this construct. Several useful capabilities are completely absent. For instance,

messages cannot extend other messages;
message parts cannot be shared by messages
message parts cannot be defined as being optional;
message parts cannot have an associated multiplicity (e.g. "this part must appear at least twice");
message parts are named by NCNAMEs, not qualified names;
messages cannot be defined as being "extensible", i.e. as accepting arbitrary parts in addition to those specified.

Although some of these limitations could be addressed by extending the <wsdl:message/> and <wsdl:part/> constructs, we'd rather not duplicate work done in other working groups. Moreover, it's always hard to determine where we should draw the line when adding new features.

Expressiveness aside, it's often the case that messages are superflous and have to be present exclusively for syntactic reasons. Not only fault messages consist of just one part, but a common WSDL authoring style uses single-part input and output messages for all operations.

Here's an example taken from the WSDL 1.1 specification ([1], Section 1.2, Example 1):

    <types>

       <schema targetNamespace="http://example.com/stockquote.xsd"

             
xmlns="http://www.w3.org/2000/10/XMLSchema">

           <element
name="TradePriceRequest">

             
<complexType>

                 
<all>

                     
<element name="tickerSymbol" type="string"/>

                 
</all>

             
</complexType>

           </element>

           <element
name="TradePrice">

             
<complexType>

                 
<all>

                     
<element name="price" type="float"/>

                 
</all>

             
</complexType>

           </element>

       </schema>

    </types>

      

    <message name="GetLastTradePriceInput">

        <part name="body" element="xsd1:TradePriceRequest"/>

    </message>

      

    <message name="GetLastTradePriceOutput">

        <part name="body" element="xsd1:TradePrice"/>

    </message>

      

    <portType name="StockQuotePortType">

        <operation name="GetLastTradePrice">

           <input message="tns:GetLastTradePriceInput"/>

           <output message="tns:GetLastTradePriceOutput"/>

        </operation>

    </portType>

In addition to the presence of single-part messages, another hint that messages can safely be dispensed with comes from the naming convention used in the example above (and, incidentally, by countless other WSDL documents). In particular, notice how the names of the input and output messages for an operation (e.g, GetLastTradePriceInput and GetLastTradePriceOutput) mirror the names of the XML Schema element declarations (TradePriceRequest and TradePrice). Clearly, if the latter were used directly when declaring a <wdsl:operation/>, no loss of information would occur. As yet an additional hint of the artificiality of the part construct itself, consider some of the names typically given to parts of a message: "body", "parameters", "arguments", "result" -- all as generic and non-descript as possible.

Richness and meaningfulness of messages aside, one additional problem is that faced by the authors of a WSDL binding extension.

As things stand today, bindings must deal with (at least) two different packaging/typing constructs, namely <wsdl:message/> and <xsd:complexType/> (or <xsd:element/>): the former applies only to the top-level, while the second one can go arbitrarily deep.
Consequently, when the author of a binding wants to describe the result of applying the binding rules to a <wsdl:operation/>, he is forced to give a first description in terms of message parts, then refine it to say how parts are to be mapped based on their type.

Proposed Resolution

We propose eliminating the <wsdl:message> construct altogether.

In lieu of messages, portType operations would use their favorite type system to describe their input, output and fault messages.

The type system extensibility features currently built in the <wsdl:part/> element would be moved to the <wsdl:input/>, <wsdl:output/> and <wsdl:fault/> elements. In particular, those elements would accept one of the predefined "type" and "element" attributes, used to refer to XML Schema type definitions and element declarations respectively, as well as other arbitrary namespace-qualified attributes to allow WSDL authors to use arbitrary type systems.

The component model would undergo a corresponding change. In particular, "message" and "part" components would disappear, while "message reference" components would acquire some of the properties currently associated with parts.

Consequences

Unlike <wsdl:message/>, the XML Schema type system is feature-rich, so that the limitations listed in the "Problem Statement" section above do not apply. More explicitely,

types can be derived from other types through either extension or restriction;
the minOccurs and maxOccurs attributes can be used to specify cardinality constraints;
the ref attribute allows for sharing of type or element components at any level of the description;
local elements may have qualified names;
the xsd:any construct provides support for extensible content models.

There's also a host of other advanced features that XML Schema possesses, such as substitution groups, that would suddenly become available to WSDL authors as they define the input and output message formats for their operations. Such features are simply unimaginable with the current <wsdl:message/> construct, and we look forward to seeing how they'll be employed should this proposal be accepted.

Since current usage tells us that the XML Schema type system is already used by the vast majority of WSDL 1.1 documents, this proposal would enable WSDL processors to manipulate messages through their XML Schema descriptions alone.

Similarly, binding authors could use XPath and other XML-related technologies without having to introduce special syntax to deal with messages and parts, as was the case in WSDL 1.1. For instance, the result of applying a binding to a "message type" could be fully described using XSLT. It's also worth pointing out that the working group has already started taking steps in that direction, as witnessed by the changes to the <soap:header/> element approved at the last face to face meeting.

The case of other type systems can be readily accommodated by using the extensible nature of the <wsdl:input/>, <wsdl:output/> and <wsdl:fault/> element. Any type system worth its name will provide structuring constructs at least as powerful as <wsdl:message/>, so the removal of <wsdl:message/> won't be felt as a limitation. Rather, the ability to use the full power of the native type system will be energizing, just as for XML Schema.

A case that isn't directly addressed by this proposal is that of a <wsdl:message/> with parts described using different type systems. Until today, this case has been mostly of theoretical interest only, except in one case described below. In general, there is a range of solutions available, going from embedding all those type systems inside the XML Schema one to defining a new packaging construct specially for this purpose. Although we're not convinced of the usefulness of this "multiple type systems" scenario, we think that our proposal does not in any way prevent determined WSDL authors from using it.

There is a special case, namely the combination of XML Schema and MIME types, that is worth spelling out in detail.

In WSDL 1.1, MIME types were not specified at the message part level; rather, they were listed in the MIME binding extension. For WSDL 1.2, there is definitely some interest in allowing MIME types to be used at the abstract level.

We believe that this proposal doesn't make using MIME types any harder, and that any satisfactory solution that used the <wsdl:message/> and <wsdl:part/> constructs could be rephrased in terms of XML Schema. (For instance, XML Schema type definitions could be annotated with a mime:typeattribute. Or new type definitions, in their own namespace, could be created for all MIME types.) So we propose that the working group address the issue of using MIME types alongside XML Schema types as part of a separate issue, independent of the present one.

Examples

Consider the following WSDL 1.2 fragment (adapted from the Primer):

<message name="inReserveRoom">     <part name="customerName" type="xs:string"/>     <part name="checkInDate" type="xs:date"/>     <part name="checkOutDate" type="xs:date"/>         <part name="roomType" type="xs:string"/>         <part name="comments" type="xs:string"/>         <part name="agentID" type="xs:string"/>    </message>
<message name="outReserveRoom">     <part name="roomRate" type="xs:double"/>         <part name="reservationID" type="xs:string"/>   </message>

<operation name="ReserveRoom">        <input message="inReserveRoom"/>        <output message="outMessage"/>   </operation>

With our proposal, it would be rewritten as follows:

<types>     <xs:schema elementFormDefault="qualified" targetNamespace="http://www.w3.org/webServicesDescription12/PrimerExamples/example0">         <xs:complexType name="tReserveRoomInput">             <xs:sequence>                 <xs:element name="customerName" type="xs:string"/>                 <xs:element name="checkInDate" type="xs:date"/>                 <xs:element name="checkOutDate" type="xs:date"/>                 <xs:element name="roomType" type="xs:string"/>                 <xs:element name="comments" element="xs:string"/>                 <xs:element name="agentID" type="xs:string"/>             </xs:sequence>         </xs:complexType>
        <xs:complexType name="tReserveRoomOutput">             <xs:sequence>                 <xs:element name="roomRate" type="xs:double"/>                 <xs:element name="reservationID" type="xs:string"/>             </xs:sequence>         </xs:complexType>     </xs:schema> </types>

<operation name="ReserveRoom">     <input type="typens:tReserveRoomInput"/>     <output type="typens:tReserveRoomOutput"/> </operation>

As shown above, the XML Schema type system can be readily used to replace the less powerful <wsdl:message/> construct.

Another example from the primer shows how superflous messages are whenever WSDL authors have already come up with a suitable XML Schema description of the fragments they intend to exchange. Here's the relevant WSDL fragment in the current syntax:

<types>    <xs:schema elementFormDefault="qualified" targetNamespace="http://www.w3.org/webServicesDescription12/PrimerExamples/example0">     <xs:complexType name="tInReserveRoom">         <xs:sequence>           <xs:element name="customerName" type="xs:string"/>           <xs:element name="checkInDate" type="xs:date"/>           <xs:element name="checkOutDate" type="xs:date"/>           <xs:element name="roomType" type="xs:string"/>           <xs:element name="comments" element="xs:string"/>           <xs:element name="agentID" type="xs:string"/>         </xs:sequence>      </xs:complexType>    </xs:schema>   <xs:complexType name="tOutReserveRoom"> <xs:sequence> <xs:element name="roomRate" type="xs:double"/> <xs:element name="reservationID" type="xs:string"/> </xs:sequence> </xs:complexType> </types>
<message name="inReserveRoom">    <part name="ReserveRoom" type="typens:tInReserveRoom"/> </message>

<message name="outReserveRoom">    <part name="ReserveRoom" type="typens:tOutReserveRoom"/> </message>

<operation name="ReserveRoom">     <input message="inReserveRoom"/>     <output message="outReserveRoom"/> </operation>

And here's the corresponding fragment with the proposed new syntax:

<types>    <xs:schema elementFormDefault="qualified" targetNamespace="http://www.w3.org/webServicesDescription12/PrimerExamples/example0">     <xs:complexType name="tInReserveRoom">         <xs:sequence>           <xs:element name="customerName" type="xs:string"/>           <xs:element name="checkInDate" type="xs:date"/>           <xs:element name="checkOutDate" type="xs:date"/>           <xs:element name="roomType" type="xs:string"/>           <xs:element name="comments" element="xs:string"/>           <xs:element name="agentID" type="xs:string"/>         </xs:sequence>      </xs:complexType>    </xs:schema>
<xs:complexType name="tOutReserveRoom"> <xs:sequence>    <xs:element name="roomRate" type="xs:double"/>    <xs:element name="reservationID" type="xs:string"/> </xs:sequence> </xs:complexType> </types>

<operation name="ReserveRoom">     <input type="typens:tInReserveRoom"/>     <output type="typens:tOutReserveRoom"/> </operation>

Clearly, the message definitions in the first fragment are completely superflous and serve a syntactic purpose only. There is literally NO use of the message components in the first fragment that cannot be reproduced with the approach exemplified in the second fragment. Moreover, the latter allows for derivation of messages (and much more) while the first one does not.

References

[1] Web Services Definition Language (WSDL) 1.1