You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
5816 lines
255 KiB
5816 lines
255 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content=
|
|
"text/html; charset=utf-8" />
|
|
<title>Web Services Description Language (WSDL) Version 2.0 Part 0:
|
|
Primer</title>
|
|
|
|
<style type="text/css" xml:space="preserve">
|
|
/*<![CDATA[*/
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
ol.enumar { list-style-type: decimal; }
|
|
ol.enumla { list-style-type: lower-alpha; }
|
|
ol.enumlr { list-style-type: lower-roman; }
|
|
ol.enumua { list-style-type: upper-alpha; }
|
|
ol.enumur { list-style-type: upper-roman; }
|
|
|
|
dt.label { display: run-in; }
|
|
|
|
li, p { margin-top: 0.3em;
|
|
margin-bottom: 0.3em; }
|
|
|
|
.diff-chg { background-color: yellow; }
|
|
.diff-del { background-color: red; text-decoration: line-through;}
|
|
.diff-add { background-color: lime; }
|
|
|
|
table { empty-cells: show; }
|
|
|
|
table caption {
|
|
font-weight: normal;
|
|
font-style: italic;
|
|
text-align: left;
|
|
margin-bottom: .5em;
|
|
}
|
|
|
|
div.issue {
|
|
color: red;
|
|
}
|
|
.rfc2119 {
|
|
font-variant: small-caps;
|
|
}
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
|
|
th { color: #000000; background-color: #CCCC99; }
|
|
span.test-assertion { background-color: #FFC0CB; }
|
|
span.test-assertion-tr:hover { background-color: #FFC0CB; }
|
|
/*]]>*/
|
|
</style>
|
|
<link rel="stylesheet" type="text/css" href=
|
|
"http://www.w3.org/StyleSheets/TR/W3C-REC.css" />
|
|
</head>
|
|
<body>
|
|
<div class="head">
|
|
<p><a href="http://www.w3.org/"><img src=
|
|
"http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width=
|
|
"72" /></a></p>
|
|
<h1><a name="title" id="title"></a>Web Services Description
|
|
Language (WSDL) Version 2.0 Part 0: Primer</h1>
|
|
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Recommendation
|
|
26 June 2007</h2>
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626">http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626</a></dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/wsdl20-primer">http://www.w3.org/TR/wsdl20-primer</a></dd>
|
|
<dt>Previous version:</dt>
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2007/PR-wsdl20-primer-20070523">http://www.w3.org/TR/2007/PR-wsdl20-primer-20070523</a></dd>
|
|
<dt>Editors:</dt>
|
|
<dd>David Booth, W3C Fellow / Hewlett-Packard</dd>
|
|
<dd>Canyang Kevin Liu, SAP Labs</dd>
|
|
</dl>
|
|
<p>Please refer to the <a href=
|
|
"http://www.w3.org/2007/06/wsdl20-errata.html"><strong>errata</strong></a>
|
|
for this document, which may include some normative
|
|
corrections.</p>
|
|
<p>This document is also available in these non-normative formats:
|
|
<a href="wsdl20-primer.pdf">PDF</a>, <a href=
|
|
"wsdl20-primer.ps">PostScript</a>, <a href=
|
|
"wsdl20-primer.xml">XML</a>, and <a href=
|
|
"wsdl20-primer.txt">plain text</a>.</p>
|
|
<p>See also <a href=
|
|
"http://www.w3.org/2003/03/Translations/byTechnology?technology=wsdl20-primer">
|
|
<strong>translations</strong></a>.</p>
|
|
<p class="copyright"><a href=
|
|
"http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2007 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
|
|
(<a href="http://www.csail.mit.edu/"><acronym title=
|
|
"Massachusetts Institute of Technology">MIT</acronym></a>, <a href=
|
|
"http://www.ercim.org/"><acronym title=
|
|
"European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
|
|
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved.
|
|
W3C <a href=
|
|
"http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
|
|
<a href=
|
|
"http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
|
|
and <a href=
|
|
"http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> rules apply.</p>
|
|
</div>
|
|
<hr />
|
|
<div>
|
|
<h2><a name="abstract" id="abstract"></a>Abstract</h2>
|
|
<p>This document is a companion to the WSDL 2.0 specification
|
|
(<em>Web Services Description Language (WSDL) Version 2.0 Part 1:
|
|
Core Language</em> [<cite><a href="#WSDL-PART1">WSDL 2.0
|
|
Core</a></cite>], <em>Web Services Description Language (WSDL)
|
|
Version 2.0 Part 2: Adjuncts</em> [<cite><a href="#WSDL-PART2">WSDL
|
|
2.0 Adjuncts</a></cite>]). It is intended for readers who wish to
|
|
have an easier, less technical introduction to the main features of
|
|
the language.</p>
|
|
<p>This primer is only intended to be a starting point toward use
|
|
of WSDL 2.0, and hence does not describe every feature of the
|
|
language. Users are expected to consult the WSDL 2.0 specification
|
|
if they wish to make use of more sophisticated features or
|
|
techniques.</p>
|
|
<p>Finally, this primer is <em>non-normative</em>. Any specific
|
|
questions of what WSDL 2.0 requires or forbids should be referred
|
|
to the WSDL 2.0 specification.</p>
|
|
</div>
|
|
<div>
|
|
<h2><a name="status" id="status"></a>Status of this Document</h2>
|
|
<p><em>This section describes the status of this document at the
|
|
time of its publication. Other documents may supersede this
|
|
document. A list of current W3C publications and the latest
|
|
revision of this technical report can be found in the <a href=
|
|
"http://www.w3.org/TR/">W3C technical reports index</a> at
|
|
http://www.w3.org/TR/.</em></p>
|
|
<p>This is the <a href=
|
|
"http://www.w3.org/2005/10/Process-20051014/tr.html#RecsW3C">W3C
|
|
Recommendation</a> of Web Services Description Language (WSDL)
|
|
Version 2.0 Part 0: Primer for review by W3C Members and other
|
|
interested parties. It has been produced by the <a href=
|
|
"http://www.w3.org/2002/ws/desc/">Web Services Description Working
|
|
Group</a>, which is part of the <a href=
|
|
"http://www.w3.org/2002/ws/Activity">W3C Web Services
|
|
Activity</a>.</p>
|
|
<p>Please send comments about this document to the public <a href=
|
|
"mailto:public-ws-desc-comments@w3.org">public-ws-desc-comments@w3.org</a>
|
|
mailing list (<a href=
|
|
"http://lists.w3.org/Archives/Public/public-ws-desc-comments/">public
|
|
archive</a>).</p>
|
|
<p>The Working Group released a test suite along with an <a href=
|
|
"http://www.w3.org/2002/ws/desc/5/impl-report/">implementation
|
|
report</a>. A <a href="wsdl20-primer-diff.html">diff-marked version
|
|
against the previous version of this document</a> is available.</p>
|
|
<p>This document has been reviewed by W3C Members, by software
|
|
developers, and by other W3C groups and interested parties, and is
|
|
endorsed by the Director as a W3C Recommendation. It is a stable
|
|
document and may be used as reference material or cited from
|
|
another document. W3C's role in making the Recommendation is to
|
|
draw attention to the specification and to promote its widespread
|
|
deployment. This enhances the functionality and interoperability of
|
|
the Web.</p>
|
|
<p>This document is governed by the <a href=
|
|
"http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24
|
|
January 2002 CPP</a> as amended by the <a href=
|
|
"http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy
|
|
Transition Procedure</a>. W3C maintains a <a href=
|
|
"http://www.w3.org/2002/ws/desc/2/04/24-IPR-statements.html">public
|
|
list of any patent disclosures</a> made in connection with the
|
|
deliverables of the group; that page also includes instructions for
|
|
disclosing a patent. An individual who has actual knowledge of a
|
|
patent which the individual believes contains <a href=
|
|
"http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">
|
|
Essential Claim(s)</a> must disclose the information in accordance
|
|
with <a href=
|
|
"http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">
|
|
section 6 of the W3C Patent Policy</a>.</p>
|
|
</div>
|
|
<div class="toc">
|
|
<h2><a name="contents" id="contents"></a>Table of Contents</h2>
|
|
<p class="toc">1. <a href="#Introduction">Introduction</a>
|
|
<br />
|
|
    1.1 <a href=
|
|
"#Prerequisites">Prerequisites</a>
|
|
<br />
|
|
    1.2 <a href="#PrimerStructure">Structure of
|
|
this Primer</a>
|
|
<br />
|
|
    1.3 <a href="#UseIRI">Use of URIs and
|
|
IRIs</a>
|
|
<br />
|
|
    1.4 <a href="#notation">Notational
|
|
Conventions</a>
|
|
<br />
|
|
2. <a href="#basics">WSDL 2.0 Basics</a>
|
|
<br />
|
|
    2.1 <a href="#basic-example">Getting
|
|
Started: The GreatH Hotel Example</a>
|
|
<br />
|
|
        2.1.1 <a href=
|
|
"#basics-greath-scenario">Example Scenario: The GreatH Hotel
|
|
Reservation Service</a>
|
|
<br />
|
|
        2.1.2 <a href=
|
|
"#basics-getting-started">Defining a WSDL 2.0 Target Namespace</a>
|
|
<br />
|
|
            2.1.2.1
|
|
<a href="#example-empty-shell-explanation">Explanation of
|
|
Example</a>
|
|
<br />
|
|
        2.1.3 <a href=
|
|
"#basics-types">Defining Message Types</a>
|
|
<br />
|
|
            2.1.3.1
|
|
<a href="#example-initial-types-explanation">Explanation of
|
|
Example</a>
|
|
<br />
|
|
        2.1.4 <a href=
|
|
"#basics-interface">Defining an Interface</a>
|
|
<br />
|
|
            2.1.4.1
|
|
<a href="#example-initial-interface-explanation">Explanation of
|
|
Example</a>
|
|
<br />
|
|
        2.1.5 <a href=
|
|
"#basics-binding">Defining a Binding</a>
|
|
<br />
|
|
            2.1.5.1
|
|
<a href="#example-initial-binding-explanation">Explanation of
|
|
Example</a>
|
|
<br />
|
|
        2.1.6 <a href=
|
|
"#basics-service">Defining a Service</a>
|
|
<br />
|
|
            2.1.6.1
|
|
<a href="#example-initial-service-explanation">Explanation of
|
|
Example</a>
|
|
<br />
|
|
        2.1.7 <a href=
|
|
"#basics-documentation">Documenting the Service</a>
|
|
<br />
|
|
            2.1.7.1
|
|
<a href="#example-initial-documentation-explanation">Explanation of
|
|
Example</a>
|
|
<br />
|
|
    2.2 <a href="#wsdl-xml-representation">WSDL
|
|
2.0 Infoset, Schema and Component Model</a>
|
|
<br />
|
|
        2.2.1 <a href=
|
|
"#wsdl-infoset-diagram">WSDL 2.0 Infoset</a>
|
|
<br />
|
|
        2.2.2 <a href=
|
|
"#wsdl-schema">WSDL 2.0 Schema</a>
|
|
<br />
|
|
            2.2.2.1
|
|
<a href="#element-order">WSDL 2.0 Element Ordering</a>
|
|
<br />
|
|
        2.2.3 <a href=
|
|
"#component-model">WSDL 2.0 Component Model</a>
|
|
<br />
|
|
            2.2.3.1
|
|
<a href="#import-component">WSDL 2.0 Import and Include</a>
|
|
<br />
|
|
    2.3 <a href="#more-types">More on Message
|
|
Types</a>
|
|
<br />
|
|
        2.3.1 <a href=
|
|
"#more-types-schema-inline">Inlining XML Schema</a>
|
|
<br />
|
|
        2.3.2 <a href=
|
|
"#more-types-schema-import">Importing XML Schema</a>
|
|
<br />
|
|
        2.3.3 <a href=
|
|
"#more-types-import-include-summary">Summary of Import and Include
|
|
Mechanisms</a>
|
|
<br />
|
|
    2.4 <a href="#more-interfaces">More on
|
|
Interfaces</a>
|
|
<br />
|
|
        2.4.1 <a href=
|
|
"#more-interfaces-interfaces">Interface Syntax</a>
|
|
<br />
|
|
        2.4.2 <a href=
|
|
"#more-interfaces-inheritance">Interface Inheritance</a>
|
|
<br />
|
|
        2.4.3 <a href=
|
|
"#more-interfaces-faults">Interface Faults</a>
|
|
<br />
|
|
        2.4.4 <a href=
|
|
"#more-interfaces-operations">Interface Operations</a>
|
|
<br />
|
|
            2.4.4.1
|
|
<a href="#more-interfaces-op-attr">Operation Attributes</a>
|
|
<br />
|
|
            2.4.4.2
|
|
<a href="#id2295836">Operation Message References</a>
|
|
<br />
|
|
                2.4.4.2.1
|
|
<a href="#id2295901">The messageLabel Attribute</a>
|
|
<br />
|
|
                2.4.4.2.2
|
|
<a href="#id2295952">The element Attribute</a>
|
|
<br />
|
|
                2.4.4.2.3
|
|
<a href="#id2296126">Multiple infault or outfault Elements</a>
|
|
<br />
|
|
            2.4.4.3
|
|
<a href="#more-interfaces-meps">Understanding Message Exchange
|
|
Patterns (MEPs)</a>
|
|
<br />
|
|
    2.5 <a href="#more-bindings">More on
|
|
Bindings</a>
|
|
<br />
|
|
        2.5.1 <a href=
|
|
"#more-bindings-wsdl">Syntax Summary for Bindings</a>
|
|
<br />
|
|
        2.5.2 <a href=
|
|
"#more-bindings-reusable">Reusable Bindings</a>
|
|
<br />
|
|
        2.5.3 <a href=
|
|
"#more-bindings-faults">Binding Faults</a>
|
|
<br />
|
|
        2.5.4 <a href=
|
|
"#bindingOperations">Binding Operations</a>
|
|
<br />
|
|
        2.5.5 <a href=
|
|
"#more-bindings-soap">The SOAP Binding Extension</a>
|
|
<br />
|
|
            2.5.5.1
|
|
<a href="#more-bindings-soap-example-explanation">Explanation of
|
|
Example</a>
|
|
<br />
|
|
        2.5.6 <a href=
|
|
"#more-bindings-http">The HTTP Binding Extension</a>
|
|
<br />
|
|
            2.5.6.1
|
|
<a href="#id2297429">Explanation of Example</a>
|
|
<br />
|
|
        2.5.7 <a href=
|
|
"#adv-get-vs-post">HTTP GET Versus POST: Which to Use?</a>
|
|
<br />
|
|
3. <a href="#advanced-topic_ii">Advanced Topics I: Importing
|
|
Mechanisms</a>
|
|
<br />
|
|
    3.1 <a href=
|
|
"#adv-import-and-authoring">Importing WSDL</a>
|
|
<br />
|
|
    3.2 <a href=
|
|
"#adv-multiple-inline-schemas">Importing Schemas</a>
|
|
<br />
|
|
        3.2.1 <a href=
|
|
"#id2298427">Schemas in Imported Documents</a>
|
|
<br />
|
|
        3.2.2 <a href=
|
|
"#id2298802">Multiple Inline Schemas in One Document</a>
|
|
<br />
|
|
        3.2.3 <a href=
|
|
"#adv-schema-location">The schemaLocation Attribute</a>
|
|
<br />
|
|
            3.2.3.1
|
|
<a href="#id2299144">Using the id Attribute to Identify Inline
|
|
Schemas</a>
|
|
<br />
|
|
4. <a href="#advanced-topic_iii">Advanced Topics II: Extensibility
|
|
and Predefined Extensions</a>
|
|
<br />
|
|
    4.1 <a href=
|
|
"#adv-extensibility">Extensibility</a>
|
|
<br />
|
|
        4.1.1 <a href=
|
|
"#adv-optional-versus-required">Optional Versus Required
|
|
Extensions</a>
|
|
<br />
|
|
    4.2 <a href="#adv-MEP">Defining New
|
|
MEPs</a>
|
|
<br />
|
|
        4.2.1 <a href=
|
|
"#challenge-confirm">Confirmed Challenge</a>
|
|
<br />
|
|
    4.3 <a href="#adv-RPCstyle">RPC Style</a>
|
|
<br />
|
|
5. <a href="#advanced-topic_iv">Advanced Topics III:
|
|
Miscellaneous</a>
|
|
<br />
|
|
    5.1 <a href=
|
|
"#adv-message-dispatch">Enabling Easy Message Dispatch</a>
|
|
<br />
|
|
    5.2 <a href="#adv-versioning">Web Service
|
|
Versioning</a>
|
|
<br />
|
|
        5.2.1 <a href=
|
|
"#adv-versioning-compatible-evolution">Compatible Evolution</a>
|
|
<br />
|
|
        5.2.2 <a href=
|
|
"#adv-versioning-big-bang">Big Bang</a>
|
|
<br />
|
|
        5.2.3 <a href=
|
|
"#ad-versioing-migration">Evolving a Service</a>
|
|
<br />
|
|
        5.2.4 <a href=
|
|
"#adv-versioning-combined">Combined Approaches</a>
|
|
<br />
|
|
        5.2.5 <a href=
|
|
"#adv-versioning-examples">Examples of Versioning and Extending a
|
|
Service</a>
|
|
<br />
|
|
            5.2.5.1
|
|
<a href="#id2301152">Additional Optional Elements Added in
|
|
Content</a>
|
|
<br />
|
|
            5.2.5.2
|
|
<a href="#id2301217">Additional Optional Elements Added to a
|
|
Header</a>
|
|
<br />
|
|
            5.2.5.3
|
|
<a href="#id2301271">Additional Mandatory Elements in Content</a>
|
|
<br />
|
|
            5.2.5.4
|
|
<a href="#id2301354">Additional Optional Operation Added to
|
|
Interface</a>
|
|
<br />
|
|
            5.2.5.5
|
|
<a href="#id2301385">Additional Mandatory Operation Added to
|
|
Interface</a>
|
|
<br />
|
|
            5.2.5.6
|
|
<a href="#id2301454">Indicating Incompatibility by Changing the
|
|
Endpoint URI</a>
|
|
<br />
|
|
            5.2.5.7
|
|
<a href="#id2301490">Indicating Incompatibility by Changing the
|
|
SOAP Action</a>
|
|
<br />
|
|
            5.2.5.8
|
|
<a href="#id2301552">Indicating Incompatibility by Changing the
|
|
Element Content</a>
|
|
<br />
|
|
    5.3 <a href=
|
|
"#adv-service-references">Describing Web Service Messages That
|
|
Refer to Other Web Services</a>
|
|
<br />
|
|
        5.3.1 <a href=
|
|
"#reservationDetails">The Reservation Details Web Service</a>
|
|
<br />
|
|
        5.3.2 <a href=
|
|
"#reservationList">The Reservation List Web Service</a>
|
|
<br />
|
|
        5.3.3 <a href=
|
|
"#reservationDetails_HTTP">Reservation Details Web Service Using
|
|
HTTP Transfer</a>
|
|
<br />
|
|
        5.3.4 <a href=
|
|
"#reservationList_HTTP_GET">Reservation List Web Service Using HTTP
|
|
GET</a>
|
|
<br />
|
|
    5.4 <a href=
|
|
"#adv-multiple-docs-describing-same-service">Multiple Interfaces
|
|
for the Same Service</a>
|
|
<br />
|
|
    5.5 <a href="#adv-rdf-mapping">Mapping to
|
|
RDF and Semantic Web</a>
|
|
<br />
|
|
        5.5.1 <a href=
|
|
"#adv-rdf-rep-wsdl">RDF Representation of WSDL 2.0</a>
|
|
<br />
|
|
    5.6 <a href="#adv-notes-on-uris">Notes on
|
|
URIs</a>
|
|
<br />
|
|
        5.6.1 <a href=
|
|
"#adv-namespaces-and-schema-locations">XML Namespaces and Schema
|
|
Locations</a>
|
|
<br />
|
|
        5.6.2 <a href=
|
|
"#adv-relative-uris">Relative URIs</a>
|
|
<br />
|
|
        5.6.3 <a href=
|
|
"#adv-generating-uris">Generating Temporary URIs</a>
|
|
<br />
|
|
6. <a href="#References">References</a>
|
|
<br />
|
|
    6.1 <a href=
|
|
"#Normative-References">Normative References</a>
|
|
<br />
|
|
    6.2 <a href=
|
|
"#Informative-References">Informative References</a>
|
|
<br /></p>
|
|
<h3><a name="appendices" id="appendices"></a>Appendix</h3>
|
|
<p class="toc">A. <a href="#acknowledgments">Acknowledgements</a>
|
|
(Non-Normative)
|
|
<br /></p>
|
|
</div>
|
|
<hr />
|
|
<div class="body">
|
|
<div class="div1">
|
|
<h2><a name="Introduction" id="Introduction"></a>1.
|
|
Introduction</h2>
|
|
<div class="div2">
|
|
<h3><a name="Prerequisites" id="Prerequisites"></a>1.1
|
|
Prerequisites</h3>
|
|
<p>This primer assumes that the reader has the following
|
|
prerequisite knowledge:</p>
|
|
<ul>
|
|
<li>
|
|
<p>familiarity with XML (<em>Extensible Markup Language (XML)
|
|
1.0</em> [<cite><a href="#XML10">XML 1.0</a></cite>], <em>XML
|
|
Information Set</em> [<cite><a href="#XMLInfoSet">XML Information
|
|
Set</a></cite>]) and XML Namespaces (<em>Namespaces in XML</em>
|
|
[<cite><a href="#XMLNS">XML Namespaces</a></cite>]);</p>
|
|
</li>
|
|
<li>
|
|
<p>some familiarity with XML Schema (<em>XML Schema Part 1:
|
|
Structures</em> [<cite><a href="#XMLSchemaP1">XML Schema
|
|
Structures</a></cite>] <em>XML Schema Part 2: Datatypes</em>
|
|
[<cite><a href="#XMLSchemaP2">XML Schema
|
|
Datatypes</a></cite>]);</p>
|
|
</li>
|
|
<li>
|
|
<p>familiarity with basic Web services concepts such as Web
|
|
service, client, and the purpose and function of a Web service
|
|
description. (For an explanation of basic Web services concepts,
|
|
see <em>Web Services Architecture</em> [<cite><a href="#wsarch">WS
|
|
Architecture</a></cite>] <a href=
|
|
"http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#whatis">Section
|
|
1.4</a> and <em>Web Services Glossary</em> [<cite><a href=
|
|
"#WSAGLOSS">WS Glossary</a></cite>] <a href=
|
|
"http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/">glossary</a>.
|
|
However, note the <em>Web Services Architecture</em> document uses
|
|
the slightly more precise terms "<a href=
|
|
"http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#requesteragent">requester
|
|
agent</a>" and "<a href=
|
|
"http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#provideragent">provider
|
|
agent</a>" instead of the terms "client" and "Web service" used in
|
|
this primer.)</p>
|
|
</li>
|
|
</ul>
|
|
No previous experience with WSDL is assumed.</div>
|
|
<div class="div2">
|
|
<h3><a name="PrimerStructure" id="PrimerStructure"></a>1.2
|
|
Structure of this Primer</h3>
|
|
<p>Section 2 starts with a hypothetical use case involving a hotel
|
|
reservation service. It proceeds step-by-step through the
|
|
development of a simple example WSDL 2.0 document that describes
|
|
this service:</p>
|
|
<ul>
|
|
<li>
|
|
<p>The <code>types</code> element describes the kinds of messages
|
|
that the service will send and receive.</p>
|
|
</li>
|
|
<li>
|
|
<p>The <code>interface</code> element describes <em>what</em>
|
|
abstract functionality the Web service provides.</p>
|
|
</li>
|
|
<li>
|
|
<p>The <code>binding</code> element describes <em>how</em> to
|
|
access the service.</p>
|
|
</li>
|
|
<li>
|
|
<p>The <code>service</code> element describes <em>where</em> to
|
|
access the service.</p>
|
|
</li>
|
|
</ul>
|
|
<p>After presenting the example, it moves on to introduce the WSDL
|
|
2.0 infoset, schema, and component model. Then it provides more
|
|
detailed coverage on defining message types, interfaces, bindings,
|
|
and services.</p>
|
|
<p>Section 3 explains the WSDL 2.0 importing mechanisms in great
|
|
details.</p>
|
|
<p>Section 4 talks about WSDL 2.0 extensibility and various
|
|
predefined extensions.</p>
|
|
<p>Section 5 covers various topics that may fall outside the scope
|
|
of WSDL 2.0, but shall provide useful background and best practice
|
|
guidances that may be useful when authoring a WSDL 2.0 document or
|
|
implementing the WSDL 2.0 specification.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="UseIRI" id="UseIRI"></a>1.3 Use of URIs and IRIs</h3>
|
|
<p>The core specification of WSDL 2.0 supports Internationalized
|
|
Resource Identifiers or IRIs [<cite><a href="#RFC3987">IETF RFC
|
|
3987</a></cite>]. IRIs are a superset of URIs with added support
|
|
for internationalization. The URI syntax [<cite><a href=
|
|
"#RFC3986">IETF RFC 3986</a></cite>] only allows the use of a small
|
|
set of characters, including upper and lower case letters of the
|
|
English alphabet, European numerals and a few symbols. IRIs allow
|
|
the use of characters from a wider range of language scripts.</p>
|
|
<p>For simplicity, examples throughout this primer only use URIs.
|
|
If you are interested in learning more about the use of IRIs, you
|
|
might care to read the <a href=
|
|
"http://www.w3.org/International/articles/idn-and-iri/">paper</a>
|
|
prepared by the <a href="http://www.w3.org/International/">W3C
|
|
Internationalization Activity</a>.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="notation" id="notation"></a>1.4 Notational
|
|
Conventions</h3>
|
|
<p>This document uses several XML namespaces, some of which are
|
|
defined by standards, and some are application-specific. Namespace
|
|
names of the general form "http://greath.example.com/..." represent
|
|
application or context-dependent URIs [<cite><a href=
|
|
"#RFC3986">IETF RFC 3986</a></cite>].Note also that the choice of
|
|
any namespace prefix is arbitrary and not semantically significant
|
|
(see [<cite><a href="#XMLInfoSet">XML Information
|
|
Set</a></cite>]).</p>
|
|
<p>Following the convention for XML syntax summary in
|
|
[<cite><a href="#WSDL-PART1">WSDL 2.0 Core</a></cite>], this primer
|
|
uses an informal syntax to describe the XML grammar of a WSDL 2.0
|
|
document:</p>
|
|
<ul>
|
|
<li>
|
|
<p>The syntax appears as an XML instance, but the values indicate
|
|
the data types instead of values.</p>
|
|
</li>
|
|
<li>
|
|
<p>Characters are appended to elements and attributes as follows:
|
|
"?" (0 or 1), "*" (0 or more), "+" (1 or more).</p>
|
|
</li>
|
|
<li>
|
|
<p>Elements names ending in "…" indicate that elements/attributes
|
|
irrelevant to the context are being omitted.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="basics" id="basics"></a>2. WSDL 2.0 Basics</h2>
|
|
<div class="div2">
|
|
<h3><a name="basic-example" id="basic-example"></a>2.1 Getting
|
|
Started: The GreatH Hotel Example</h3>
|
|
<p>This section introduces the basic concepts used in WSDL 2.0
|
|
through the description of a hypothetical hotel reservation
|
|
service. We start with a simple scenario, and later add more
|
|
requirements to illustrate how more advanced WSDL 2.0 features may
|
|
be used.</p>
|
|
<div class="div3">
|
|
<h4><a name="basics-greath-scenario" id=
|
|
"basics-greath-scenario"></a>2.1.1 Example Scenario: The GreatH
|
|
Hotel Reservation Service</h4>
|
|
<p>Hotel GreatH (a fictional hotel) is located in a remote island.
|
|
It has been relying on fax and phone to provide room reservations.
|
|
Even though the facilities and prices at GreatH are better than
|
|
what its competitor offers, GreatH notices that its competitor is
|
|
getting more customers than GreatH. After research, GreatH realizes
|
|
that this is because the competitor offers a Web service that
|
|
permits travel agent reservation systems to reserve rooms directly
|
|
over the Internet. GreatH then hires us to build a reservation Web
|
|
service with the following functionality:</p>
|
|
<ul>
|
|
<li>
|
|
<p><em>CheckAvailability</em>. To check availability, the client
|
|
must specify a check-in date, a check-out date, and room type. The
|
|
Web service will return a room rate (a floating point number in
|
|
USD) if such a room is available, or a zero room rate if not. If
|
|
any input data is invalid, the service should return an error.
|
|
Thus, the service will accept a <code>checkAvailability</code>
|
|
message and return a <code>checkAvailabilityResponse</code> or
|
|
<code>invalidDataFault</code> message.</p>
|
|
</li>
|
|
<li>
|
|
<p><em>MakeReservation</em>. To make a reservation, a client must
|
|
provide a name, address, and credit card information, and the
|
|
service will return a confirmation number if the reservation is
|
|
successful. The service will return an error message if the credit
|
|
card number or any other data field is invalid. Thus, the service
|
|
will accept a <code>makeReservation</code> message and return a
|
|
<code>makeReservationResponse</code> or
|
|
<code>invalidCreditCardFault</code> message.</p>
|
|
</li>
|
|
</ul>
|
|
We know that we will later need to build a complete system that
|
|
supports transactions and secured transmission, but initially we
|
|
will implement only minimal functionality. In fact, to simplify our
|
|
first example, we will implement only the
|
|
<em>CheckAvailability</em> operation.
|
|
<p>The next several sections proceed step-by-step through the
|
|
process of developing a WSDL 2.0 document that describes the
|
|
desired Web service. However, for those who can't wait to see a
|
|
complete example, here is the WSDL 2.0 document that we'll be
|
|
creating.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-initial" id="example-initial"></a><em><span>Example
|
|
2-1.</span> WSDL 2.0 Document for the GreatH Web Service (Initial
|
|
Example)</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description
|
|
xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
|
|
xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
|
|
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
|
|
xmlns:wsdlx= "http://www.w3.org/ns/wsdl-extensions">
|
|
|
|
<documentation>
|
|
This document describes the GreatH Web service. Additional
|
|
application-level requirements for use of this service --
|
|
beyond what WSDL 2.0 is able to describe -- are available
|
|
at http://greath.example.com/2004/reservation-documentation.html
|
|
</documentation>
|
|
|
|
<types>
|
|
<xs:schema
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://greath.example.com/2004/schemas/resSvc"
|
|
xmlns="http://greath.example.com/2004/schemas/resSvc">
|
|
|
|
<xs:element name="checkAvailability" type="tCheckAvailability"/>
|
|
<xs:complexType name="tCheckAvailability">
|
|
<xs:sequence>
|
|
<xs:element name="checkInDate" type="xs:date"/>
|
|
<xs:element name="checkOutDate" type="xs:date"/>
|
|
<xs:element name="roomType" type="xs:string"/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
|
|
<xs:element name="checkAvailabilityResponse" type="xs:double"/>
|
|
|
|
<xs:element name="invalidDataError" type="xs:string"/>
|
|
|
|
</xs:schema>
|
|
</types>
|
|
|
|
<interface name = "reservationInterface" >
|
|
|
|
<fault name = "invalidDataFault"
|
|
element = "ghns:invalidDataError"/>
|
|
|
|
<operation name="opCheckAvailability"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out"
|
|
style="http://www.w3.org/ns/wsdl/style/iri"
|
|
wsdlx:safe = "true">
|
|
<input messageLabel="In"
|
|
element="ghns:checkAvailability" />
|
|
<output messageLabel="Out"
|
|
element="ghns:checkAvailabilityResponse" />
|
|
<outfault ref="tns:invalidDataFault" messageLabel="Out"/>
|
|
</operation>
|
|
|
|
</interface>
|
|
|
|
<binding name="reservationSOAPBinding"
|
|
interface="tns:reservationInterface"
|
|
type="http://www.w3.org/ns/wsdl/soap"
|
|
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
|
|
|
|
<fault ref="tns:invalidDataFault"
|
|
wsoap:code="soap:Sender"/>
|
|
|
|
<operation ref="tns:opCheckAvailability"
|
|
wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
|
|
|
|
</binding>
|
|
|
|
<service name="reservationService"
|
|
interface="tns:reservationInterface">
|
|
|
|
<endpoint name="reservationEndpoint"
|
|
binding="tns:reservationSOAPBinding"
|
|
address ="http://greath.example.com/2004/reservation"/>
|
|
|
|
</service>
|
|
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="basics-getting-started" id=
|
|
"basics-getting-started"></a>2.1.2 Defining a WSDL 2.0 Target
|
|
Namespace</h4>
|
|
<p>Before writing our WSDL 2.0 document, we need to decide on a
|
|
<em>WSDL 2.0 target namespace</em> URI for it. The WSDL 2.0 target
|
|
namespace is analogous to an XML Schema target namespace.
|
|
Interface, binding and service names that we define in our WSDL 2.0
|
|
document will be associated with the WSDL 2.0 target namespace, and
|
|
thus will be distinguishable from similar names in a different WSDL
|
|
2.0 target namespace. (This will become important if using WSDL
|
|
2.0's import or interface inheritance mechanisms.)</p>
|
|
<p>The value of the WSDL 2.0 target namespace must be an absolute
|
|
URI. Furthermore, it should be dereferenceable to a WSDL 2.0
|
|
document that describes the Web service that the WSDL 2.0 target
|
|
namespace is used to describe. For example, the GreatH owners
|
|
should make the WSDL 2.0 document available from this URI. (And if
|
|
a WSDL 2.0 description is split into multiple documents, then the
|
|
WSDL 2.0 target namespace should resolve to a master document that
|
|
includes all the WSDL 2.0 documents needed for that service
|
|
description.) However, there is no absolute requirement for this
|
|
URI to be dereferenceable, so a WSDL 2.0 processor must not depend
|
|
on it being dereferenceable.</p>
|
|
<p>This recommendation may sound circular, but bear in mind that
|
|
the client might have obtained the WSDL 2.0 document from anywhere
|
|
-- not necessarily an authoritative source. But by dereferencing
|
|
the WSDL 2.0 target namespace URI, a user should be able to obtain
|
|
an authoritative version. Since GreatH will be the owner of the
|
|
service, the WSDL 2.0 target namespace URI should refer to a
|
|
location on the GreatH Web site or otherwise within its
|
|
control.</p>
|
|
<p>Once we have decided on a WSDL 2.0 target namespace URI, we can
|
|
begin our WSDL 2.0 document as the following empty shell.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-empty-shell" id=
|
|
"example-empty-shell"></a><em><span>Example 2-2.</span> An Initial
|
|
Empty WSDL 2.0 Document</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description
|
|
xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
|
|
. . . >
|
|
|
|
. . .
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="example-empty-shell-explanation" id=
|
|
"example-empty-shell-explanation"></a>2.1.2.1 Explanation of
|
|
Example</h5>
|
|
<dl>
|
|
<dt class="label"><code><description</code></dt>
|
|
<dd>
|
|
<p>Every WSDL 2.0 document has a <code>description</code> element
|
|
as its top-most element. This merely acts as a container for the
|
|
rest of the WSDL 2.0 document, and is used to declare namespaces
|
|
that will be used throughout the document.</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>xmlns="http://www.w3.org/ns/wsdl"</code></dt>
|
|
<dd>
|
|
<p>This is the XML namespace for WSDL 2.0 itself. We assign it as
|
|
the default namespace for this example by not defining a prefix for
|
|
it. In other words, any unprefixed elements in this example are
|
|
expected to be WSDL 2.0 elements (such as the
|
|
<code>description</code> element).</p>
|
|
</dd>
|
|
<dt class="label"><code>targetNamespace=
|
|
"http://greath.example.com/2004/wsdl/resSvc"</code></dt>
|
|
<dd>
|
|
<p>This defines the WSDL 2.0 target namespace that we have chosen
|
|
for the GreatH reservation service, as described above. Note that
|
|
this is not an actual XML namespace declaration. Rather, it is a
|
|
WSDL 2.0 attribute whose purpose is <em>analogous</em> to an XML
|
|
Schema target namespace.</p>
|
|
</dd>
|
|
<dt class="label"><code>xmlns:tns=
|
|
"http://greath.example.com/2004/wsdl/resSvc"</code></dt>
|
|
<dd>
|
|
<p>This is an actual XML namespace declaration for use in our
|
|
GreatH service description. Note that this is the same URI that was
|
|
specified above as the value of the <code>targetNamespace</code>
|
|
attribute. This will allow us later to use the <code>tns:</code>
|
|
prefix in QNames, to refer to the WSDL 2.0 target namespace of the
|
|
GreatH service. (For more on QNames see [<cite><a href="#XMLNS">XML
|
|
Namespaces</a></cite>] section 3 <a href=
|
|
"http://www.w3.org/TR/2006/REC-xml-names-20060816/#ns-qualnames">Qualified
|
|
Names</a>.)</p>
|
|
</dd>
|
|
</dl>
|
|
<p>Now we can start describing the GreatH service.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="basics-types" id="basics-types"></a>2.1.3 Defining
|
|
Message Types</h4>
|
|
<p>We know that the GreatH service will be sending and receiving
|
|
messages, so a good starting point in describing the service is to
|
|
define the message types that the service will use. We'll use XML
|
|
Schema to do so, because WSDL 2.0 processors are likely to support
|
|
XML Schema at a minimum. However, WSDL 2.0 does not prohibit the
|
|
use of some other schema definition language.</p>
|
|
<p>WSDL 2.0 allows message types to be defined directly within the
|
|
WSDL 2.0 document, inside the <code>types</code> element, which is
|
|
a child of the <code>description</code> element. (Later we'll see
|
|
how we can provide the type definitions in a separate document,
|
|
using XML Schema's <code>import</code> mechanism.) The following
|
|
schema defines <code>checkAvailability</code>,
|
|
<code>checkAvailabilityResponse</code> and
|
|
<code>invalidDataError</code> message types that we'll need.</p>
|
|
<p>In WSDL 2.0, all normal and fault message types must be defined
|
|
as single <em>elements</em> at the topmost level (though of course
|
|
each element may have any amount of substructure inside it). Thus,
|
|
a message type must not directly consist of a sequence of elements
|
|
or other complex type.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-initial-types" id=
|
|
"example-initial-types"></a><em><span>Example 2-3.</span> GreatH
|
|
Message Types</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description
|
|
xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
|
|
. . . >
|
|
|
|
...
|
|
|
|
<types>
|
|
<xs:schema
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://greath.example.com/2004/schemas/resSvc"
|
|
xmlns="http://greath.example.com/2004/schemas/resSvc">
|
|
|
|
<xs:element name="checkAvailability" type="tCheckAvailability"/>
|
|
<xs:complexType name="tCheckAvailability">
|
|
<xs:sequence>
|
|
<xs:element name="checkInDate" type="xs:date"/>
|
|
<xs:element name="checkOutDate" type="xs:date"/>
|
|
<xs:element name="roomType" type="xs:string"/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
|
|
<xs:element name="checkAvailabilityResponse" type="xs:double"/>
|
|
|
|
<xs:element name="invalidDataError" type="xs:string"/>
|
|
|
|
</xs:schema>
|
|
</types>
|
|
. . .
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="example-initial-types-explanation" id=
|
|
"example-initial-types-explanation"></a>2.1.3.1 Explanation of
|
|
Example</h5>
|
|
<dl>
|
|
<dt class="label"><code>xmlns:ghns =
|
|
"http://greath.example.com/2004/schemas/resSvc"</code></dt>
|
|
<dd>
|
|
<p>We've added another namespace declaration. The <code>ghns</code>
|
|
namespace prefix will allow us (later, when defining an interface)
|
|
to reference the XML Schema target namespace that we define for our
|
|
message types. Thus, the URI we specify must be the same as the URI
|
|
that we define as the target namespace of our XML Schema types
|
|
(below) -- <em>not</em> the target namespace of the WSDL 2.0
|
|
document itself.</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>targetNamespace="http://greath.example.com/2004/schemas/resSvc"</code></dt>
|
|
<dd>
|
|
<p>This is the XML Schema target namespace that we've created for
|
|
use by the GreatH reservation service. The
|
|
<code>checkAvailability</code>,
|
|
<code>checkAvailabilityResponse</code> and
|
|
<code>invalidDataError</code> element names will be associated with
|
|
this XML Schema target namespace.</p>
|
|
</dd>
|
|
<dt class="label"><code>checkAvailability</code>,
|
|
<code>checkAvailabilityResponse</code> and
|
|
<code>invalidDataError</code></dt>
|
|
<dd>
|
|
<p>These are the message types that we'll use. Note that these are
|
|
defined to be XML <em>elements</em>, as explained above.</p>
|
|
</dd>
|
|
</dl>
|
|
<p>Although we have defined several types, we have not yet
|
|
indicated which ones are to be used as message types for a Web
|
|
service. We'll do that in the next section.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="basics-interface" id="basics-interface"></a>2.1.4
|
|
Defining an Interface</h4>
|
|
<p>WSDL 2.0 enables one to separate the description of a Web
|
|
service's abstract functionality from the concrete details of how
|
|
and where that functionality is offered. This separation
|
|
facilitates different levels of reusability and distribution of
|
|
work in the lifecycle of a Web service and the WSDL 2.0 document
|
|
that describes it.</p>
|
|
<p>A WSDL 2.0 <code>interface</code> defines the abstract interface
|
|
of a Web service as a set of abstract <em>operations</em>, each
|
|
operation representing a simple interaction between the client and
|
|
the service. Each operation specifies the types of messages that
|
|
the service can send or receive as part of that operation. Each
|
|
operation also specifies a message exchange <em>pattern</em> that
|
|
indicates the sequence in which the associated messages are to be
|
|
transmitted between the parties. For example, the <em>in-out</em>
|
|
pattern (see <em>WSDL 2.0 Predefined Extensions</em>
|
|
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section
|
|
2.2.3 <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">In-Out</a>)
|
|
indicates that if the client sends a message <em>in</em> to the
|
|
service, the service will either send a reply message back
|
|
<em>out</em> to the client (in the normal case) or it will send a
|
|
fault message back to the client (in the case of an error). We will
|
|
explain more about message exchange <em>pattern</em>s in <a href=
|
|
"#more-interfaces-meps"><strong>2.4.4.3 Understanding Message
|
|
Exchange Patterns (MEPs)</strong></a></p>
|
|
<p>For the GreatH service, we will (initially) define an interface
|
|
containing a single operation, <code>opCheckAvailability</code>,
|
|
using the <code>checkAvailability</code> and
|
|
<code>checkAvailabilityResponse</code> message types that we
|
|
defined in the <code>types</code> section. We'll use the <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-out</a>
|
|
pattern for this operation, because this is the most natural way to
|
|
represent a simple request-response interaction. We could have
|
|
instead (for example) defined two separate operations using the
|
|
<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-only</a>
|
|
and <a href=
|
|
"http://www.w3.org/TR/2007/NOTE-wsdl20-additional-meps-20070626#out-only">
|
|
out-only</a> patterns (see <em>WSDL 2.0 Predefined Extensions</em>
|
|
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section
|
|
2.2.1 <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-only">In-Only</a>
|
|
and section 2.2.5 <a href=
|
|
"http://www.w3.org/TR/2007/NOTE-wsdl20-additional-meps-20070626#out-only">
|
|
Out-Only</a>), but that would just complicate matters for the
|
|
client, because we would then have to separately indicate to the
|
|
client developer that the two operations should be used together as
|
|
a request-response pair.</p>
|
|
<p>In addition to the normal input and output messages, we also
|
|
need to specify the fault message that we wish to use in the event
|
|
of an error. WSDL 2.0 permits fault messages to be declared within
|
|
the <code>interface</code> element in order to facilitate reuse of
|
|
faults across operations. If a fault occurs, it terminates whatever
|
|
message sequence was indicated by the message exchange pattern of
|
|
the operation.</p>
|
|
<p>Let's add these to our WSDL 2.0 document.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-initial-interface" id=
|
|
"example-initial-interface"></a><em><span>Example 2-4.</span>
|
|
GreatH Interface Definition</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description
|
|
xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
|
|
. . .
|
|
xmlns:wsdlx="http://www.w3.org/ns/wsdl-extensions">
|
|
|
|
. . .
|
|
<types>
|
|
...
|
|
</types>
|
|
|
|
<interface name = "reservationInterface" >
|
|
|
|
<fault name = "invalidDataFault"
|
|
element = "ghns:invalidDataError"/>
|
|
|
|
<operation name="opCheckAvailability"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out"
|
|
style="http://www.w3.org/ns/wsdl/style/iri"
|
|
wsdlx:safe = "true">
|
|
<input messageLabel="In"
|
|
element="ghns:checkAvailability" />
|
|
<output messageLabel="Out"
|
|
element="ghns:checkAvailabilityResponse" />
|
|
<outfault ref="tns:invalidDataFault" messageLabel="Out"/>
|
|
</operation>
|
|
|
|
</interface>
|
|
|
|
. . .
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="example-initial-interface-explanation" id=
|
|
"example-initial-interface-explanation"></a>2.1.4.1 Explanation of
|
|
Example</h5>
|
|
<dl>
|
|
<dt class="label"><code><interface name = "reservationInterface"
|
|
></code></dt>
|
|
<dd>
|
|
<p>Interfaces are declared directly inside the
|
|
<code>description</code> element. In this example, we are declaring
|
|
only one interface, but in general a WSDL 2.0 document may declare
|
|
more than one interface. Thus, each interface must be given a name
|
|
that is unique within the set of interfaces defined in this WSDL
|
|
2.0 target namespace. Interface names are tokens that must not
|
|
contain a space or colon (":").</p>
|
|
</dd>
|
|
<dt class="label"><code><fault name =
|
|
"invalidDataFault"</code></dt>
|
|
<dd>
|
|
<p>The <code>name</code> attribute defines a name for this fault.
|
|
The name is required so that when an operation is defined, it can
|
|
reference the desired fault by name. Fault names must be unique
|
|
within an interface.</p>
|
|
</dd>
|
|
<dt class="label"><code>element =
|
|
"ghns:invalidDataError"/></code></dt>
|
|
<dd>
|
|
<p>The <code>element</code> attribute specifies the schema type of
|
|
the fault message, as previously defined in the <code>types</code>
|
|
section.</p>
|
|
</dd>
|
|
<dt class="label"><code><operation
|
|
name="opCheckAvailability"</code></dt>
|
|
<dd>
|
|
<p>The <code>name</code> attribute defines a name for this
|
|
operation, so that it can be referenced later when bindings are
|
|
defined. Operation names must also be unique within an interface.
|
|
(WSDL 2.0 uses separate symbol spaces for operation and fault
|
|
names, so operation name "foo" is distinct from fault name
|
|
"foo".)</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>pattern="http://www.w3.org/ns/wsdl/in-out"</code></dt>
|
|
<dd>
|
|
<p>This line specifies that this operation will use the <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-out</a>
|
|
pattern as described above. WSDL 2.0 uses URIs to identify message
|
|
exchange patterns in order to ensure that the identifiers are
|
|
globally unambiguous, while also permitting future new patterns to
|
|
be defined by anyone. (However, just because someone defines a new
|
|
pattern and creates a URI to identify it, that does <em>not</em>
|
|
mean that other WSDL 2.0 processors will automatically recognize or
|
|
understand that pattern. As with any other extension, it can only
|
|
be used among processors that <em>do</em> recognize and understand
|
|
it.)</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>style="http://www.w3.org/ns/wsdl/style/iri"</code></dt>
|
|
<dd>
|
|
<p>This line indicates that the XML schema defining the input
|
|
message of this operation follows a set of rules as specified in
|
|
<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#_operation_iri_style">
|
|
IRI Style</a> that ensures the message can be serialized as an
|
|
IRI.</p>
|
|
</dd>
|
|
<dt class="label"><code>wsdlx:safe="true" ></code></dt>
|
|
<dd>
|
|
<p>This line indicates that this operation will not obligate the
|
|
client in any way, i.e., the client can safely invoke this
|
|
operation without fear that it may be incurring an obligation (such
|
|
as agreeing to buy something). This is further explained in
|
|
<a href="#more-interfaces-operations"><strong>2.4.4 Interface
|
|
Operations</strong></a>.</p>
|
|
</dd>
|
|
<dt class="label"><code><input messageLabel="In"</code></dt>
|
|
<dd>
|
|
<p>The <code>input</code> element specifies an input message. Even
|
|
though we have already specified which message exchange pattern the
|
|
operation will use, a message exchange pattern represents a
|
|
template for a message sequence, and in theory could consist of
|
|
multiple input and/or output messages. Thus we must also indicate
|
|
which potential input message in the pattern this particular input
|
|
message represents. This is the purpose of the
|
|
<code>messageLabel</code> attribute. Since the <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-out</a>
|
|
pattern that we've chosen to use only has one input message, it is
|
|
trivial in this case: we simply fill in the message label "In" that
|
|
was defined in <em>WSDL 2.0 Predefined Extensions</em>
|
|
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section
|
|
2.2.3 <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">In-Out</a>
|
|
for the <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-out</a>
|
|
pattern. However, if a new pattern is defined that involve multiple
|
|
input messages, then the different input messages in the pattern
|
|
could then be distinguished by using different labels.</p>
|
|
</dd>
|
|
<dt class="label"><code>element="ghns:checkAvailability"
|
|
/></code></dt>
|
|
<dd>
|
|
<p>This specifies the message type for this input message, as
|
|
defined previously in the <code>types</code> section.</p>
|
|
</dd>
|
|
<dt class="label"><code><output messageLabel="Out" . .
|
|
.</code></dt>
|
|
<dd>
|
|
<p>This is similar to defining an input message.</p>
|
|
</dd>
|
|
<dt class="label"><code><outfault ref="tns:invalidDataFault"
|
|
messageLabel="Out"/></code></dt>
|
|
<dd>
|
|
<p>This associates an output fault with this operation. Faults are
|
|
declared a little differently than normal messages. The
|
|
<code>ref</code> attribute refers to the name of a previously
|
|
defined fault in this interface -- not a message schema type
|
|
directly. Since message exchange patterns could in general involve
|
|
a sequence of several messages, a fault could potentially occur at
|
|
various points within the message sequence. Because one may wish to
|
|
associate a different fault with each permitted point in the
|
|
sequence, the <code>messageLabel</code> is used to indicate the
|
|
desired point for this particular fault. It does so indirectly by
|
|
specifying the message that will either trigger this fault or that
|
|
this fault will replace, depending on the pattern. (Some patterns
|
|
use a <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#fault-trigger">
|
|
message-triggers-fault rule</a>; others use a <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#fault-replacement">
|
|
fault-replaces-message</a> rule. See <em>WSDL 2.0 Predefined
|
|
Extensions</em> [<cite><a href="#WSDL-PART2">WSDL 2.0
|
|
Adjuncts</a></cite>] section 2.1.2 <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#fault-trigger">
|
|
Message Triggers Fault</a> and section 2.1.1 <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#fault-replacement">
|
|
Fault Replaces Message</a>.)</p>
|
|
</dd>
|
|
</dl>
|
|
<p>Now that we've defined the abstract interface for the GreatH
|
|
service, we're ready to define a binding for it.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="basics-binding" id="basics-binding"></a>2.1.5 Defining
|
|
a Binding</h4>
|
|
<p>Although we have specified <em>what</em> abstract messages can
|
|
be exchanged with the GreatH Web service, we have not yet specified
|
|
<em>how</em> those messages can be exchanged. This is the purpose
|
|
of a <em>binding</em>. A binding specifies concrete message format
|
|
and transmission protocol details for an interface, and must supply
|
|
such details for every operation and fault in the interface.</p>
|
|
<p>In the general case, binding details for each operation and
|
|
fault are specified using <code>operation</code> and
|
|
<code>fault</code> elements inside a <code>binding</code> element,
|
|
as shown in the example below. However, in some cases it is
|
|
possible to use defaulting rules to supply the information. The
|
|
WSDL 2.0 SOAP binding extension, for example, defines some
|
|
defaulting rules for operations. (See <em>Web Services Description
|
|
Language (WSDL) Version 2.0 Part 2: Adjuncts</em> [<cite><a href=
|
|
"#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>], <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#soap-defaults">
|
|
Default Binding Rules</a>.)</p>
|
|
<p>In order to accommodate new kinds of message formats and
|
|
transmission protocols, bindings are defined using extensions to
|
|
the WSDL 2.0 language, via WSDL 2.0's open content model. (See
|
|
<a href="#adv-extensibility"><strong>4.1 Extensibility</strong></a>
|
|
for more on extensibility.) WSDL 2.0 Part 2 [<cite><a href=
|
|
"#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] defines binding
|
|
extensions for SOAP 1.2 [<cite><a href="#SOAP12-PART1">SOAP 1.2
|
|
Part 1: Messaging Framework</a></cite>] and HTTP 1.1
|
|
[<cite><a href="#RFC2616">IETF RFC 2616</a></cite>] as predefined
|
|
extensions, so that SOAP 1.2 or HTTP 1.1 bindings can be easily
|
|
defined in WSDL 2.0 documents. However, other specifications could
|
|
define new binding extensions that could also be used to define
|
|
bindings. (As with any extension, other WSDL 2.0 processors would
|
|
have to know about the new constructs in order to make use of
|
|
them.)</p>
|
|
<p>For the GreatH service, we will use SOAP 1.2 as our concrete
|
|
message format and HTTP as our underlying transmission protocol, as
|
|
shown below.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-initial-binding" id=
|
|
"example-initial-binding"></a><em><span>Example 2-5.</span> GreatH
|
|
Binding Definition</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description
|
|
xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
|
|
xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
|
|
xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
|
|
. . .
|
|
|
|
<types>
|
|
. . .
|
|
</types>
|
|
|
|
<interface name = "reservationInterface" >
|
|
...
|
|
</interface>
|
|
|
|
<binding name="reservationSOAPBinding"
|
|
interface="tns:reservationInterface"
|
|
type="http://www.w3.org/ns/wsdl/soap"
|
|
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
|
|
|
|
<operation ref="tns:opCheckAvailability"
|
|
wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
|
|
|
|
<fault ref="tns:invalidDataFault"
|
|
wsoap:code="soap:Sender"/>
|
|
|
|
</binding>
|
|
|
|
. . .
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="example-initial-binding-explanation" id=
|
|
"example-initial-binding-explanation"></a>2.1.5.1 Explanation of
|
|
Example</h5>
|
|
<dl>
|
|
<dt class="label"><code>xmlns:wsoap=
|
|
"http://www.w3.org/ns/wsdl/soap"</code></dt>
|
|
<dd>
|
|
<p>We've added two more namespace declarations. This one is the
|
|
namespace for the SOAP 1.2 binding extension that is defined in
|
|
WSDL 2.0 Part 3 [<cite><a href="#SOAP12-PART1">SOAP 1.2 Part 1:
|
|
Messaging Framework</a></cite>]. Elements and attributes prefixed
|
|
with <code>wsoap:</code> are constructs defined there.</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>xmlns:soap="http://www.w3.org/2003/05/soap-envelope"</code></dt>
|
|
<dd>
|
|
<p>This namespace is defined by the SOAP 1.2 specification itself.
|
|
The SOAP 1.2 specification defines certain terms within this
|
|
namespace to unambiguously identify particular concepts. Thus, we
|
|
will use the <code>soap:</code> prefix when we need to refer to one
|
|
of those terms.</p>
|
|
</dd>
|
|
<dt class="label"><code><binding
|
|
name="reservationSOAPBinding"</code></dt>
|
|
<dd>
|
|
<p>Bindings are declared directly inside the
|
|
<code>description</code> element. The <code>name</code> attribute
|
|
defines a name for this binding. Each name must be unique among all
|
|
bindings in this WSDL 2.0 target namespace, and will be used later
|
|
when we define a service endpoint that references this binding.
|
|
WSDL 2.0 uses separate symbol spaces for interfaces, bindings and
|
|
services, so interface "foo", binding "foo" and service "foo" are
|
|
all distinct.</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>interface="tns:reservationInterface"</code></dt>
|
|
<dd>
|
|
<p>This is the name of the interface whose message format and
|
|
transmission protocols we are specifying. As discussed in <a href=
|
|
"#more-bindings"><strong>2.5 More on Bindings</strong></a>, a
|
|
reusable binding can be defined by omitting the
|
|
<code>interface</code> attribute. Note also the use of the
|
|
<code>tns:</code> prefix, which refers to the previously defined
|
|
WSDL 2.0 target namespace for this WSDL 2.0 document. In this case
|
|
it may seem silly to have to specify the <code>tns:</code> prefix,
|
|
but in <a href="#adv-import-and-authoring"><strong>3.1 Importing
|
|
WSDL</strong></a> we will see how WSDL 2.0's import mechanism can
|
|
be used to combine components that are defined in different WSDL
|
|
2.0 target namespaces.</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>type="http://www.w3.org/ns/wsdl/soap"</code></dt>
|
|
<dd>
|
|
<p>This specifies what kind of concrete message format to use, in
|
|
this case SOAP 1.2.</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"</code></dt>
|
|
<dd>
|
|
<p>This attribute is specific to WSDL 2.0's SOAP binding extension
|
|
(thus it uses the <code>wsoap:</code> prefix). It specifies the
|
|
underlying transmission protocol that should be used, in this case
|
|
HTTP.</p>
|
|
</dd>
|
|
<dt class="label"><code><operation
|
|
ref="tns:opCheckAvailability"</code></dt>
|
|
<dd>
|
|
<p>This is not defining a new operation; rather, it is referencing
|
|
the previously defined <code>opCheckAvailability</code> operation
|
|
in order to specify binding details for it. This element can be
|
|
omitted if defaulting rules are instead used to supply the
|
|
necessary information. (See the SOAP binding extension in WSDL 2.0
|
|
Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]
|
|
section 4.3 <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#soap-defaults">
|
|
Default Binding Rules</a> .)</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"></code></dt>
|
|
<dd>
|
|
<p>This attribute is also specific to WSDL 2.0's SOAP binding
|
|
extension. It specifies the SOAP message exchange pattern (MEP)
|
|
that will be used to implement the abstract WSDL 2.0 message
|
|
exchange pattern (<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-out</a>)
|
|
that was specified when the <code>opCheckAvailability</code>
|
|
operation was defined.</p>
|
|
<p>When HTTP is used as the underlying transport protocol (as in
|
|
this example) the <code>wsoap:mep</code> attribute also controls
|
|
whether GET or POST will be used as the underlying HTTP method. In
|
|
this case, the use of
|
|
<code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"</code>
|
|
causes GET to be used by default. See also <a href=
|
|
"#adv-get-vs-post"><strong>2.5.7 HTTP GET Versus POST: Which to
|
|
Use?</strong></a>.</p>
|
|
</dd>
|
|
<dt class="label"><code><fault
|
|
ref="tns:invalidDataFault"</code></dt>
|
|
<dd>
|
|
<p>As with a binding operation, this is not declaring a new fault;
|
|
rather, it is referencing a fault (<code>invalidDataFault</code>)
|
|
that was previously defined in the <code>opCheckAvailability</code>
|
|
interface, in order to specify binding details for it.</p>
|
|
</dd>
|
|
<dt class="label"><code>wsoap:code="soap:Sender"/></code></dt>
|
|
<dd>
|
|
<p>This attribute is also specific to WSDL 2.0's SOAP binding
|
|
extension. This specifies the SOAP 1.2 fault code that will cause
|
|
this fault message to be sent. If desired, a list of subcodes can
|
|
also be specified using the optional <code>wsoap:subcodes</code>
|
|
attribute.</p>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="basics-service" id="basics-service"></a>2.1.6 Defining
|
|
a Service</h4>
|
|
<p>Now that our binding has specified <em>how</em> messages will be
|
|
transmitted, we are ready to specify <em>where</em> the service can
|
|
be accessed, by use of the <code>service</code> element.</p>
|
|
<p>A WSDL 2.0 <em>service</em> specifies a single interface that
|
|
the service will support, and a list of <em>endpoint</em> locations
|
|
where that service can be accessed. Each endpoint must also
|
|
reference a previously defined binding to indicate what protocols
|
|
and transmission formats are to be used at that endpoint. A service
|
|
is only permitted to have one interface. (See <a href=
|
|
"#adv-multiple-docs-describing-same-service"><strong>5.4 Multiple
|
|
Interfaces for the Same Service</strong></a> for further discussion
|
|
of this limitation.)</p>
|
|
<p>Here is a definition for our GreatH service.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-initial-service" id=
|
|
"example-initial-service"></a><em><span>Example 2-6.</span> GreatH
|
|
Service Definition</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description
|
|
xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
|
|
xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
|
|
xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
|
|
. . .
|
|
|
|
<types>
|
|
. . .
|
|
</types>
|
|
|
|
<interface name = "reservationInterface" >
|
|
. . .
|
|
</interface>
|
|
|
|
<binding name="reservationSOAPBinding"
|
|
interface="tns:reservationInterface"
|
|
. . . >
|
|
. . .
|
|
</binding>
|
|
|
|
<service name="reservationService"
|
|
interface="tns:reservationInterface">
|
|
|
|
<endpoint name="reservationEndpoint"
|
|
binding="tns:reservationSOAPBinding"
|
|
address ="http://greath.example.com/2004/reservation"/>
|
|
|
|
</service>
|
|
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="example-initial-service-explanation" id=
|
|
"example-initial-service-explanation"></a>2.1.6.1 Explanation of
|
|
Example</h5>
|
|
<dl>
|
|
<dt class="label"><code><service
|
|
name="reservationService"</code></dt>
|
|
<dd>
|
|
<p>This defines a name for this service, which must be unique among
|
|
service names in the WSDL 2.0 target namespace. The name attribute
|
|
is required. It allows URIs to be created that identify components
|
|
in WSDL 2.0 description. (See <em>WSDL 2.0 Core Language</em>
|
|
[<cite><a href="#WSDL-PART1">WSDL 2.0 Core</a></cite>] appendix C
|
|
<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626/#wsdl-iri-references">
|
|
IRI References for WSDL 2.0 constructs</a>.)</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>interface="tns:reservationInterface"></code></dt>
|
|
<dd>
|
|
<p>This specifies the name of the previously defined interface that
|
|
these service endpoints will support.</p>
|
|
</dd>
|
|
<dt class="label"><code><endpoint
|
|
name="reservationEndpoint"</code></dt>
|
|
<dd>
|
|
<p>This defines an endpoint for the service, and a name for this
|
|
endpoint, which must be unique within this service.</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>binding="tns:reservationSOAPBinding"</code></dt>
|
|
<dd>
|
|
<p>This specifies the name of the previously defined binding to be
|
|
used by this endpoint.</p>
|
|
</dd>
|
|
<dt class="label"><code>address
|
|
="http://greath.example.com/2004/reservation"/></code></dt>
|
|
<dd>
|
|
<p>This specifies the physical address at which this service can be
|
|
accessed using the binding specified by the <code>binding</code>
|
|
attribute.</p>
|
|
</dd>
|
|
</dl>
|
|
<p>That's it! Well, almost.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="basics-documentation" id=
|
|
"basics-documentation"></a>2.1.7 Documenting the Service</h4>
|
|
<p>As we have seen, a WSDL 2.0 document is inherently only a
|
|
<em>partial</em> description of a service. Although it captures the
|
|
basic mechanics of interacting with the service -- the message
|
|
types, transmission protocols, service location, etc. -- in
|
|
general, additional documentation will need to explain other
|
|
application-level requirements for its use. For example, such
|
|
documentation should explain the purpose and use of the service,
|
|
the meanings of all messages, constraints on their use, and the
|
|
sequence in which operations should be invoked.</p>
|
|
<p>The <code>documentation</code> element allows the WSDL 2.0
|
|
author to include some human-readable documentation inside a WSDL
|
|
2.0 document. It is also a convenient place to reference any
|
|
additional external documentation that a client developer may need
|
|
in order to use the service. It can appear in a number of places in
|
|
a WSDL 2.0 document (see <a href=
|
|
"#wsdl-infoset-diagram"><strong>2.2.1 WSDL 2.0
|
|
Infoset</strong></a>), though in this example we have only
|
|
demonstrated its use at the beginning.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-initial-documentation" id=
|
|
"example-initial-documentation"></a><em><span>Example 2-7.</span>
|
|
Documenting the GreatH Service</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description
|
|
. . . >
|
|
|
|
<documentation>
|
|
This document describes the GreatH Web service. Additional
|
|
application-level requirements for use of this service --
|
|
beyond what WSDL 2.0 is able to describe -- are available
|
|
at http://greath.example.com/2004/reservation-documentation.html
|
|
</documentation>
|
|
. . .
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="example-initial-documentation-explanation" id=
|
|
"example-initial-documentation-explanation"></a>2.1.7.1 Explanation
|
|
of Example</h5>
|
|
<dl>
|
|
<dt class="label"><code><documentation></code></dt>
|
|
<dd>
|
|
<p>This element is optional, but a good idea to include. It can
|
|
contain arbitrary mixed content.</p>
|
|
</dd>
|
|
<dt class="label"><code>at
|
|
http://greath.example.com/2004/reservation-documentation.html</code></dt>
|
|
<dd>
|
|
<p>The most important thing to include is a pointer to any
|
|
additional documentation that a client developer would need in
|
|
order to use the service.</p>
|
|
</dd>
|
|
</dl>
|
|
<p>This completes our presentation of the GreatH example. In the
|
|
following sections, we will move on to look into more details of
|
|
various aspects of WSDL 2.0 specification.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="wsdl-xml-representation" id=
|
|
"wsdl-xml-representation"></a>2.2 WSDL 2.0 Infoset, Schema and
|
|
Component Model</h3>
|
|
<p>In computer science theory, a language consists of a (possibly
|
|
infinite) set of sentences, and each sentence is a finite string of
|
|
literal symbols or characters. A language specification must
|
|
therefore define the set of sentences in that language, and, to be
|
|
useful, it should also indicate the meaning of each sentence.
|
|
Indeed, this is the purpose of the WSDL 2.0 specification.</p>
|
|
<p>However, instead of defining WSDL 2.0 in terms of literal
|
|
symbols or characters, to avoid dependency on any particular
|
|
character encoding, WSDL 2.0 is defined in terms of the <em>XML
|
|
Infoset</em> [<cite><a href="#XMLInfoSet">XML Information
|
|
Set</a></cite>]. Specifically, a <em>WSDL 2.0 document</em>
|
|
consists of a <code>description</code> element information item (in
|
|
the XML Infoset) that conforms to the WSDL 2.0 specification. In
|
|
other words, a sentence in the WSDL 2.0 language is a
|
|
<code>description</code> element information item that obeys the
|
|
additional constraints spelled out in the WSDL 2.0
|
|
specification.</p>
|
|
<p>Since an XML Infoset can be created from more than one physical
|
|
document, a WSDL 2.0 document does not necessarily correspond to a
|
|
single <em>physical</em> document: the word "document" is used
|
|
figuratively, for convenience. Furthermore, since WSDL 2.0 provides
|
|
<code>import</code> and <code>include</code> mechanisms, a WSDL 2.0
|
|
document may reference other WSDL 2.0 documents to facilitate
|
|
convenient organization or reuse. In such cases, the meaning of the
|
|
including or importing document as a whole will depend (in part) on
|
|
the meaning of the included or imported document.</p>
|
|
<p>The XML Infoset uses terms like "element information item" and
|
|
"attribute information item". Unfortunately, those terms are rather
|
|
lengthy to repeat often. Thus, for convenience, this primer often
|
|
uses the terms "element" and "attribute" instead, as a shorthand.
|
|
It should be understood, however, that since WSDL 2.0 is based on
|
|
the XML Infoset, we really mean "element information item" and
|
|
"attribute information item", respectively.</p>
|
|
<div class="div3">
|
|
<h4><a name="wsdl-infoset-diagram" id=
|
|
"wsdl-infoset-diagram"></a>2.2.1 WSDL 2.0 Infoset</h4>
|
|
<p>The following diagram gives an overview of the XML Infoset for a
|
|
WSDL 2.0 document.</p>
|
|
<div class="figure" style="text-align: center"><br />
|
|
<img src="images/WSDL20InfosetModel.png" alt=
|
|
"WSDL 2.0 Infoset Diagram" />
|
|
<p style="text-align:left"><em><span>Figure 2-1.</span> WSDL 2.0
|
|
Infoset Diagram</em></p>
|
|
|
|
<br /></div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="wsdl-schema" id="wsdl-schema"></a>2.2.2 WSDL 2.0
|
|
Schema</h4>
|
|
<p>The WSDL 2.0 specification supplies a <a href=
|
|
"http://www.w3.org/ns/wsdl">normative WSDL 2.0 schema</a>, defined
|
|
in [<cite><a href="#XMLSchemaP1">XML Schema Structures</a></cite>],
|
|
which can be used as an aid in validating WSDL 2.0 documents. We
|
|
say "as an aid" here because WSDL 2.0 specification [<cite><a href=
|
|
"#WSDL-PART1">WSDL 2.0 Core</a></cite>] often provides further
|
|
constraints to the WSDL 2.0 schema. In addition to being valid with
|
|
the normative schema, a WSDL 2.0 document must also follow all the
|
|
constraints defined by the WSDL 2.0 specification.</p>
|
|
<div class="div4">
|
|
<h5><a name="element-order" id="element-order"></a>2.2.2.1 WSDL 2.0
|
|
Element Ordering</h5>
|
|
<p>This section gives an example of how WSDL 2.0 specification
|
|
constrains the WSDL 2.0 schema about the ordering of top WSDL 2.0
|
|
elements.</p>
|
|
<p>Although the WSDL 2.0 schema does not indicate the required
|
|
ordering of elements, the WSDL 2.0 specification (WSDL 2.0 Part 1
|
|
[<cite><a href="#WSDL-PART1">WSDL 2.0 Core</a></cite>] section
|
|
"<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#Description_XMLRep">XML
|
|
Representation of Description Component</a>") clearly states a set
|
|
of constraints about how the child elements of the
|
|
<code>description</code> element should be ordered. Thus, the order
|
|
of the WSDL 2.0 elements matters, even though the WSDL 2.0 schema
|
|
does not capture this constraint.</p>
|
|
<p>The following is a pseudo-content model of
|
|
<code>description</code>.</p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<<strong>description</strong>>
|
|
<documentation />?
|
|
[ <import /> | <include /> ]*
|
|
<types />?
|
|
[ <interface /> | <binding /> | <service /> ]*
|
|
</<strong>description</strong>>
|
|
</pre></div>
|
|
<p>In other words, the children elements of the
|
|
<code>description</code> element should be ordered as follows:</p>
|
|
<ul>
|
|
<li>
|
|
<p>An optional <code>documentation</code> comes first, if
|
|
present.</p>
|
|
</li>
|
|
<li>
|
|
<p>then comes zero or more elements from among the following, in
|
|
any order:</p>
|
|
<ul>
|
|
<li>
|
|
<p><code>include</code></p>
|
|
</li>
|
|
<li>
|
|
<p><code>import</code></p>
|
|
</li>
|
|
<li>
|
|
<p>extensions</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<p>An optional <code>types</code> follows</p>
|
|
</li>
|
|
<li>
|
|
<p>Zero or more elements from among the following, in any
|
|
order:</p>
|
|
<ul>
|
|
<li>
|
|
<p><code>interface</code></p>
|
|
</li>
|
|
<li>
|
|
<p><code>binding</code></p>
|
|
</li>
|
|
<li>
|
|
<p><code>service</code></p>
|
|
</li>
|
|
<li>
|
|
<p>extensions.</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<p>Note the term "extension" is used above as a convenient way to
|
|
refer to namespace-qualified extension elements. The namespace name
|
|
of such extension elements must not
|
|
be"http://www.w3.org/ns/wsdl".</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="component-model" id="component-model"></a>2.2.3 WSDL
|
|
2.0 Component Model</h4>
|
|
<p>The WSDL 2.0 Infoset model above illustrates the required
|
|
structure of a WSDL 2.0 document, using the XML Infoset. However,
|
|
the WSDL 2.0 language also imposes many semantic constraints over
|
|
and above structural conformance to this XML Infoset. In order to
|
|
precisely describe these constraints, and as an aid in precisely
|
|
defining the meaning of each WSDL 2.0 document, the WSDL 2.0
|
|
specification defines a <em>component model</em> as an additional
|
|
layer of abstraction above the XML Infoset. Constraints and meaning
|
|
are defined in terms of this component model, and the definition of
|
|
each component includes a mapping that specifies how values in the
|
|
component model are derived from corresponding items in the XML
|
|
Infoset. The following diagram gives an overview of the WSDL 2.0
|
|
components and their containment hierarchy.</p>
|
|
<div class="figure" style="text-align: center"><br />
|
|
<img src="images/WSDL20Components.png" alt=
|
|
"WSDL 2.0 Components Containment hierarchy" />
|
|
<p style="text-align:left"><em><span>Figure 2-2.</span> WSDL 2.0
|
|
Components Containment hierarchy</em></p>
|
|
|
|
<br /></div>
|
|
<p>In general, the WSDL 2.0 component model parallels the structure
|
|
of the required XML Infoset illustrated above. For example, the
|
|
<em>Description</em>, <em>Interface</em>, <em>Binding</em>,
|
|
<em>Service</em> and <em>Endpoint</em> <em>components</em>
|
|
correspond to the <code>description</code>, <code>interface</code>,
|
|
<code>binding</code>, <code>service</code>, and
|
|
<code>endpoint</code> element information items, respectively.
|
|
Since WSDL 2.0 relies heavily on the component model to convey the
|
|
meaning of the constructs in the WSDL 2.0 language, you can think
|
|
of the Description component as representing the meaning of the
|
|
<code>description</code> element information item, and hence, it
|
|
represents the meaning of the WSDL 2.0 document as a whole.</p>
|
|
<p>Furthermore, each of these components has <em>properties</em>
|
|
whose values are (usually) derived from the element and attribute
|
|
information item children of those element information items. For
|
|
example, the Service component corresponds to the
|
|
<code>service</code> element information item, so the Service
|
|
component has an {endpoints} property whose value is a set of
|
|
Endpoint components corresponding to the <code>endpoint</code>
|
|
element information item children of that <code>service</code>
|
|
element information item. (Whew!)</p>
|
|
<div class="div4">
|
|
<h5><a name="import-component" id="import-component"></a>2.2.3.1
|
|
WSDL 2.0 Import and Include</h5>
|
|
<p>The WSDL 2.0 component model is particularly helpful in defining
|
|
the meaning of <code>import</code> and <code>include</code>
|
|
elements. The <code>include</code> element allows you to assemble
|
|
the contents of a given WSDL 2.0 namespace from several WSDL 2.0
|
|
documents that define components for that namespace. The components
|
|
defined by a given WSDL 2.0 document consist of those whose
|
|
definitions are contained in the document and those that are
|
|
defined by any WSDL 2.0 documents that are included in it via the
|
|
<code>include</code> element. The effect of the
|
|
<code>include</code> element is cumulative so that if document A
|
|
includes document B and document B includes document C, then the
|
|
components defined by document A consist of those whose definitions
|
|
are contained in documents A, B, and C.</p>
|
|
<p>In contrast, the <code>import</code> element does not define any
|
|
components. Instead, the <code>import</code> element declares that
|
|
the components whose definitions are contained in a WSDL 2.0
|
|
document for a given WSDL 2.0 namespace refer to components that
|
|
belong to a different WSDL 2.0 namespace. If a WSDL 2.0 document
|
|
contains definitions of components that refer to other namespaces,
|
|
then those namespaces must be declared via an <code>import</code>
|
|
element. The <code>import</code> element also has an optional
|
|
<code>location</code> attribute that is a hint to the processor
|
|
where the definitions of the imported namespace can be found.
|
|
However, the processor may find the definitions by other means, for
|
|
example, by using a catalog.</p>
|
|
<p>After processing any <code>include</code> elements and locating
|
|
the components that belong to any imported namespaces, the WSDL 2.0
|
|
component model for a WSDL 2.0 document will contain a set of
|
|
components that belong to the document's WSDL 2.0 namespace and any
|
|
imported namespaces. These components will refer to each other,
|
|
usually via QName references. A WSDL 2.0 document is invalid if any
|
|
component reference cannot be resolved, whether or not the
|
|
referenced component belongs to the same or a different
|
|
namespace.</p>
|
|
<p>We will cover a lot more about how to use WSDL 2.0 import and
|
|
include in <a href="#adv-import-and-authoring"><strong>3.1
|
|
Importing WSDL</strong></a></p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="more-types" id="more-types"></a>2.3 More on Message
|
|
Types</h3>
|
|
<p>Message types may be defined in various schema languages. In
|
|
this primer, we will only focus on the use of XML Schema
|
|
[<cite><a href="#XMLSchemaP1">XML Schema Structures</a></cite>]
|
|
since it's natively supported by WSDL 2.0. Message types defined in
|
|
other languages may be introduced into a WSDL 2.0
|
|
<code>description</code> via extensions, see the W3C notes
|
|
[<cite><a href="#altschemalangs">Alternative Schema Languages
|
|
Support</a></cite>] for more details.</p>
|
|
<p>The following is the XML syntax for the <code>wsdl:types</code>
|
|
element:</p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<description>
|
|
<<strong>types</strong>>
|
|
<documentation />*
|
|
[ <xs:import namespace="<em>xs:anyURI</em>" schemaLocation="<em>xs:anyURI</em>"? /> |
|
|
<xs:schema targetNamespace="<em>xs:anyURI</em>" /> |
|
|
<em>other extension elements</em> ]*
|
|
</<strong>types</strong>>
|
|
</description>
|
|
</pre></div>
|
|
<p>There are two ways to make XML Schema message definitions
|
|
visible, or in other words, available for reference by QName (see
|
|
WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0
|
|
Core</a></cite>] "<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#qnameres">QName
|
|
Resolution</a>") in a WSDL 2.0 document: inlining or importing.
|
|
Inlining is to put the schema definitions directly within an
|
|
<code>xs:schema</code> element under <code>types</code>. Importing
|
|
is to have the schema defined in a separate document and then bring
|
|
it into the WSDL definition by using <code>xs:import</code>
|
|
directly under <code>types</code>.</p>
|
|
<p>In the following sections, we will provide examples for the
|
|
different mechanisms.</p>
|
|
<div class="div3">
|
|
<h4><a name="more-types-schema-inline" id=
|
|
"more-types-schema-inline"></a>2.3.1 Inlining XML Schema</h4>
|
|
<p>We have already seen an example of using inlined schema
|
|
definitions in section <a href="#basics-types"><strong>2.1.3
|
|
Defining Message Types</strong></a>. When XML Schema is inlined
|
|
directly in a WSDL 2.0 document, it uses the existing top-level
|
|
<code>xs:schema</code> element defined by XML Schema to do so, as
|
|
though a schema file had been copied and pasted into the
|
|
<code>types</code> element. The schema components defined in the
|
|
inlined schema are then available to the containing WSDL 2.0
|
|
<code>description</code> for reference by QName. For instance, in
|
|
<a href="#example-initial">Example 2-1</a>, the input message of
|
|
the interface operation "opCheckAvailability" is defined by the
|
|
"ghns:checkAvailability" element in the inlined schema.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="more-types-schema-import" id=
|
|
"more-types-schema-import"></a>2.3.2 Importing XML Schema</h4>
|
|
<p>XML Schema components can be defined in separate schema files
|
|
and be made available to a WSDL2.0 <code>description</code> by
|
|
using <code>xs:import</code> directly under <code>types</code>.</p>
|
|
<p>There are many cases where one would prefer having schema
|
|
definitions in separate schema files. One reason is the reusability
|
|
of the schema definitions. Inlined schema definitions are only
|
|
available to the containing WSDL 2.0 <code>description</code>.
|
|
Although WSDL 2.0 provides a <code>wsdl:import</code> mechanism for
|
|
importing other WSDL files, schema definitions inlined in an
|
|
imported WSDL document are NOT automatically made available to the
|
|
importing WSDL 2.0 document, even though other WSDL 2.0 components
|
|
(such as Interfaces, Bindings, etc.) do become available.
|
|
Therefore, if one wishes to share schema definitions across several
|
|
WSDL 2.0 <code>description</code>s, these schema definitions should
|
|
instead be placed in separate XML Schema documents and imported
|
|
into each WSDL 2.0 <code>description</code> using
|
|
<code>xs:import</code> directly under <code>types</code>.</p>
|
|
<p>Let's see an example. Assuming the message types in <a href=
|
|
"#example-initial-types">Example 2-3</a> are defined in a separate
|
|
schema file named
|
|
"http://greath.example.com/2004/schemas/resSvc.xsd" with a target
|
|
namespace "http://greath.example.com/2004/schemas/resSvc", the
|
|
schema definition can then be brought into the WSDL 2.0
|
|
<code>description</code> using <code>xs:import</code>. Note that
|
|
only components in the imported namespace
|
|
"http://greath.example.com/2004/schemas/resSvc" are available for
|
|
reference in the WSDL 2.0 document.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-schema-import" id=
|
|
"example-schema-import"></a><em><span>Example 2-8.</span>
|
|
<code>xs:import</code>ed Message Definitions that Are Visible to
|
|
the Containing WSDL 2.0 Description</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
|
|
. . . >
|
|
. . .
|
|
|
|
<types>
|
|
<xs:import namespace="http://greath.example.com/2004/schemas/resSvc"
|
|
schemaLocation= "http://greath.example.com/2004/schemas/resSvc.xsd"/>
|
|
</types>
|
|
|
|
. . .
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<p>It's important to note that <code>xs:import</code> used directly
|
|
under <code>wsdl:types</code> has been given a different visibility
|
|
than <code>xs:import</code> used inside an inlined schema. An
|
|
inlined schema may use native XML schema <code>xs:import</code> to
|
|
bring in external schema definitions that are in different
|
|
namespaces; However, though this is the schema importing mechanism
|
|
recommended for WSDL 1.1 in <a href=
|
|
"http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#WSDL_and_Schema_Import">
|
|
WS-I Basic Profile</a>, according to XML Schema specification, such
|
|
enclosed message definitions are only visible to the importing
|
|
schema (in this case, the inlined schema). They are not visible to
|
|
the containing WSDL 2.0 <code>description</code>.</p>
|
|
<p>If we change <a href="#example-schema-import">Example 2-8</a> to
|
|
use XML Schema's native <code>xs:import</code> element in an
|
|
inlined schema, the schema components defined in the namespace
|
|
http://greath.example.com/2004/schemas/resSvc are not available to
|
|
our example WSDL 2.0 definition any more.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-schema-import1" id=
|
|
"example-schema-import1"></a><em><span>Example 2-9.</span>
|
|
<code>xs:import</code>ed Message Definitions in Inlined Schema Are
|
|
Not Visible to the Containing WSDL 2.0 Description</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
|
|
. . . >
|
|
. . .
|
|
|
|
<types>
|
|
<xs:schema targetNamespace="http://greath.example.com/2004/schemas/resSvcWrapper">
|
|
<xs:import namespace="http://greath.example.com/2004/schemas/resSvc"
|
|
schemaLocation= "http://greath.example.com/2004/schemas/resSvc.xsd"/>
|
|
</xs:schema>
|
|
</types>
|
|
|
|
. . .
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<p>Of course, an inlined XML schema may also use XML Schema's
|
|
native <code>xs:include</code> element to refer to schemas defined
|
|
in separate files when the included schema has no namespace or has
|
|
the same namespace as the including schema. In this case, according
|
|
to XML Schema, the included schema components become a part of the
|
|
including schema as though they had been copied and pasted into the
|
|
including schema. Hence, the included schema components are also
|
|
available to the containing WSDL 2.0 <code>description</code> for
|
|
reference by QName.</p>
|
|
<p>The following example has the same effect as <a href=
|
|
"#example-initial-types">Example 2-3</a>:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-schema-import2" id=
|
|
"example-schema-import2"></a><em><span>Example 2-10.</span>
|
|
<code>xs:included</code> Message Definitions in Inlined Schema Are
|
|
Visible to the Containing WSDL 2.0 Description</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
|
|
. . . >
|
|
. . .
|
|
|
|
<types>
|
|
<xs:schema targetNamespace="http://greath.example.com/2004/schemas/resSvc">
|
|
<xs:include schemaLocation= "http://greath.example.com/2004/schemas/resSvc.xsd"/>
|
|
</xs:schema>
|
|
</types>
|
|
|
|
. . .
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="more-types-import-include-summary" id=
|
|
"more-types-import-include-summary"></a>2.3.3 Summary of Import and
|
|
Include Mechanisms</h4>
|
|
<p>So far we have briefly covered both WSDL import and include and
|
|
schema import and include. The following table summarizes the
|
|
similarities and differences between the WSDL 2.0 and XML Schema
|
|
<code>include</code> and <code>import</code> mechanisms. We will
|
|
talk a lot more about importing mechanisms in <a href=
|
|
"#adv-import-and-authoring"><strong>3.1 Importing WSDL</strong></a>
|
|
and <a href="#adv-multiple-inline-schemas"><strong>3.2 Importing
|
|
Schemas</strong></a></p>
|
|
<a name="imin" id="imin"></a>
|
|
<table border="1">
|
|
<caption>Table 2-1. Summary of Import and Include
|
|
Mechanisms</caption>
|
|
<thead>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Mechanism</th>
|
|
<th rowspan="1" colspan="1">Object</th>
|
|
<th rowspan="1" colspan="1">Meaning</th>
|
|
<th rowspan="1" colspan="1">Visibility of Schema Components</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">wsdl:import</td>
|
|
<td rowspan="1" colspan="1">WSDL 2.0 Namespace</td>
|
|
<td rowspan="1" colspan="1">Declare that WSDL 2.0 components refer
|
|
to WSDL 2.0 components from a DIFFERENT targetNamespace.</td>
|
|
<td rowspan="1" colspan="1">XML Schema Components in the imported
|
|
<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#component-Description">
|
|
Description</a> component are NOT visible to the containing
|
|
<code>description</code>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">wsdl:include</td>
|
|
<td rowspan="1" colspan="1">WSDL 2.0 Document</td>
|
|
<td rowspan="1" colspan="1">Merge Interface, Binding and Service
|
|
components from another WSDL 2.0 document that has the SAME
|
|
targetNamespace.</td>
|
|
<td rowspan="1" colspan="1">XML Schema components in the included
|
|
<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#component-Description">
|
|
Description</a> component's {<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#property-Description.elementdeclarations">element
|
|
declarations</a>} and {<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#property-Description.typedefinitions">type
|
|
definitions</a>} properties are visible to the containing
|
|
<code>description</code>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">wsdl:types/ xs:import</td>
|
|
<td rowspan="1" colspan="1">XML Schema Namespace</td>
|
|
<td rowspan="1" colspan="1">Declare that XML Schema components
|
|
refer to XML Schema components from a DIFFERENT
|
|
targetNamespace.</td>
|
|
<td rowspan="1" colspan="1">XML Schema components in the imported
|
|
namespace are visible to the containing
|
|
<code>description</code>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">wsdl:types/ xs:schema/xs:import</td>
|
|
<td rowspan="1" colspan="1">XML Schema Namespace</td>
|
|
<td rowspan="1" colspan="1">Declare that XML Schema components
|
|
refer to XML Schema components from a DIFFERENT
|
|
targetNamespace.</td>
|
|
<td rowspan="1" colspan="1">XML Schema components in the imported
|
|
namespace are NOT visible to the containing
|
|
<code>description</code>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">wsdl:types/ xs:schema/xs:include</td>
|
|
<td rowspan="1" colspan="1">XML Schema Document</td>
|
|
<td rowspan="1" colspan="1">Merge XML Schema components from
|
|
another XML Schema document that has the SAME or NO
|
|
targetNamespace.</td>
|
|
<td rowspan="1" colspan="1">XML Schema components in the included
|
|
document are visible to the containing
|
|
<code>description</code>.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<br /></div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="more-interfaces" id="more-interfaces"></a>2.4 More on
|
|
Interfaces</h3>
|
|
<p>We previously mentioned that a WSDL 2.0 interface is basically a
|
|
set of operations. However, there are some additional capabilities
|
|
that we have not yet covered. First, let's review the syntax for
|
|
the <code>interface</code> element.</p>
|
|
<div class="div3">
|
|
<h4><a name="more-interfaces-interfaces" id=
|
|
"more-interfaces-interfaces"></a>2.4.1 Interface Syntax</h4>
|
|
<p>Below is the XML syntax summary of the <code>interface</code>
|
|
element, simplified by omitting optional
|
|
<code><documentation></code> elements:</p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<description targetNamespace="<em>xs:anyURI</em>" >
|
|
|
|
. . .
|
|
<interface name="<em>xs:NCName</em>"
|
|
extends="<em>list of xs:QName</em>"?
|
|
styleDefault="<em>list of xs:anyURI</em>"? >
|
|
|
|
<fault name="<em>xs:NCName</em>"
|
|
element="<em>xs:QName</em>"? >
|
|
</fault>*
|
|
|
|
<operation name="<em>xs:NCName</em>"
|
|
pattern="<em>xs:anyURI</em>"
|
|
style="<em>list of xs:anyURI</em>"?
|
|
wsdlx:safe="<em>xs:boolean</em>"? >
|
|
|
|
<input messageLabel="<em>xs:NCName</em>"?
|
|
element="<em>union of xs:QName, xs:Token</em>"? >
|
|
</input>*
|
|
|
|
<output messageLabel="<em>xs:NCName</em>"?
|
|
element="<em>union of xs:QName, xs:Token</em>"? >
|
|
</output>*
|
|
|
|
<infault ref="<em>xs:QName</em>" messageLabel="<em>xs:NCName</em>"? > </infault>*
|
|
|
|
<outfault ref="<em>xs:QName</em>" messageLabel="<em>xs:NCName</em>"? > </outfault>*
|
|
|
|
</operation>*
|
|
|
|
</interface>*
|
|
. . .
|
|
|
|
</description>
|
|
|
|
</pre></div>
|
|
<p>The <code>interface</code> element has two optional attributes:
|
|
<code>styleDefault</code> and <code>extends</code>. The
|
|
<code>styleDefault</code> attribute can be used to define a default
|
|
value for the <code>style</code> attributes of all operations under
|
|
this interface (see WSDL 2.0 Part 1 "<a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#Interface_styleDefault_attribute">styleDefault
|
|
attribute information item</a>"). The <code>extends</code>
|
|
attribute is for inheritance, and is explained next.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="more-interfaces-inheritance" id=
|
|
"more-interfaces-inheritance"></a>2.4.2 Interface Inheritance</h4>
|
|
<p>The optional <code>extends</code> attribute allows an interface
|
|
to extend or inherit from one or more other interfaces. In such
|
|
cases the interface contains the operations of the interfaces it
|
|
extends, along with any operations it defines directly. Two things
|
|
about extending interfaces deserve some attention.</p>
|
|
<p>First, an inheritance loop (or infinite recursion) is
|
|
prohibited: the interfaces that a given interface extends must NOT
|
|
themselves extend that interface either directly or indirectly.</p>
|
|
<p>Second, we must explain what happens when operations from two
|
|
different interfaces have the same target namespace and operation
|
|
name. There are two cases: either the component models of the
|
|
operations are the same, or they are different. If the component
|
|
models are the same (per the component comparison algorithm defined
|
|
in WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0
|
|
Core</a></cite>] " <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#compequiv">Equivalence
|
|
of Components</a> ") then they are considered to be the same
|
|
operation, i.e., they are collapsed into a single operation, and
|
|
the fact that they were included more than once is not considered
|
|
an error. (For operations, component equivalence basically means
|
|
that the two operations have the same set of attributes and
|
|
descendants.) In the second case, if two operations have the same
|
|
name in the same WSDL 2.0 target namespace but are not equivalent,
|
|
then it is an error. For the above reason, it is considered good
|
|
practice to ensure that all operations within the same target
|
|
namespace are named uniquely.</p>
|
|
<p>Finally, since faults can also be defined as children of the
|
|
<code>interface</code> element (as described in the following
|
|
sections), the same name-collision rules apply to those
|
|
constructs.</p>
|
|
<p>Let's say the GreatH hotel wants to maintain a standard message
|
|
log operation for all received messages. It wants this operation to
|
|
be reusable across the whole reservation system, so each service
|
|
will send out, for potential use of a logging service, the content
|
|
of each message it receives together with a timestamp and the
|
|
originator of the message. One way to meet such requirement is to
|
|
define the log operation in an interface which can be inherited by
|
|
other interfaces. Assuming a <code>messageLog</code> element is
|
|
already defined in the ghns namespace with the required content,
|
|
the inheritance use case is illustrated in the following example.
|
|
As a result of the inheritance, the
|
|
<code>reservationInterface</code> now contains two operations:
|
|
<code>opCheckAvailability</code> and <code>opLogMessage</code></p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-faults" id="example-faults"></a><em><span>Example
|
|
2-11.</span> Interface Inheritance</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
|
|
<description ...>
|
|
...
|
|
<interface name = "messageLogInterface" >
|
|
|
|
<operation name="opLogMessage"
|
|
pattern="http://www.w3.org/ns/wsdl/out-only">
|
|
<output messageLabel="out"
|
|
element="ghns:messageLog" />
|
|
</operation>
|
|
|
|
</interface>
|
|
|
|
<interface name="reservationInterface" <strong>extends</strong>="tns:messageLogInterface" >
|
|
|
|
<operation name="opCheckAvailability"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out"
|
|
style="http://www.w3.org/ns/wsdl/style/iri"
|
|
wsdlx:safe = "true">
|
|
<input messageLabel="In"
|
|
element="ghns:checkAvailability" />
|
|
<output messageLabel="Out"
|
|
element="ghns:checkAvailabilityResponse" />
|
|
<outfault ref="tns:invalidDataFault" messageLabel="Out"/>
|
|
|
|
</operation>
|
|
</interface>
|
|
...
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<p>Now let's have a look at the element children of
|
|
<code>interface</code>, beginning with <code>fault</code>.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="more-interfaces-faults" id=
|
|
"more-interfaces-faults"></a>2.4.3 Interface Faults</h4>
|
|
<p>The <code>fault</code> element is used to declare faults that
|
|
may occur during execution of operations of an interface. They are
|
|
declared directly under <code>interface</code>, and referenced from
|
|
operations where they apply, in order to permit reuse across
|
|
multiple operations.</p>
|
|
<p>Faults are very similar to messages and can be viewed as a
|
|
special kind of message. Both faults and messages may carry a
|
|
payload that is normally described by an element declaration.
|
|
However, WSDL 2.0 treats faults and messages slightly differently.
|
|
The messages of an operation directly refer to their element
|
|
declaration, however the faults of an operation indirectly refer to
|
|
their element declaration via a fault element that is defined on
|
|
the interface.</p>
|
|
<p>The reason for defining faults at the interface level is to
|
|
allow their reuse across multiple operations. This design is
|
|
especially beneficial when bindings are defined, since in binding
|
|
extensions like SOAP there is additional information that is
|
|
associated with faults. In the case of SOAP, faults have codes and
|
|
subcodes in addition to a payload. By defining faults at the
|
|
interface level, common codes and subcodes can be associated with
|
|
them, thereby ensuring consistency across all operations that use
|
|
the faults</p>
|
|
<p>The <code>fault</code> element has a required <code>name</code>
|
|
attribute that must be unique within the parent
|
|
<code>interface</code> element, and permits it to be referenced
|
|
from operation declarations. The optional <code>element</code>
|
|
attribute can be used to indicate a schema for the content or
|
|
payload of the fault message. Its value should be the QName of a
|
|
global element defined in the <code>types</code> section. Please
|
|
note that when other type systems are used to define the schema for
|
|
a fault message, additional attributes may need to be defined via
|
|
WSDL 2.0's attribute extension mechanism to allow the schema to be
|
|
associated with the fault.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="more-interfaces-operations" id=
|
|
"more-interfaces-operations"></a>2.4.4 Interface Operations</h4>
|
|
<p>As shown earlier, the <code>operation</code> element is used to
|
|
indicate an operation supported by the containing interface. It
|
|
associates message schemas with a message exchange pattern (MEP),
|
|
in order to abstractly describe a simple interaction with a Web
|
|
service.</p>
|
|
<div class="div4">
|
|
<h5><a name="more-interfaces-op-attr" id=
|
|
"more-interfaces-op-attr"></a>2.4.4.1 Operation Attributes</h5>
|
|
<p>An <code>operation</code> has two required attributes and one
|
|
optional attribute:</p>
|
|
<ul>
|
|
<li>
|
|
<p>A required <code>name</code> attribute, as seen already, which
|
|
must be unique within the interface.</p>
|
|
</li>
|
|
<li>
|
|
<p>A required <code>pattern</code> attribute whose value must be an
|
|
absolute URI that identifies the desired MEP for the
|
|
<code>operation</code>. MEPs are further explained in <a href=
|
|
"#more-interfaces-meps"><strong>2.4.4.3 Understanding Message
|
|
Exchange Patterns (MEPs)</strong></a>.</p>
|
|
</li>
|
|
<li>
|
|
<p>An optional <code>style</code> attribute whose value is a list
|
|
of absolute URIs. Each URI identifies a certain set of rules that
|
|
were followed in defining this <code>operation</code>. It is an
|
|
error if a particular style is indicated, but the associated rules
|
|
are not followed. [<cite><a href="#WSDL-PART2">WSDL 2.0
|
|
Adjuncts</a></cite>] defines a set of styles, including</p>
|
|
<ul>
|
|
<li>
|
|
<p>RPC Style. The RPC style is selected when the <code>style</code>
|
|
is assigned the value http://www.w3.org/ns/wsdl/rpc. It places
|
|
restrictions for Remote Procedure Call-types of interactions.</p>
|
|
</li>
|
|
<li>
|
|
<p>IRI Style. The IRI style is selected when the <code>style</code>
|
|
is assigned the value http://www.w3.org/ns/wsdl/style/iri. It
|
|
places restrictions on message definitions so they may be
|
|
serialized into something like HTTP URL encoded.</p>
|
|
</li>
|
|
<li>
|
|
<p>The Multipart style. The Multipart style is selected when the
|
|
<code>style</code> is assigned the value
|
|
http://www.w3.org/ns/wsdl/style/multipart. In the HTTP binding, for
|
|
XForms clients, a message must be defined following the Multipart
|
|
style and serialized as "Multipart/form-data".</p>
|
|
</li>
|
|
</ul>
|
|
<p>You can find more details of these WSDL 2.0 predefined styles.
|
|
Section <a href="#adv-RPCstyle"><strong>4.3 RPC Style</strong></a>
|
|
provides an example of using the RPC <code>style</code>.
|
|
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] provides
|
|
examples for the IRI style and Multipart style.</p>
|
|
</li>
|
|
</ul>
|
|
<p>Note that [<cite><a href="#WSDL-PART2">WSDL 2.0
|
|
Adjuncts</a></cite>] provides a predefined extension for indicating
|
|
operation safety. The <code>wsdlx:safe</code> global attribute
|
|
whose value is a boolean can be used with an operation to indicate
|
|
whether the operation is asserted to be "safe" (as defined in
|
|
Section 3.5 of the Web Architecture [<cite><a href="#webarch">Web
|
|
Architecture</a></cite>]) for clients to invoke. In essence, a safe
|
|
operation is any operation that does not give the client any new
|
|
obligations. For example, an operation that permits the client to
|
|
check prices on products typically would not obligate the client to
|
|
buy those products, and thus would be safe, whereas an operation
|
|
for purchasing products would obligate the client to pay for the
|
|
products that were ordered, and thus would not be safe.</p>
|
|
<p>An operation should be marked safe (by using the
|
|
<code>wsdlx:safe</code> and by setting its value to "true") if it
|
|
meets the criteria for a safe interaction defined in Section 3.5 of
|
|
the Web Architecture [<cite><a href="#webarch">Web
|
|
Architecture</a></cite>], because this permits the infrastructure
|
|
to perform efficiency optimizations, such as pre-fetch, re-fetch
|
|
and caching.</p>
|
|
<p>The default value of this attribute is false. If it is false or
|
|
is not set, then no assertion is made about the safety of the
|
|
operation; thus the operation may or may not be safe.</p>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="id2295836" id="id2295836"></a>2.4.4.2 Operation
|
|
Message References</h5>
|
|
<p>An <code>operation</code> will also have <code>input</code>,
|
|
<code>output</code>,<code>infault</code>, and/or
|
|
<code>outfault</code> element children that specify the ordinary
|
|
and fault message types to be used by that operation. The MEP
|
|
specified by the <code>pattern</code> attribute determines which of
|
|
these elements should be included, since each MEP has placeholders
|
|
for the message types involved in its pattern.</p>
|
|
<p>Since operations were already discussed in <a href=
|
|
"#basics-interface"><strong>2.1.4 Defining an
|
|
Interface</strong></a>, this section will merely comment on
|
|
additional capabilities that were not previously explained.</p>
|
|
<div class="div5">
|
|
<h6><a name="id2295901" id="id2295901"></a>2.4.4.2.1 The
|
|
messageLabel Attribute</h6>
|
|
<p>The <code>messageLabel</code> attribute of the
|
|
<code>input</code> and <code>output</code> elements is optional. It
|
|
is not necessary to explicitly set the <code>messageLabel</code>
|
|
when the MEP in use is one of the eight MEPs predefined in WSDL 2.0
|
|
Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]
|
|
and it has only one message with a given direction.</p>
|
|
</div>
|
|
<div class="div5">
|
|
<h6><a name="id2295952" id="id2295952"></a>2.4.4.2.2 The element
|
|
Attribute</h6>
|
|
<p>The <code>element</code> attribute of the <code>input</code> and
|
|
<code>output</code> elements is used to specify the message content
|
|
schema (aka payload schema) when the content model is defined using
|
|
XML Schema. As we have seen already, it can specify the QName of an
|
|
element schema that was defined in the <code>types</code> section.
|
|
However, alternatively it can specify one of the following
|
|
tokens:</p>
|
|
<dl>
|
|
<dt class="label"><code>#any</code></dt>
|
|
<dd>
|
|
<p>The message content is any single element.</p>
|
|
</dd>
|
|
<dt class="label"><code>#none</code></dt>
|
|
<dd>
|
|
<p>There is no message content, i.e., the message payload is
|
|
empty.</p>
|
|
</dd>
|
|
<dt class="label"><code>#other</code></dt>
|
|
<dd>
|
|
<p>The message content is described by a non-XML type system.
|
|
Extension attributes specify the type.</p>
|
|
</dd>
|
|
</dl>
|
|
<p>The <code>element</code> attribute is also optional. If it is
|
|
not specified, then the message content is described by a non-XML
|
|
type system.</p>
|
|
<p>Note that there are situations that the information conveyed in
|
|
the <code>element</code> attribute is not sufficient for a service
|
|
implementation to uniquely identify an incoming message and
|
|
dispatch it to an appropriate operation. In such situations,
|
|
additional means may be required to aid identifying an incoming
|
|
message. See <a href="#adv-message-dispatch"><strong>5.1 Enabling
|
|
Easy Message Dispatch</strong></a> for more detail.</p>
|
|
</div>
|
|
<div class="div5">
|
|
<h6><a name="id2296126" id="id2296126"></a>2.4.4.2.3 Multiple
|
|
infault or outfault Elements</h6>
|
|
<p>When <code>infault</code> and/or <code>outfault</code> occur
|
|
multiple times within an <code>operation</code>, they define
|
|
alternative fault messages.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="more-interfaces-meps" id=
|
|
"more-interfaces-meps"></a>2.4.4.3 Understanding Message Exchange
|
|
Patterns (MEPs)</h5>
|
|
<p>WSDL 2.0 message exchange patterns (MEPs) are used to define the
|
|
sequence and cardinality of the abstract messages in an operation.
|
|
By design, WSDL 2.0 MEPs are abstract. First of all, they abstract
|
|
out specific message types. MEPs identify placeholders for
|
|
messages, and placeholders are associated with specific message
|
|
types when an operation is defined, which includes specifying which
|
|
MEP to use for that operation. Secondly, unless explicitly stated
|
|
otherwise, MEPs also abstract out binding-specific information like
|
|
timing between messages, whether the pattern is synchronous or
|
|
asynchronous, and whether the messages are sent over a single or
|
|
multiple channels.</p>
|
|
<p>It's worth pointing out that WSDL 2.0 MEPs do not exhaustively
|
|
describe the set of messages that may be exchanged between a
|
|
service and other nodes. By some prior agreement, another node
|
|
and/or the service may send other messages (to each other or to
|
|
other nodes) that are not described by the MEP. For instance, even
|
|
though an MEP may define a single message sent from a service to
|
|
one other node, a service defined by that MEP may multicast that
|
|
message to other nodes. To maximize reuse, WSDL 2.0 message
|
|
exchange patterns identify a minimal contract between other parties
|
|
and Web Services, and contain only information that is relevant to
|
|
both the Web service and the client that engages that service.</p>
|
|
<p>A total of eight MEPs are defined in [<cite><a href=
|
|
"#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]. These MEPs should
|
|
cover the most common use cases, but they are not meant to be an
|
|
exhaustive list of MEPs that can ever be used by operations. More
|
|
MEPs can be defined for particular application needs by interested
|
|
parties. (See <a href="#more-interfaces-meps"><strong>2.4.4.3
|
|
Understanding Message Exchange Patterns (MEPs)</strong></a> )</p>
|
|
<p>For the eight MEPs defined by WSDL 2.0, some of them are
|
|
variations of others based on how faults may be generated. For
|
|
example, the In-Only pattern ("http://www.w3.org/ns/wsdl/in-only")
|
|
consists of exactly one message received by a service from some
|
|
other node. No fault can be generated. As a variation of In-Only,
|
|
Robust In-Only pattern ("http://www.w3.org/ns/wsdl/robust-in-only")
|
|
also consists of exactly one message received by a service, but in
|
|
this case faults can be triggered by the message and must be
|
|
delivered to the originator of the message. If there is no path to
|
|
this node, the fault must be discarded. For details about the
|
|
common fault generation models used by the eight WSDL 2.0 MEPs, see
|
|
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>].</p>
|
|
<p>Depending on how the first message in the MEP is initiated, the
|
|
eight WSDL 2.0 MEPs may be grouped into two groups: in-bound MEPs,
|
|
for which the service receives the first message in the exchange,
|
|
and out-bound MEPs, for which the service sends out the first
|
|
message in the exchange. (Such grouping is not provided in the WSDL
|
|
2.0 specification and is presented here only for the purpose of
|
|
easy reference in this primer).</p>
|
|
<p>A frequently asked question about out-bound MEPs is how a
|
|
service knows where to send the message. Services using out-bound
|
|
MEPs are typically part of large scale integration systems that
|
|
rely on mapping and routing facilities. In such systems, out-bound
|
|
MEPs are useful for specifying the functionality of a service
|
|
abstractly, including its requirements for potential customers,
|
|
while endpoint address information can be provided at deployment or
|
|
runtime by the underlying integration infrastructure. For example,
|
|
the GreatH hotel reservation system may require that every time a
|
|
customer interacts with the system to check availability, data
|
|
about the customer must be logged by a CRM system. At design time,
|
|
it's unknown which particular CRM system would be used together
|
|
with the reservation system. To address this requirement, we may
|
|
change the "reservationInterface" in <a href=
|
|
"#example-initial">Example 2-1</a> to include an out-bound
|
|
logInquiry operation. This <code>logInquiry</code> operation
|
|
advertises to potential service clients that customer data will be
|
|
made available by the reservation service at run time. When the
|
|
reservation service is deployed to GreatH's IT landscape,
|
|
appropriate configuration time and run time infrastructure will
|
|
help determine which CRM system will get the customer data and log
|
|
it appropriately. It's worth noting that in addition to being used
|
|
by a CRM system for customer management purpose, the same data may
|
|
also be used by a system performance analysis tool for different
|
|
purpose. Providing an out-bound operation in the reservation
|
|
service enables loose coupling and so improves the overall GreatH
|
|
IT landscape's flexibility and scalability.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-outbound-operation" id=
|
|
"example-outbound-operation"></a><em><span>Example 2-12.</span> Use
|
|
of outbound MEPs</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
|
|
<description ...>
|
|
...
|
|
<interface name="reservationInterface">
|
|
...
|
|
<operation name="opCheckAvailability" ... >
|
|
|
|
<operation name="opLogInquiry"
|
|
<strong>pattern="http://www.w3.org/ns/wsdl/out-only"</strong>>
|
|
<<strong>output messageLabel="Out" element="ghns:customerData"</strong> />
|
|
</operation>
|
|
|
|
</interface>
|
|
...
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<p>Although the eight MEPs defined in WSDL 2.0 Part 2
|
|
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] are
|
|
intended to cover most use cases, WSDL 2.0 has designed this set to
|
|
be extensible. This is why MEPs are identified by URIs rather than
|
|
a fixed set of tokens.</p>
|
|
<p>For more about defining new MEPs, see <a href=
|
|
"#adv-MEP"><strong>4.2 Defining New MEPs</strong></a>.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="more-bindings" id="more-bindings"></a>2.5 More on
|
|
Bindings</h3>
|
|
<p>Bindings are used to supply protocol and encoding details that
|
|
specify <em>how</em> messages are to be sent or received. Each
|
|
<code>binding</code> element uses a particular <em>binding
|
|
extension</em> to specify such information. WSDL 2.0 Part 2
|
|
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] defines
|
|
several binding extensions that are typically used. However,
|
|
binding extensions that are not defined in WSDL 2.0 Part 2 can also
|
|
be used, provided that client and service toolkits support
|
|
them.</p>
|
|
<p>Binding information must be supplied for every operation in the
|
|
interface that is used in an endpoint. However, if the desired
|
|
binding extension provides suitable defaulting rules, then the
|
|
information will only need to be explicitly supplied at the
|
|
interface level, and the defaulting rules will implicitly propagate
|
|
the information to the operations of the interface. For example,
|
|
see the <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#soap-defaults">
|
|
Default Binding Rules</a> of SOAP binding extension in WSDL 2.0
|
|
Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0
|
|
Adjuncts</a></cite>].</p>
|
|
<div class="div3">
|
|
<h4><a name="more-bindings-wsdl" id="more-bindings-wsdl"></a>2.5.1
|
|
Syntax Summary for Bindings</h4>
|
|
<p>Since bindings are specified using extensions to the WSDL 2.0
|
|
language (i.e., binding extensions are not in the WSDL 2.0
|
|
namespace), the XML for expressing a binding will consist of a
|
|
mixture of elements and attributes from WSDL 2.0 namespace and from
|
|
the binding extension's namespace, using WSDL 2.0's open content
|
|
model.</p>
|
|
<p>Here is a syntax summary for <code>binding</code>, simplified by
|
|
omitting optional <code>documentation</code> elements. Bear in mind
|
|
that this syntax summary only shows the elements and attributes
|
|
defined within the WSDL 2.0 namespace. When an actual binding is
|
|
defined, elements and attributes from the namespace of the desired
|
|
binding extension will also be intermingled as required by that
|
|
particular binding extension.</p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<description targetNamespace="<em>xs:anyURI</em>" >
|
|
. . .
|
|
<<strong>binding</strong> name="<em>xs:NCName</em>" interface="<em>xs:QName</em>"? >
|
|
|
|
<fault ref="<em>xs:QName</em>" > </fault>*
|
|
|
|
<operation ref="<em>xs:QName</em>" >
|
|
<input messageLabel="<em>xs:NCName</em>"? > </input>*
|
|
<output messageLabel="<em>xs:NCName</em>"? > </output>*
|
|
<infault ref="<em>xs:QName</em>" messageLabel="<em>xs:NCName</em>"? > </infault>*
|
|
<outfault ref="<em>xs:QName</em>" messageLabel="<em>xs:NCName</em>"? > </outfault>*
|
|
</operation>*
|
|
|
|
</<strong>binding</strong>>*
|
|
. . .
|
|
</description>
|
|
</pre></div>
|
|
<p>The <code>binding</code> syntax parallels the syntax of
|
|
<code>interface</code>: each interface construct has a binding
|
|
counterpart. Despite this syntactic similarity, they are indeed
|
|
different constructs, since they are in different symbol spaces and
|
|
are designed for different purposes.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="more-bindings-reusable" id=
|
|
"more-bindings-reusable"></a>2.5.2 Reusable Bindings</h4>
|
|
<p>A binding can either be reusable (applicable to any interface)
|
|
or non-reusable (specified for a particular interface).
|
|
Non-reusable bindings may be specified at the granularity of the
|
|
interface (assuming the binding extension provides suitable
|
|
defaulting rules), or on a per-operation basis if needed. A
|
|
non-reusable binding was demonstrated in <a href=
|
|
"#basics-binding"><strong>2.1.5 Defining a
|
|
Binding</strong></a>.</p>
|
|
<p>To define a reusable binding, the <code>binding</code> element
|
|
simply omits the <code>interface</code> attribute and omits
|
|
specifying any operation-specific and fault-specific binding
|
|
details. Endpoints can later refer to a reusable binding in the
|
|
same manner as for a non-reusable binding. Thus, a reusable binding
|
|
becomes associated with a particular interface when it is
|
|
referenced from an endpoint, because an endpoint is part of a
|
|
service, and the service specifies a particular interface that it
|
|
implements. Since a reusable binding does not specify an interface,
|
|
reusable bindings cannot specify operation-specific details.
|
|
Therefore, reusable bindings can only be defined using binding
|
|
extensions that have suitable defaulting rules, such that the
|
|
binding information only needs to be explicitly supplied at the
|
|
interface level.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="more-bindings-faults" id=
|
|
"more-bindings-faults"></a>2.5.3 Binding Faults</h4>
|
|
<p>A binding <code>fault</code> associates a concrete message
|
|
format with an abstract fault of an interface. It describes how
|
|
faults that occur within a message exchange of an operation will be
|
|
formatted, since the fault does not occur by itself. Rather, a
|
|
fault occurs as part of a message exchange specified by an
|
|
interface <code>operation</code> and its binding counterpart, the
|
|
binding <code>operation</code>.</p>
|
|
<p>A binding <code>fault</code> has one required <code>ref</code>
|
|
attribute which is a reference, by QName, to an
|
|
<code>interface</code> <code>fault</code>. It identifies the
|
|
abstract interface <code>fault</code> for which binding information
|
|
is being specified. Be aware that the value of <code>ref</code>
|
|
attribute of all the <code>faults</code> under a
|
|
<code>binding</code> must be unique. That is, one cannot define
|
|
multiple bindings for the same interface fault within a given
|
|
<code>binding</code>.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="bindingOperations" id="bindingOperations"></a>2.5.4
|
|
Binding Operations</h4>
|
|
<p>A binding <code>operation</code> describes a concrete binding of
|
|
an interface operation to a concrete message format. An interface
|
|
operation is uniquely identified by the WSDL 2.0 target namespace
|
|
of the interface and the name of the operation within that
|
|
interface, via the required <code>ref</code> attribute of binding
|
|
<code>operation</code>. As with faults, for each
|
|
<code>operation</code> within a <code>binding</code>, the value of
|
|
the <code>ref</code> attribute must be unique.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="more-bindings-soap" id="more-bindings-soap"></a>2.5.5
|
|
The SOAP Binding Extension</h4>
|
|
<p>The WSDL 2.0 SOAP Binding Extension (see WSDL 2.0 Part 2
|
|
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]) was
|
|
primarily designed to support the features of SOAP 1.2
|
|
[<cite><a href="#SOAP12-PART1">SOAP 1.2 Part 1: Messaging
|
|
Framework</a></cite>]. However, for backwards compatibility, it
|
|
also provides some support for SOAP 1.1 [<cite><a href=
|
|
"#SOAP11">SOAP 1.1</a></cite>].</p>
|
|
<p>An example using the WSDL 2.0 SOAP binding extension was already
|
|
presented in <a href="#basics-binding"><strong>2.1.5 Defining a
|
|
Binding</strong></a>, but some additional points are worth
|
|
mentioning:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Because the same binding extension is used for both SOAP 1.2 and
|
|
SOAP 1.1, a <code>wsoap:version</code> attribute is provided to
|
|
allow you to indicate which version of SOAP you want. If this
|
|
attribute is not specified, it defaults to SOAP 1.2.</p>
|
|
</li>
|
|
<li>
|
|
<p>The WSDL 2.0 SOAP binding extension defines a set of default
|
|
rules, so that bindings can be specified at the interface level or
|
|
at the operation level (or both), with the operation level taking
|
|
precedence. However, it does not define default binding rules for
|
|
faults. Thus, if a given interface defines any faults, then
|
|
corresponding binding information must be explicitly provided for
|
|
each such fault.</p>
|
|
</li>
|
|
<li>
|
|
<p>If HTTP is used as the underlying protocol, then the binding can
|
|
(and should) control whether each operation will use HTTP GET or
|
|
POST. (See <a href="#adv-get-vs-post"><strong>2.5.7 HTTP GET Versus
|
|
POST: Which to Use?</strong></a>.)</p>
|
|
</li>
|
|
</ul>
|
|
<p>Here is an example that illustrates both a SOAP 1.2 binding (as
|
|
seen before) and a SOAP 1.1 binding.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-binding-soap" id=
|
|
"example-binding-soap"></a><em><span>Example 2-13.</span> SOAP 1.2
|
|
and SOAP 1.1 Bindings</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description
|
|
xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace="http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:tns="http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:ghns="http://greath.example.com/2004/schemas/resSvc"
|
|
xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
|
|
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
|
|
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/">
|
|
|
|
....
|
|
|
|
<!-- SOAP 1.2 Binding -->
|
|
<binding name="reservationSOAPBinding"
|
|
interface="tns:reservationInterface"
|
|
type="http://www.w3.org/ns/wsdl/soap"
|
|
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
|
|
|
|
<operation ref="tns:opCheckAvailability"
|
|
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"/>
|
|
|
|
<fault ref="tns:invalidDataFault"
|
|
wsoap:code="soap:Sender"/>
|
|
|
|
</binding>
|
|
|
|
<!-- SOAP 1.1 Binding -->
|
|
<binding name="reservationSOAP11Binding"
|
|
interface="tns:reservationInterface"
|
|
type="http://www.w3.org/ns/wsdl/soap"
|
|
wsoap:version="1.1"
|
|
wsoap:protocol="http://www.w3.org/2006/01/soap11/bindings/HTTP/">
|
|
|
|
<operation ref="tns:opCheckAvailability"/>
|
|
|
|
<fault ref="tns:invalidDataFault"
|
|
wsoap:code="soap11:Client"/>
|
|
|
|
</binding>
|
|
|
|
|
|
<service name="reservationService"
|
|
interface="tns:reservationInterface">
|
|
|
|
<!-- SOAP 1.2 End Point -->
|
|
<endpoint name="reservationEndpoint"
|
|
binding="tns:reservationSOAPBinding"
|
|
address="http://greath.example.com/2004/reservation"/>
|
|
|
|
<!-- SOAP 1.1 End Point -->
|
|
<endpoint name="reservationEndpoint2"
|
|
binding="tns:reservationSOAP11Binding"
|
|
address="http://greath.example.com/2004/reservation"/>
|
|
|
|
</service>
|
|
</description>
|
|
|
|
</pre></div>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="more-bindings-soap-example-explanation" id=
|
|
"more-bindings-soap-example-explanation"></a>2.5.5.1 Explanation of
|
|
Example</h5>
|
|
<p>Most lines in this example is the same as previously explained
|
|
in <a href="#basics-binding"><strong>2.1.5 Defining a
|
|
Binding</strong></a>, so we'll only point out lines that are
|
|
demonstrating something new for SOAP 1.1 binding.</p>
|
|
<dl>
|
|
<dt class="label"><code><description ...
|
|
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"></code></dt>
|
|
<dd>
|
|
<p>This is the namespace for terms defined within the SOAP 1.1
|
|
specification [<cite><a href="#SOAP11">SOAP 1.1</a></cite>].</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code><binding...wsoap:version="1.1"</code></dt>
|
|
<dd>
|
|
<p>This line indicates that this binding uses SOAP 1.1
|
|
[<cite><a href="#WSDL-SOAP11">WSDL 2.0 SOAP 1.1
|
|
Binding</a></cite>], rather than SOAP 1.2.</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>wsoap:protocol="http://www.w3.org/2006/01/soap11/bindings/HTTP/"></code></dt>
|
|
<dd>
|
|
<p>This line specifies that HTTP should be used as the underlying
|
|
transmission protocol. See also <a href=
|
|
"#adv-get-vs-post"><strong>2.5.7 HTTP GET Versus POST: Which to
|
|
Use?</strong></a>.</p>
|
|
</dd>
|
|
<dt class="label"><code><operation
|
|
ref="tns:opCheckAvailability"/></code></dt>
|
|
<dd>
|
|
<p>Note that <code>wsoap:mep</code> is not applicable to SOAP 1.1
|
|
binding.</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code><fault...wsoap:code="soap11:Client"/></code></dt>
|
|
<dd>
|
|
<p>This line specifies the SOAP 1.1 fault code that will be used in
|
|
transmitting invalidDataFault.</p>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="more-bindings-http" id="more-bindings-http"></a>2.5.6
|
|
The HTTP Binding Extension</h4>
|
|
<p>In addition to the WSDL 2.0 SOAP binding extension described
|
|
above, WSDL 2.0 Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0
|
|
Adjuncts</a></cite>] defines a binding extension for HTTP 1.1
|
|
[<cite><a href="#RFC2616">IETF RFC 2616</a></cite>] and HTTPS
|
|
[<cite><a href="#RFC2818">IETF RFC 2818</a></cite>], so that these
|
|
protocols can be used natively to send and receive messages,
|
|
without first encoding them in SOAP.</p>
|
|
<p>The HTTP binding extension provides many features to
|
|
control:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Which HTTP operation will be used. (GET, PUT, POST, DELETE, and
|
|
other HTTP operations are supported.)</p>
|
|
</li>
|
|
<li>
|
|
<p>Input, output and fault serialization</p>
|
|
</li>
|
|
<li>
|
|
<p>Transfer codings</p>
|
|
</li>
|
|
<li>
|
|
<p>Authentication requirements</p>
|
|
</li>
|
|
<li>
|
|
<p>Cookies</p>
|
|
</li>
|
|
<li>
|
|
<p>HTTP over TLS (https)</p>
|
|
</li>
|
|
</ul>
|
|
<p>As with the WSDL 2.0 SOAP binding extension, the HTTP binding
|
|
extension also provides defaulting rules to permit binding
|
|
information to be specified at the interface level and used by
|
|
default for each operation in the affected interface, however,
|
|
defaulting rules are not provided for binding faults.</p>
|
|
<p>Here is an example of using the HTTP binding extension to check
|
|
hotel room availability at GreatH.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-bindings-http" id=
|
|
"example-bindings-http"></a><em><span>Example 2-14.</span> HTTP
|
|
Binding Extension</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
. . .
|
|
xmlns:whttp="http://www.w3.org/ns/wsdl/http" >
|
|
|
|
. . .
|
|
<binding name="reservationHTTPBinding"
|
|
interface="tns:reservationInterface"
|
|
type="http://www.w3.org/ns/wsdl/http"
|
|
whttp:methodDefault="GET">
|
|
|
|
<operation ref="tns:opCheckAvailability"
|
|
whttp:location="{checkInDate}" />
|
|
</binding>
|
|
|
|
<service name="reservationService"
|
|
interface="tns:reservationInterface">
|
|
|
|
<!-- HTTP 1.1 GET End Point -->
|
|
<endpoint name="reservationEndpoint"
|
|
binding="tns:reservationHTTPBinding"
|
|
address="http://greath.example.com/2004/checkAvailability/"/>
|
|
|
|
</service>
|
|
. . .
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="id2297429" id="id2297429"></a>2.5.6.1 Explanation of
|
|
Example</h5>
|
|
<p>Most of this example is the same as previously explained in
|
|
<a href="#basics-binding"><strong>2.1.5 Defining a
|
|
Binding</strong></a>, so we'll only point out lines that are
|
|
demonstrating something new for HTTP binding extension.</p>
|
|
<dl>
|
|
<dt class="label">
|
|
<code><description...xmlns:whttp="http://www.w3.org/ns/wsdl/http"
|
|
></code></dt>
|
|
<dd>
|
|
<p>This defines the namespace prefix for elements and attributes
|
|
defined by the WSDL 2.0 HTTP binding extension.</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code><binding...type="http://www.w3.org/ns/wsdl/http"</code></dt>
|
|
<dd>
|
|
<p>This declares the binding as being an HTTP binding.</p>
|
|
</dd>
|
|
<dt class="label"><code>whttp:methodDefault="GET"></code></dt>
|
|
<dd>
|
|
<p>The default method for operations in this interface will be HTTP
|
|
GET.</p>
|
|
</dd>
|
|
<dt class="label"><code>whttp:location="{checkInDate}"
|
|
></code></dt>
|
|
<dd>
|
|
<p>The <code>whttp:location</code> attribute specifies a pattern
|
|
for serializing input message instance data into the path component
|
|
of the request URI. The default binding rules for HTTP specify that
|
|
the default input serialization for GET is
|
|
<code>application/x-www-form-urlencoded</code>. Curly braces are
|
|
used to specify the name of a schema type in the input message
|
|
schema, which determines what input instance data will be inserted
|
|
into the path component of the request URI. The curly
|
|
brace-enclosed name will be replaced with instance data in
|
|
constructing the path component. Remaining input instance data (not
|
|
specified by <code>whttp:location</code>) will either be serialized
|
|
into the query string portion of the URI or into the message body,
|
|
as follows: if a "/" is appended to a curly brace-enclosed type
|
|
name, then any remaining input message instance data will be
|
|
serialized into the message body. Otherwise it will be serialized
|
|
into query parameters.</p>
|
|
<p>Thus, in this example, each of the elements in the
|
|
<code>tCheckAvailability</code> type will be serialized into the
|
|
query parameters. A sample resulting URI would therefore be
|
|
<code>http://greath.example.com/2004/checkAvailability/5-5-5?checkOutDate=6-6-5&roomType=foo</code>.</p>
|
|
</dd>
|
|
</dl>
|
|
<p>Here is an alternate example that appends "/" to the type name
|
|
in order to serialize the remaining instance data into the message
|
|
body:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-bindings-http-path-subsset" id=
|
|
"example-bindings-http-path-subsset"></a><em><span>Example
|
|
2-15.</span> Serializing a Subset of Types in the Path</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
|
|
. . .
|
|
<operation ref="tns:opCheckAvailability"
|
|
whttp:location="bycheckInDate/{checkInDate/}" >
|
|
. . .
|
|
</pre></div>
|
|
</div>
|
|
<p>This would instead serialize to a request URI such as:
|
|
<code>http://greath.example.com/2004/checkAvailability/bycheckInDate/5-5-5</code>.
|
|
The rest of the message content would go to the HTTP message
|
|
body.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="adv-get-vs-post" id="adv-get-vs-post"></a>2.5.7 HTTP
|
|
GET Versus POST: Which to Use?</h4>
|
|
<p>When a binding using HTTP is specified for an operation, the
|
|
WSDL 2.0 author must decide which HTTP method is appropriate to use
|
|
-- usually a choice between GET and POST. In the context of the Web
|
|
as a whole (rather than specifically Web services), the W3C
|
|
Technical Architecture Group (TAG) has addressed the question of
|
|
when it is appropriate to use GET, versus when to use POST, in a
|
|
finding entitled <em>URIs, Addressability, and the use of HTTP GET
|
|
and POST</em> ([<cite><a href="#TAG-whenToUseGET">W3C TAG Finding:
|
|
Use of HTTP GET</a></cite>]). From the abstract:</p>
|
|
<p>"<em>. . . designers should adopt [GET] for safe operations such
|
|
as simple queries. POST is appropriate for other types of
|
|
applications where a user request has the potential to change the
|
|
state of the resource (or of related resources). The finding
|
|
explains how to choose between HTTP GET and POST for an application
|
|
taking into account architectural, security, and practical
|
|
considerations.</em>"</p>
|
|
<p>Recall that the concept of a safe operation was discussed in
|
|
<a href="#more-interfaces-op-attr"><strong>2.4.4.1 Operation
|
|
Attributes</strong></a>. (Briefly, a safe operation is one that
|
|
does not cause the invoker to incur new obligations.) Although the
|
|
<code>wsdlx:safe</code> attribute of an interface operation
|
|
indicates that the abstract operation is safe, it does not
|
|
automatically cause GET to be used at the HTTP level when the
|
|
binding is specified. The choice of GET or POST is determined at
|
|
the binding level:</p>
|
|
<ul>
|
|
<li>
|
|
<p>If the WSDL 2.0 SOAP binding extension is used (<a href=
|
|
"#more-bindings-soap"><strong>2.5.5 The SOAP Binding
|
|
Extension</strong></a>), with HTTP as the underlying transport
|
|
protocol, then GET may be specified by setting:</p>
|
|
<dl>
|
|
<dt class="label">
|
|
<code>wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"</code></dt>
|
|
<dd>
|
|
<p>on the <code>binding</code> element (to indicate the use of HTTP
|
|
as the underlying protocol); and</p>
|
|
</dd>
|
|
<dt class="label">
|
|
<code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response/"</code></dt>
|
|
<dd>
|
|
<p>on the binding <code>operation</code> element, which causes GET
|
|
to be used by default.</p>
|
|
</dd>
|
|
</dl>
|
|
</li>
|
|
<li>
|
|
<p>If the WSDL 2.0 HTTP binding extension is used directly
|
|
(<a href="#more-bindings-http"><strong>2.5.6 The HTTP Binding
|
|
Extension</strong></a>), GET may be specified by setting
|
|
either:</p>
|
|
<dl>
|
|
<dt class="label"><code>whttp:methodDefault="GET"</code></dt>
|
|
<dd>
|
|
<p>on the <code>binding</code> element; or</p>
|
|
</dd>
|
|
<dt class="label"><code>whttp:method="GET"</code></dt>
|
|
<dd>
|
|
<p>on the binding <code>operation</code> element, which overrides
|
|
<code>whttp:methodDefault</code> if set on the <code>binding</code>
|
|
element; or</p>
|
|
</dd>
|
|
<dt class="label"><code>wsdlx:safe="true"</code></dt>
|
|
<dd>
|
|
<p>on the bound <code>interface operation</code> . When the above
|
|
two items are not explicitly set, and when the bound interface
|
|
operation is marked safe, the HTTP Binding will by default set the
|
|
method to GET.</p>
|
|
</dd>
|
|
</dl>
|
|
</li>
|
|
</ul>
|
|
<p>For example, in the GreatH interface definition shown in
|
|
<a href="#example-initial-interface">Example 2-4</a>, the
|
|
wsdlx:safe attribute is set to "true". The HTTP binding definition
|
|
in <a href="#example-bindings-http">Example 2-14</a> may take
|
|
advantage of that and be simplified as below and still have the
|
|
http method set to GET by default:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-binding-safety" id=
|
|
"example-binding-safety"></a><em><span>Example 2-16.</span> Safety
|
|
and HTTP Binding</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
|
|
<binding name="reservationHTTPBinding"
|
|
|
|
interface="tns:reservationInterface"
|
|
|
|
type="http://www.w3.org/ns/wsdl/http" >
|
|
|
|
<operation ref="tns:opCheckAvailability"
|
|
|
|
whttp:location="{checkInDate}"/>
|
|
|
|
</binding>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="advanced-topic_ii" id="advanced-topic_ii"></a>3.
|
|
Advanced Topics I: Importing Mechanisms</h2>
|
|
<div class="div2">
|
|
<h3><a name="adv-import-and-authoring" id=
|
|
"adv-import-and-authoring"></a>3.1 Importing WSDL</h3>
|
|
<p>In some circumstances WSDL authors may want to split up a Web
|
|
service description into two or more documents. For example, if a
|
|
description is getting long or is being developed by several
|
|
authors, then it is convenient to divide it into several parts.
|
|
Another very important case is when you expect parts of the
|
|
description to be reused in several contexts. Clearly it is
|
|
undesirable to cut and paste sections of one document into another,
|
|
since that is error prone and leads to maintenance problems. More
|
|
importantly, you may need to reuse components that belong to a
|
|
wsdl:targetNamespace that is different than that of the document
|
|
you are writing, in which case the rules of WSDL 2.0 prevent you
|
|
from simply cutting and pasting them into your document.</p>
|
|
<p>To solve these problems, WSDL 2.0 provides two mechanisms for
|
|
modularizing Web service description documents: <code>import</code>
|
|
and <code>include</code>. This section discusses the import
|
|
mechanism and describes some typical cases where it may be
|
|
used.</p>
|
|
<p>The <code>import</code> mechanism lets one refer to the
|
|
definitions of Web service components that belong to other
|
|
namespaces. To illustrate this, consider the GreatH hotel
|
|
reservation service. Suppose that the reservation service uses a
|
|
standard credit card validation service that is provided by a
|
|
financial services company. Furthermore, suppose that companies in
|
|
the financial services industry decided that it would be useful to
|
|
report errors in credit card validation using a common set of
|
|
faults, and have defined these faults in the following Web service
|
|
description:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"credit-card-faults" id="credit-card-faults"></a><em><span>Example
|
|
3-1.</span> Standard Credit Card Validation Faults
|
|
(credit-card-faults.wsdl)</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace="http://finance.example.com/CreditCards/wsdl"
|
|
xmlns:tns="http://finance.example.com/CreditCards/wsdl"
|
|
xmlns:cc="http://finance.example.com/CreditCards/xsd">
|
|
|
|
<documentation>
|
|
This document describes standard faults for use
|
|
by Web services that process credit cards.
|
|
</documentation>
|
|
|
|
<types>
|
|
<xs:import xmlns:xs="http://www.w3.org/2001/XMLSchema"
|
|
namespace="http://finance.example.com/CreditCardFaults/xsd"
|
|
schemaLocation="credit-card-faults.xsd" />
|
|
</types>
|
|
|
|
<interface name="creditCardFaults">
|
|
|
|
<fault name="cancelledCreditCard" element="cc:CancelledCreditCard">
|
|
<documentation>Thrown when the credit card has been cancelled.</documentation>
|
|
</fault>
|
|
|
|
<fault name="expiredCreditCard" element="cc:ExpiredCreditCard">
|
|
<documentation>Thrown when the credit card has expired.</documentation>
|
|
</fault>
|
|
|
|
<fault name="invalidCreditCardNumber" element="cc:InvalidCreditCardNumber">
|
|
<documentation>Thrown when the credit card number is invalid.
|
|
This fault will occur if the wrong credit card type is specified.
|
|
</documentation>
|
|
</fault>
|
|
|
|
<fault name="invalidExpirationDate" element="cc:InvalidExpirationDate">
|
|
<documentation>Thrown when the expiration date is invalid.</documentation>
|
|
</fault>
|
|
|
|
</interface>
|
|
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<p>This example defines an interface,
|
|
<code>creditCardFaults</code>, that contains four faults,
|
|
<code>cancelledCreditCard</code>, <code>expiredCreditCard</code>,
|
|
<code>invalidCreditCardNumber</code>, and
|
|
<code>invalidExpirationDate</code>. These components belong to the
|
|
namespace
|
|
<code>http://finance.example.com/CreditCards/wsdl</code>.</p>
|
|
<p>Because these faults are defined in a different
|
|
wsdl:targetNamespace than the one used by the GreatH Web service
|
|
description, import must be used to make them available within the
|
|
GreatH Web service description, as shown in the following
|
|
example:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"use-credit-card-faults" id=
|
|
"use-credit-card-faults"></a><em><span>Example 3-2.</span> Using
|
|
the Standard Credit Card Validation Faults
|
|
(use-credit-card-faults.wsdl)</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0"?>
|
|
<description
|
|
targetNamespace="http://greath.example.com/2004/wsdl/resSvc"
|
|
xmlns:ghns="http://greath.example.com/2004/schemas/resSvc"
|
|
xmlns:cc="http://finance.example.com/CreditCards/wsdl"
|
|
xmlns="http://www.w3.org/ns/wsdl"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema">
|
|
|
|
<documentation>
|
|
Description: The definition of the reservation Web service of
|
|
GreatH hotel. Author: Joe Somebody Date: 05/17/2004
|
|
</documentation>
|
|
|
|
<import namespace="http://finance.example.com/CreditCards/wsdl"
|
|
location="credit-card-faults.wsdl"/>
|
|
. . .
|
|
<interface name="reservation" extends="cc:creditCardFaults">
|
|
. . .
|
|
<operation name="makeReservation"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
|
|
<input messageLabel="In" element="ghns:makeReservation" />
|
|
|
|
<output messageLabel="Out"
|
|
element="ghns:makeReservationResponse" />
|
|
|
|
<outfault ref="invalidDataFault" messageLabel="Out" />
|
|
|
|
<outfault ref="cc:cancelledCreditCard" messageLabel="Out" />
|
|
<outfault ref="cc:expiredCreditCard" messageLabel="Out" />
|
|
<outfault ref="cc:invalidCreditCardNumber" messageLabel="Out" />
|
|
<outfault ref="cc:invalidExpirationDate" messageLabel="Out" />
|
|
</operation>
|
|
</interface>
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<p>The hotel reservation service declares that it is using
|
|
components from another namespace via the <code>import</code>>
|
|
element. The import element has a required <code>namespace</code>
|
|
attribute that specifies the other namespace, and an optional
|
|
<code>location</code> attribute that gives the processor a hint
|
|
where to find the description of the other namespace. The
|
|
<code>reservation</code> interface extends the
|
|
<code>creditCardFault</code> interface from the other namespace in
|
|
order to make the faults available in the reservation interface.
|
|
Finally, the <code>makeReservation</code> operation refers to the
|
|
standard faults in its <code>outfault</code> elements.</p>
|
|
<p>Another typical situation for using imports is to define a
|
|
standard interface that is to be implemented by many services. For
|
|
example, suppose the hotel industry decided that it was useful to
|
|
have a standard interface for making reservations. This interface
|
|
would belong to some industry association namespace, e.g.
|
|
<code>http://hotels.example.com/reservations/wsdl</code>. Each
|
|
hotel that implemented the standard reservation service would
|
|
define a service in its own namespace, e.g.
|
|
<code>http://greath.example.com/2004/wsdl/resSvc</code>. The
|
|
description of each service would import the
|
|
<code>http://hotels.example.com/reservations/wsdl</code> namespace
|
|
and refer to the standard reservation interface in it.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="adv-multiple-inline-schemas" id=
|
|
"adv-multiple-inline-schemas"></a>3.2 Importing Schemas</h3>
|
|
<p>WSDL 2.0 documents may contain one or more XML schemas defined
|
|
within the <code>wsdl:types</code> element. This section
|
|
illustrates the correct way to refer to these schemas, both from
|
|
within the same document and from other documents.</p>
|
|
<div class="div3">
|
|
<h4><a name="id2298427" id="id2298427"></a>3.2.1 Schemas in
|
|
Imported Documents</h4>
|
|
<p>In this example, we consider some GreatH Hotel Web services that
|
|
retrieve and update reservation details. The retrieval Web service
|
|
is defined in the <code>retrieveDetails.wsdl</code> WSDL 2.0
|
|
document, along with a schema for the message format. The updating
|
|
Web service is defined in the <code>updateDetails.wsdl</code> WSDL
|
|
2.0 document which imports the first document and refers to both
|
|
WSDL 2.0 and schema definitions contained in the imported
|
|
document.</p>
|
|
<p><a href="#retrieveDetails.wsdl">Example 3-3</a> shows the
|
|
definition of the retrieval Web service in the
|
|
<code>http://greath.example.com/2004/services/retrieveDetails</code>
|
|
namespace. This WSDL 2.0 document also contains an inline schema
|
|
that describes the reservation detail in the
|
|
<code>http://greath.example.com/2004/schemas/reservationDetails</code>
|
|
namespace. This schema is visible to the
|
|
<code>retrieveDetailsInterface</code> interface definition which
|
|
refers to it in the <code>retrieve</code> operation's output
|
|
message.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"retrieveDetails.wsdl" id=
|
|
"retrieveDetails.wsdl"></a><em><span>Example 3-3.</span> The
|
|
Retrieve Reservation Details Web Service:
|
|
retrieveDetails.wsdl</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace="http://greath.example.com/2004/services/retrieveDetails"
|
|
xmlns:tns="http://greath.example.com/2004/services/retrieveDetails"
|
|
xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema">
|
|
|
|
<documentation>
|
|
This document describes the GreatH Retrieve Reservation Details
|
|
Web service.
|
|
</documentation>
|
|
|
|
<types>
|
|
<xs:schema xmlns="http://www.w3.org/2001/XMLSchema"
|
|
targetNamespace="http://greath.example.com/2004/schemas/reservationDetails">
|
|
|
|
<xs:element name="reservationDetails">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element name="confirmationNumber"
|
|
type="string" />
|
|
<xs:element name="checkInDate" type="date" />
|
|
<xs:element name="checkOutDate" type="date" />
|
|
<xs:element name="roomType" type="string" />
|
|
<xs:element name="smoking" type="boolean" />
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
</types>
|
|
|
|
<interface name="retrieveDetailsInterface">
|
|
|
|
<operation name="retrieve"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In" element="#none" />
|
|
<output messageLabel="Out"
|
|
element="wdetails:reservationDetails" />
|
|
</operation>
|
|
|
|
</interface>
|
|
|
|
</description>
|
|
|
|
</pre></div>
|
|
</div>
|
|
<p><a href="#updateDetails.wsdl">Example 3-4</a> shows the
|
|
definition of the updating Web service in the
|
|
<code>http://greath.example.com/2004/services/updateDetails</code>
|
|
namespace. The <code>updateDetailsInterface</code> interface
|
|
extends the <code>retrieveDetailsInterface</code> interface.
|
|
However, the <code>retrieveDetailsInterface</code> belongs to the
|
|
<code>http://greath.example.com/2004/services/retrieveDetails</code>
|
|
namespace, so <code>updateDetails.wsdl</code> must import
|
|
<code>retrieveDetails.wsdl</code> to make that namespace
|
|
visible.</p>
|
|
<p>The <code>updateDetailsInterface</code> interface also uses the
|
|
<code>reservationDetails</code> element definition that is
|
|
contained in the inline schema of the imported
|
|
<code>retrieveDetails.wsdl</code> document. However, this schema is
|
|
not automatically visible within the
|
|
<code>updateDetails.wsdl</code> document. To make it visible, the
|
|
<code>updateDetails.wsdl</code> document must import the namespace
|
|
of the inline schema within the <code>types</code> element using
|
|
the XML schema <code>import</code> element.</p>
|
|
<p>In this example, the <code>schemaLocation</code> attribute of
|
|
the <code>import</code> element has been omitted. The
|
|
<code>schemaLocation</code> attribute is a hint to the WSDL 2.0
|
|
processor that tells it where to look for the imported schema
|
|
namespace. However, the WSDL 2.0 processor has already processed
|
|
the <code>retrieveDetails.wsdl</code> document which contains the
|
|
imported namespace in an inline schema so it should not need any
|
|
hints. However, this behavior depends on the implementation of the
|
|
processor and so cannot be relied on.</p>
|
|
<p>Although the WSDL 2.0 document may validly omit the
|
|
<code>schemaLocation</code> attribute, it is a best practice to
|
|
either provide a reliable value for it or move the inline schema
|
|
into a separate document, say <code>reservationDetails.xsd</code>,
|
|
and directly import it in the <code>types</code> element of both
|
|
<code>retrieveDetails.wsdl</code> and
|
|
<code>updateDetails.wsdl</code>. In general, schemas that are
|
|
expected to be referenced from more than one WSDL 2.0 document
|
|
should be defined in a separate schema document rather than be
|
|
inlined.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"updateDetails.wsdl" id="updateDetails.wsdl"></a><em><span>Example
|
|
3-4.</span> The Update Reservation Details Web Service:
|
|
updateDetails.wsdl</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace="http://greath.example.com/2004/services/updateDetails"
|
|
xmlns:tns="http://greath.example.com/2004/services/updateetails"
|
|
xmlns:retrieve="http://greath.example.com/2004/services/retrieveDetails"
|
|
xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema">
|
|
|
|
<documentation>
|
|
This document describes the GreatH Update Reservation Details
|
|
Web service.
|
|
</documentation>
|
|
|
|
<import
|
|
namespace="http://greath.example.com/2004/services/retrieveDetails"
|
|
location="retrieveDetails.wsdl" />
|
|
|
|
<types>
|
|
<xs:import
|
|
namespace="http://greath.example.com/2004/schemas/reservationDetails" />
|
|
</types>
|
|
|
|
<interface name="updateDetailsInterface"
|
|
extends="retrieve:retrieveDetailsInterface">
|
|
|
|
<operation name="update"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In"
|
|
element="details:reservationDetails" />
|
|
<output messageLabel="Out"
|
|
element="details:reservationDetails" />
|
|
</operation>
|
|
|
|
</interface>
|
|
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="id2298802" id="id2298802"></a>3.2.2 Multiple Inline
|
|
Schemas in One Document</h4>
|
|
<p>A WSDL 2.0 document may define multiple inline schemas in its
|
|
<code>types</code> element. The two or more schemas may have the
|
|
same target namespace provided that they do not define the same
|
|
elements or types. It is an error to define the same element or
|
|
type more than once, even if the definitions are identical.</p>
|
|
<p>Each namespace of an inline schema becomes visible to the Web
|
|
service definitions. However, the namespaces are not automatically
|
|
visible to the other inline schemas. Each inline schema must
|
|
explicitly import any other namespace it references. The
|
|
<code>schemaLocation</code> attribute is not required in this case
|
|
since the WSDL 2.0 processor knows the location of each schema by
|
|
virtue of having processed the enclosing WSDL 2.0 document.</p>
|
|
<p>To illustrate this, consider <a href=
|
|
"#retrieveItems.wsdl">Example 3-5</a> which contains two inline
|
|
schemas. The
|
|
<code>http://greath.example.com/2004/schemas/reservationItems</code>
|
|
namespace contains some elements for items that appear in the
|
|
reservation details. The
|
|
<code>http://greath.example.com/2004/schemas/reservationDetails</code>
|
|
namespace contains the <code>reservationDetails</code> element
|
|
which refers to the item elements. The schema for the
|
|
<code>http://greath.example.com/2004/schemas/reservationDetails</code>
|
|
namespace contains an <code>import</code> element that imports the
|
|
<code>http://greath.example.com/2004/schemas/reservationItems</code>
|
|
namespace. No <code>schemaLocation</code> attribute is required for
|
|
this import since the schema is defined inline in the importing
|
|
document.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"retrieveItems.wsdl" id="retrieveItems.wsdl"></a><em><span>Example
|
|
3-5.</span> Multiple Inline Schemas: retrieveItems.wsdl</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace="http://greath.example.com/2004/services/retrieveDetails"
|
|
xmlns:tns="http://greath.example.com/2004/services/retrieveDetails"
|
|
xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema">
|
|
|
|
<documentation>
|
|
This document describes the GreatH Retrieve Reservation Details
|
|
Web service.
|
|
</documentation>
|
|
|
|
<types>
|
|
|
|
<xs:schema targetNamespace="http://greath.example.com/2004/schemas/reservationItems">
|
|
|
|
<xs:element name="confirmationNumber" type="string" />
|
|
<xs:element name="checkInDate" type="date" />
|
|
<xs:element name="checkOutDate" type="date" />
|
|
<xs:element name="roomType" type="string" />
|
|
<xs:element name="smoking" type="boolean" />
|
|
|
|
</xs:schema>
|
|
|
|
<xs:schema targetNamespace="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:items="http://greath.example.com/2004/schemas/reservationItems">
|
|
|
|
<xs:import
|
|
namespace="http://greath.example.com/2004/schemas/reservationItems" />
|
|
|
|
<xs:element name="reservationDetails">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element ref="items:confirmationNumber" />
|
|
<xs:element ref="items:checkInDate" />
|
|
<xs:element ref="items:checkOutDate" />
|
|
<xs:element ref="items:roomType" />
|
|
<xs:element ref="items:smoking" />
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</types>
|
|
|
|
<interface name="retrieveDetailsInterface">
|
|
|
|
<operation name="retrieve"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In" element="#none" />
|
|
<output messageLabel="Out"
|
|
element="wdetails:reservationDetails" />
|
|
</operation>
|
|
|
|
</interface>
|
|
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="adv-schema-location" id=
|
|
"adv-schema-location"></a>3.2.3 The schemaLocation Attribute</h4>
|
|
<p>In the preceding examples, schemas were defined inline in WSDL
|
|
2.0 documents. This section discusses the correct way to specify a
|
|
<code>schemaLocation</code> attribute on a schema
|
|
<code>import</code> element to provide a processor with a hint for
|
|
locating these schemas.</p>
|
|
<p><a href="#updateDetails.wsdl">Example 3-4</a> shows how one WSDL
|
|
2.0 document imports a schema defined in another, i.e. <a href=
|
|
"#retrieveDetails.wsdl">Example 3-3</a>. Similarly, <a href=
|
|
"#retrieveItems.wsdl">Example 3-5</a> shows how one schema in a
|
|
WSDL 2.0 document imports another schema defined in the same
|
|
document. In both of these examples, the
|
|
<code>schemaLocation</code> attribute was omitted since the WSDL
|
|
2.0 processor was assumed to know how to locate the imported
|
|
schemas because they were part of the WSDL 2.0 documents being
|
|
processed. The <code>schemaLocation</code> attribute can be used to
|
|
give the processor a URI reference that explicitly locates the
|
|
schemas. A URI reference is a URI plus an optional fragment
|
|
identifier that indicates part of the resource. For schemas, the
|
|
fragment should identify the <code>schema</code> element. The
|
|
simplest way to accomplish this is to use the <code>id</code>
|
|
attribute, however XPointer (see [<cite><a href="#XPTR">XPointer
|
|
Framework</a></cite>]) can also be used.</p>
|
|
<div class="div4">
|
|
<h5><a name="id2299144" id="id2299144"></a>3.2.3.1 Using the id
|
|
Attribute to Identify Inline Schemas</h5>
|
|
<p><a href="#schemaIds.wsdl">Example 3-6</a> shows the use of the
|
|
<code>id</code> attribute. Both of the inline schemas have
|
|
<code>id</code> attributes. The id of the
|
|
<code>http://greath.example.com/2004/schemas/reservationItems</code>
|
|
schema is <code>items</code> and the id of the
|
|
<code>http://greath.example.com/2004/schemas/reservationDetails</code>
|
|
schema is <code>details</code>. The <code>import</code> element in
|
|
the
|
|
<code>http://greath.example.com/2004/schemas/reservationDetails</code>
|
|
schema uses the id of the
|
|
<code>http://greath.example.com/2004/schemas/reservationItems</code>
|
|
schema in the <code>schemaLocation</code> attribute, i.e.
|
|
<code>#items</code>.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"schemaIds.wsdl" id="schemaIds.wsdl"></a><em><span>Example
|
|
3-6.</span> Using Ids in Inline Schemas: schemaIds.wsdl</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace="http://greath.example.com/2004/services/retrieveDetails"
|
|
xmlns:tns="http://greath.example.com/2004/services/retrieveDetails"
|
|
xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema">
|
|
|
|
<documentation>
|
|
This document describes the GreatH Retrieve Reservation Details
|
|
Web service.
|
|
</documentation>
|
|
|
|
<types>
|
|
|
|
<xs:schema id="items"
|
|
targetNamespace="http://greath.example.com/2004/schemas/reservationItems">
|
|
|
|
<xs:element name="confirmationNumber" type="string" />
|
|
<xs:element name="checkInDate" type="date" />
|
|
<xs:element name="checkOutDate" type="date" />
|
|
<xs:element name="roomType" type="string" />
|
|
<xs:element name="smoking" type="boolean" />
|
|
|
|
</xs:schema>
|
|
|
|
<xs:schema id="details"
|
|
targetNamespace="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:items="http://greath.example.com/2004/schemas/reservationItems">
|
|
|
|
<xs:import
|
|
namespace="http://greath.example.com/2004/schemas/reservationItems"
|
|
schemaLocation="#items" />
|
|
|
|
<xs:element name="reservationDetails">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element ref="items:confirmationNumber" />
|
|
<xs:element ref="items:checkInDate" />
|
|
<xs:element ref="items:checkOutDate" />
|
|
<xs:element ref="items:roomType" />
|
|
<xs:element ref="items:smoking" />
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
</xs:schema>
|
|
|
|
</types>
|
|
|
|
<interface name="retrieveDetailsInterface">
|
|
|
|
<operation name="retrieve"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In" element="#none" />
|
|
<output messageLabel="Out"
|
|
element="wdetails:reservationDetails" />
|
|
</operation>
|
|
|
|
</interface>
|
|
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="advanced-topic_iii" id="advanced-topic_iii"></a>4.
|
|
Advanced Topics II: Extensibility and Predefined Extensions</h2>
|
|
<div class="div2">
|
|
<h3><a name="adv-extensibility" id="adv-extensibility"></a>4.1
|
|
Extensibility</h3>
|
|
<p>WSDL 2.0 provides an open content model, which allows XML
|
|
elements and attributes from other (non-WSDL 2.0) XML namespaces to
|
|
be interspersed in a WSDL 2.0 document. The qualified name
|
|
(complete with namespace URI) of the extension element or attribute
|
|
acts as an unambiguous name for the semantics of that
|
|
extension.</p>
|
|
<p>The namespace URI of the extension element should be
|
|
dereferenceable to a document that describes the semantics of that
|
|
extension. As of this writing, there is no generally accepted
|
|
standard for what kind of document that should be. However, the
|
|
<a href="http://www.w3.org/2001/tag/">W3C TAG</a> has been
|
|
discussing the issue (see TAG issue <a href=
|
|
"http://www.w3.org/2001/tag/issues.html?type=1#namespaceDocument-8">
|
|
namespaceDocument-8</a>) and is likely to provide guidance at some
|
|
point.</p>
|
|
<div class="div3">
|
|
<h4><a name="adv-optional-versus-required" id=
|
|
"adv-optional-versus-required"></a>4.1.1 Optional Versus Required
|
|
Extensions</h4>
|
|
<p>Extensions can either be required or optional.</p>
|
|
<p>An <em>optional</em> extension is one that the client may either
|
|
engage or ignore, entirely at its discretion, and is signaled by
|
|
<code>wsdl:required="false"</code> or the absence of the
|
|
<code>wsdl:required</code> attribute (because it defaults to
|
|
false). Thus, a WSDL 2.0 processor, acting on behalf of the client,
|
|
that encounters an unknown optional extension can safely ignore it
|
|
and continue to process the WSDL 2.0 document. However, it is
|
|
important to stress that optional extensions are only optional to
|
|
the <em>client</em> -- not the service. A service must support all
|
|
optional and required extensions that it advertises in its WSDL 2.0
|
|
document.</p>
|
|
<p>A <em>required</em> extension is one that must be supported and
|
|
engaged by the client in order for the interaction to proceed
|
|
properly, and is signaled by <code>wsdl:required="true"</code>. If
|
|
a WSDL 2.0 processor, acting on behalf of the client, encounters a
|
|
required extension that it does not recognize or does not support,
|
|
then it cannot safely continue to process the WSDL 2.0 document. In
|
|
most practical cases, this is likely to mean that the processor
|
|
will require manual intervention to deal with the extension. For
|
|
example, a client developer might manually provide an
|
|
implementation for the required extension to the WSDL 2.0
|
|
processor.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="adv-MEP" id="adv-MEP"></a>4.2 Defining New MEPs</h3>
|
|
<p>As we mentioned in <a href=
|
|
"#more-interfaces-meps"><strong>2.4.4.3 Understanding Message
|
|
Exchange Patterns (MEPs)</strong></a>, even though the 8 MEPs
|
|
defined by WSDL 2.0 are intended to cover most of the common use
|
|
cases, there are situations that require new MEPs to be defined. In
|
|
this section, we will explain how new MEPs can be defined to
|
|
address special business requirements.</p>
|
|
<p>Following the wild success of its reservation service, GreatH
|
|
discovered that it could radically increase tourist interest by
|
|
supplying information on weather conditions, both to travel agents
|
|
and to the general touring public. This produced a challenge for
|
|
the service implementers: how could this information be supplied to
|
|
interested parties without requiring knowledge of web service
|
|
technology specifically, and of computers generally? At issue was
|
|
the desire to provide asynchronous updates to unsophisticated
|
|
customers without incurring onerous overheads for technical
|
|
support.</p>
|
|
<p>The solution adopted was to create a standard mailing list, and
|
|
to make available a small cross-platform web service client
|
|
(actually, a subscriber) that could be installed on any computer
|
|
with POP or IMAP access to a mailbox. The mailbox, once signed up
|
|
for the mailing list, could either be processed as "dedicated" (to
|
|
the GreatH weather service; travel agents did this) or as "general
|
|
purpose" (in which case the application would only examine those
|
|
emails that contained Subject headers associated with the service).
|
|
This required development of a binding to email, which is out of
|
|
scope for this example, but the resulting WSDL 2.0 was otherwise
|
|
quite straightforward.</p>
|
|
<p>Note: the email binding in use here supports publish/subscribe,
|
|
by supporting the robust-out-only MEP as well as the client/server
|
|
style in-out used for subscribing and unsubscribing. Details of
|
|
this binding would require a document as long as the primer, so
|
|
play along.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"weather-not-initial" id=
|
|
"weather-not-initial"></a><em><span>Example 4-1.</span> Weather
|
|
Notification Service (Initial)</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace="http://greath.example.com/2004/wsdl/weathSvc.wsdl"
|
|
xmlns:tns="http://greath.example.com/2004/wsdl/weathSvc.wsdl"
|
|
xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
|
|
xmlns:email="http://www.example.com/webservices/email" >
|
|
|
|
<types>
|
|
. . .
|
|
</types>
|
|
|
|
<interface name="weatherInterface">
|
|
<operation name="opSubscribeWeather"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input element=". . ." />
|
|
<output element=". . ." />
|
|
</operation>
|
|
<operation name="opUnsubscribeWeather"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<output element=". . ." />
|
|
<input element=". . ." />
|
|
</operation>
|
|
<operation name="opNotifyWeather"
|
|
pattern="http://www.w3.org/ns/wsdl/robust-out-only">
|
|
<output element=". . ." />
|
|
</operation>
|
|
</interface>
|
|
|
|
<binding name="weatherMailingListBinding"
|
|
interface="tns:weatherInterface
|
|
type="http://www.w3.org/ns/wsdl/soap"
|
|
wsoap:protocol="http://www.example.com/bindings/email">
|
|
. . .
|
|
</binding>
|
|
|
|
<service name="weatherService"
|
|
interface="tns:weatherInterface">
|
|
<endpoint name="greatHWeatherList"
|
|
binding="tns:weatherMailingListBinding"
|
|
address="mailto:weather-owner@greath.example.com" />
|
|
</service>
|
|
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<p>Note: in the example, the messageLabels of all input and output
|
|
elements have been elided, as they are not necessary to
|
|
disambiguate (but note that the order of input and output elements
|
|
is not significant).</p>
|
|
<p>Unfortunately, the service was soon highjacked for the purpose
|
|
of annoyment. Repeatedly, hotels in less salubrious climes, and the
|
|
victims of various natural climactic disasters (hurricanes,
|
|
tornadoes) found themselves signed up to receive material full of
|
|
incomprehensible pointy brackets. They complained to GreatH, who
|
|
complained to their service designers.</p>
|
|
<p>Applying public key infrastructure to solving the problem was
|
|
immediately rejected as too complex and too heavyweight. Analysis
|
|
showed that the problem was simply to verify that the address
|
|
requesting information actually wanted that information.
|
|
Consequently, a new message exchange pattern was defined.</p>
|
|
<div class="div3">
|
|
<h4><a name="challenge-confirm" id="challenge-confirm"></a>4.2.1
|
|
Confirmed Challenge</h4>
|
|
<p>This pattern consists of two or more messages in order as
|
|
follows:</p>
|
|
<ol class="enumar">
|
|
<li>
|
|
<p>A message:</p>
|
|
<ul>
|
|
<li>
|
|
<p>indicated by a Message Label component whose message label is
|
|
"Request" and direction is "in"</p>
|
|
</li>
|
|
<li>
|
|
<p>received from some node N1</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<p>A message:</p>
|
|
<ul>
|
|
<li>
|
|
<p>indicated by a Message Label component whose message label is
|
|
"Challenge" and direction is "out"</p>
|
|
</li>
|
|
<li>
|
|
<p>sent to some node N2 (which <em>may</em> be the same node as
|
|
N1)</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<p>An optional message:</p>
|
|
<ul>
|
|
<li>
|
|
<p>indicated by a Message Label component whose message label is
|
|
"Confirmation" and direction is "in"</p>
|
|
</li>
|
|
<li>
|
|
<p>received from node N2</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<p>An optional message:</p>
|
|
<ul>
|
|
<li>
|
|
<p>indicated by a Message Label component whose message label is
|
|
"Response" and direction is "out"</p>
|
|
</li>
|
|
<li>
|
|
<p>sent to node N2</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ol>
|
|
<p>This pattern uses the rule Message Triggers Fault.</p>
|
|
<p>An operation using this message exchange pattern has a pattern
|
|
property with the value
|
|
"http://www.example.com/webservices/meps/confirmed-challenge".</p>
|
|
<p>Once the MEP had been defined (and the email binding
|
|
specification appropriately modified to indicate that this was a
|
|
supported MEP), the service was redefined and redeployed. Only the
|
|
changed operations are shown in the excerpt below.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"weather-not-final" id="weather-not-final"></a><em><span>Example
|
|
4-2.</span> Weather Notification Service (Revised)</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace="http://greath.example.com/2004/wsdl/weathSvc.wsdl"
|
|
xmlns:tns="http://greath.example.com/2004/wsdl/weathSvc.wsdl"
|
|
xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
|
|
xmlns:email="http://www.example.com/webservices/email" >
|
|
|
|
. . .
|
|
|
|
<interface name="weatherInterface">
|
|
<operation name="opSubscribeWeather"
|
|
pattern="http://www.example.com/webservices/meps/confirmed-challenge">
|
|
<input messageLabel="Request" element=". . ." />
|
|
<output messageLabel="Challenge" element=". . ." />
|
|
<input messageLabel="Confirmation" element=". . ." />
|
|
<output messageLabel="Response" element=". . ." />
|
|
</operation>
|
|
<operation name="opUnsubscribeWeather"
|
|
pattern="http://www.example.com/webservices/meps/confirmed-challenge">
|
|
<output messageLabel="Challenge" element=". . ." />
|
|
<output messageLabel="Response" element=". . ." />
|
|
<input messageLabel="Confirmation" element=". . ." />
|
|
<input messageLabel="Request" element=". . ." />
|
|
</operation>
|
|
. . .
|
|
</interface>
|
|
|
|
. . .
|
|
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<p>Note: in the second example, the input and output examples are
|
|
not in the sequence in which they occur in the pattern; this
|
|
illustrates that the sequence is not significant. Note, however,
|
|
that for this pattern, the messageLabel attribute is required on
|
|
every input and output element.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="adv-RPCstyle" id="adv-RPCstyle"></a>4.3 RPC Style</h3>
|
|
<p>Section <a href="#more-interfaces-op-attr"><strong>2.4.4.1
|
|
Operation Attributes</strong></a> mentioned that the (optional)
|
|
<code>style</code> attribute of an interface operation is used to
|
|
indicate that the operation conforms to a particular pre-defined
|
|
operation style, or set of constraints. Actually, if desired the
|
|
<code>style</code> attribute can hold a list of URIs, indicating
|
|
that the operation simultaneously conforms to multiple styles.</p>
|
|
<p>Operation styles are named using URIs, in order to be
|
|
unambiguous while still permitted new styles to be defined without
|
|
requiring updates to the WSDL 2.0 language. WSDL 2.0 Part 2
|
|
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] defines
|
|
three such operation styles; one of these is the RPC Style
|
|
(<a href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#RPCStyle">RPC
|
|
Style</a>).</p>
|
|
<p>The <em>RPC Style</em> is designed to facilitate programming
|
|
language bindings to WSDL 2.0 constructs. It allows a WSDL 2.0
|
|
interface operation to be easily mapped to a method or function
|
|
signature, such as a method signature in Java(TM) or C#. RPC Style
|
|
is restricted to operations that use the In-Out or In-Only MEPs
|
|
(see <a href="#more-interfaces-meps"><strong>2.4.4.3 Understanding
|
|
Message Exchange Patterns (MEPs)</strong></a>).</p>
|
|
<p>A WSDL 2.0 document makes use of the RPC Style in an interface
|
|
operation by first defining the operation in conformance with all
|
|
of the RPC Style rules, and then setting that operation's
|
|
<code>style</code> attribute to include the URI that identifies the
|
|
RPC Style, thus asserting that the operation does indeed conform to
|
|
the RPC Style. These rules permit the input and output message
|
|
schemas to map conveniently to inputs and outputs of a method
|
|
signature. Roughly, input elements map to input parameters, output
|
|
elements map to output parameters, and elements that appear both in
|
|
the input and output message schemas map to input/output
|
|
parameters. WSDL 2.0 Part 2 section "<a href=
|
|
"http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#RPCStyle">RPC
|
|
Style</a>" provides full details of the mapping rules and
|
|
requirements.</p>
|
|
<p>The RPC Style also permits the full signature of the intended
|
|
mapping to be indicated explicitly, using the
|
|
<code>wrpc:signature</code> attribute defined in WSDL 2.0 Part 2
|
|
section "<a href=
|
|
"http://www.w3.org/2002/ws/desc/wsdl20-adjuncts">wrpc:signature
|
|
Extension</a>". This is an (optional) extension to the WSDL 2.0
|
|
language whose value designates how input and output message schema
|
|
elements map to input and output parameters in the method
|
|
signature.</p>
|
|
<p>The example below illustrates how RPC Style may be used to
|
|
designate a signature. This example is a modified version of the
|
|
GreatH reservation service. In particular, the
|
|
<code>interface</code> and <code>types</code> sections have been
|
|
modified to specify and conform to the RPC Style.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-rpc-style" id="example-rpc-style"></a><em><span>Example
|
|
4-3.</span> Specifying RPC Style</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
. . .
|
|
<types>
|
|
|
|
<xs:element name="checkAvailability">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element name="checkInDate" type="xs:date"/>
|
|
<xs:element name="checkOutDate" type="xs:date"/>
|
|
<xs:element name="roomType" type="xs:string"/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
|
|
<xs:element name="checkAvailabilityResponse">
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element name="roomType" type="xs:string"/>
|
|
<xs:element name="rateType" type="xs:string"/>
|
|
<xs:element name="rate" type="xs:double"/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
. . .
|
|
</types>
|
|
|
|
<interface name = "reservationInterface" >
|
|
|
|
<operation name="checkAvailability"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out"
|
|
style="http://www.w3.org/ns/wsdl/rpc"
|
|
wrpc:signature=
|
|
"checkInDate #in checkOutDate #in roomType #inout rateType #out rate #return">
|
|
<input messageLabel="In"
|
|
element="tns:checkAvailability" />
|
|
<output messageLabel="Out"
|
|
element="tns:checkAvailabilityResponse" />
|
|
|
|
</operation>
|
|
. . .
|
|
</interface>
|
|
. . .
|
|
</pre></div>
|
|
</div>
|
|
<p>Note that the interface operation's name
|
|
"<code>checkAvailability</code>", is the same as the localPart of
|
|
the input element's QName, "<code>tns:checkAvailability</code>".
|
|
This is one of the requirements of the RPC Style. The name of the
|
|
operation is used as the name of the method in a language binding,
|
|
subject to further mapping restrictions specific to the target
|
|
programming language. In this case, the name of the method would be
|
|
"<code>checkAvailability</code>".</p>
|
|
<p>The local children elements of the input element and output
|
|
element designate the parameters and the return type for a method
|
|
call. Note that the elements <code>checkInDate</code>,
|
|
<code>checkOutDate</code> are input parameters, however the element
|
|
<code>roomType</code> is an in-out parameter, as it appears both as
|
|
a local element child of both input and output elements. This
|
|
indicates that the reservation system may change the room type
|
|
requested based on availability.</p>
|
|
<p>The reservation service also returns a rate type for the
|
|
reservation, such as "rack rate". The return value for the method
|
|
is designated as the "rate" element.</p>
|
|
<p>Based on the value of the <code>wrpc:signature</code> attribute,
|
|
the method signature would be obtained following the order of the
|
|
parameters. A sample mapping is provided below for the Java(TM)
|
|
language. This example was created using JAX RPC 1.1
|
|
[<cite><a href="#jaxrpc">JAX RPC 1.1</a></cite>] for mapping simple
|
|
types to Java types and designated inout and output parameters by
|
|
using Holder classes.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-rpc-style-java-sig" id=
|
|
"example-rpc-style-java-sig"></a><em><span>Example 4-4.</span>
|
|
Sample Java(TM) Signature for RPC Style</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
public interface reservationInterface extends Remote{
|
|
|
|
double checkAvailability(java.util.calendar checkInDate,
|
|
java.util.calendar checkOutDate,
|
|
StringHolder roomType,
|
|
StringHolder rateType) throws RemoteException;
|
|
. . .
|
|
}
|
|
</pre></div>
|
|
</div>
|
|
<p>Programming languages may further specify how faults are mapped
|
|
to language constructs and their scopes, such as Exceptions, but
|
|
they are not specific to RPC style.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="advanced-topic_iv" id="advanced-topic_iv"></a>5.
|
|
Advanced Topics III: Miscellaneous</h2>
|
|
<p>This section covers various topics that may fall outside the
|
|
scope of WSDL 2.0, but shall provide useful background and best
|
|
practice guidances that may be useful when authoring a WSDL 2.0
|
|
document or implementing the WSDL 2.0 specification.</p>
|
|
<div class="div2">
|
|
<h3><a name="adv-message-dispatch" id=
|
|
"adv-message-dispatch"></a>5.1 Enabling Easy Message Dispatch</h3>
|
|
<p>It is desirable for a message recipient to have the capability
|
|
to uniquely identify a message type in order to handle it
|
|
correctly. The capability of identifying a message type is
|
|
typically used for dispatching purposes within an implementation of
|
|
a web service. Therefore, WSDL authors are recommended to consider
|
|
how to disambiguate message types when they develop their
|
|
services.</p>
|
|
<p>The context in which a Web service may be deployed plays an
|
|
important role in choosing an appropriate way to disambiguate and
|
|
identify message types. In a typical deployment, an endpoint
|
|
address may host a single service that is described by a WSDL
|
|
service element. In this case, when XSD is used, assigning unique
|
|
qualified names of global element declarations as inputs within the
|
|
interface that describes the service would be sufficient to
|
|
disambiguate the types of the messages that are received. However,
|
|
when endpoint address hosts multiple services, in essence
|
|
supporting several WSDL descriptions, the desire to disambiguate
|
|
message types should be considered within the context of all the
|
|
deployed services, not only within a single interface.</p>
|
|
<p>As explained in <a href=
|
|
"#more-interfaces-op-attr"><strong>2.4.4.1 Operation
|
|
Attributes</strong></a>, when XSD is used as the type system, a few
|
|
special tokens can be used for the <code>element</code> attributes.
|
|
Uniquely identifying a message type may become very difficult
|
|
when:</p>
|
|
<ul>
|
|
<li>
|
|
<p>any of these input elements within an interface has a value of
|
|
"#any"; or</p>
|
|
</li>
|
|
<li>
|
|
<p>more than one of these input elements (see below) has a value of
|
|
"#none"; or</p>
|
|
</li>
|
|
<li>
|
|
<p>the qualified names of the global element declarations that are
|
|
specified as input elements are NOT unique when considered
|
|
together.</p>
|
|
</li>
|
|
</ul>
|
|
<p>If any of the three cases above arise, disambiguation mechanisms
|
|
may be provided by means of an extension element (i.e., an element
|
|
that is not in the http://www.w3.org/ns/wsdl namespace), having a
|
|
wsdl:required attribute with a value of "true". The semantics of
|
|
such an extension element would indicate the mechanism for
|
|
unambiguously identifing the mechanism that a message sender is
|
|
required to support in order to enable the message recipient to
|
|
unambiguously determine the message received.</p>
|
|
<p>For example, the WS-Addressing [<cite><a href=
|
|
"#WS-A">WS-Addressing</a></cite>] specification provides such a
|
|
disambiguation mechanism. It consists of an extension element which
|
|
may be marked as required, and defines a required [action] property
|
|
whose value is always present in a conformant message delivery. The
|
|
value of the action property can be used to disambiguate the
|
|
message by the receiver and there is a well defined way to
|
|
associate actions to messages in WS-Addressing specifications.
|
|
Further, WS-Addressing also provides an appropriate default action
|
|
value that identifies each message type uniquely.</p>
|
|
<p>When using the HTTP Binding, or when using the SOAP Binding with
|
|
the SOAP Response MEP, there is no SOAP envelope in a request
|
|
message, and thus mechanisms other than unique qualified names of
|
|
global element declarations, or headers such as wsa:Action, must be
|
|
considered. In these cases, the {address} and {http location}
|
|
properties may be constructed so as to provide a location that can
|
|
be correlated uniquely with an operation. For instance, one could
|
|
prefix the {http location} property with the operation name, or one
|
|
could ensure that the portion of the {http location} preceding the
|
|
first unescaped "{" character be unique per operation.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="adv-versioning" id="adv-versioning"></a>5.2 Web
|
|
Service Versioning</h3>
|
|
<p>A WSDL 2.0 document describes a set of messages that a Web
|
|
service may send and receive. In essence, it describes a language
|
|
for interacting with that service. However it is possible for a Web
|
|
service to exchange other messages beyond those described in a
|
|
particular WSDL 2.0 document. Often this circumstance occurs
|
|
following an evolution of the client and/or service, and thus an
|
|
evolution of the interaction language.</p>
|
|
<p>How best to manage the evolution (versioning) of Web based
|
|
systems is, at the time of writing, the subject of a wide-ranging
|
|
debate. However, there are three activities within the W3C that are
|
|
directly relevant to versioning of Web services description:</p>
|
|
<ul>
|
|
<li>
|
|
<p>The <a href="http://www.w3.org/2001/tag/">Technical Architecture
|
|
Group (TAG)</a> has published guidance on the extensibility and
|
|
versioning of data formats in its Web Architecture document
|
|
[<cite><a href="#webarch">Web Architecture</a></cite>]. There is
|
|
also a more wide ranging draft finding on Versioning and
|
|
Extensibility [<cite><a href="#TAG-versioning">W3C TAG Finding:
|
|
Extending and Versioning Languages Part 1</a></cite>]. Both of
|
|
these works build upon the technical note on Web Architecture:
|
|
Extensible Languages [<cite><a href="#web-extensible">WebArch:
|
|
Extensible Languages</a></cite>].</p>
|
|
</li>
|
|
<li>
|
|
<p>The <a href="http://www.w3.org/XML/Schema">XML Schema Working
|
|
Group</a> is collecting a series of use cases for schema versioning
|
|
as a part of the Schema 1.1 activity. See XML Schema Versioning Use
|
|
Cases [<cite><a href="#xsd-versioning">XML Schema: Versioning
|
|
Use-Cases</a></cite>].</p>
|
|
</li>
|
|
<li>
|
|
<p>The Guide to Versioning XML Languages using XML Schema 1.1
|
|
[<cite><a href="#xsd-versioning-guide">Guide to Versioning XML
|
|
Languages using XML Schema 1.1</a></cite>] illustrates some
|
|
techniques for versioning XML languages enabled by features of XML
|
|
Schema 1.1 [<cite><a href="#xsd11">XML Schema 1.1</a></cite>].</p>
|
|
</li>
|
|
<li>
|
|
<p>The <a href="http://www.w3.org/2001/sw/BestPractices/">Semantic
|
|
Web Best Practices and Deployments Working Group</a> is examining
|
|
how vocabularies may evolve. See [<cite><a href="#sw-vocabulary">SW
|
|
VocabManagementNote</a></cite>]</p>
|
|
</li>
|
|
</ul>
|
|
<p>While incomplete, these activities all agree in one important
|
|
respect: that versioning is difficult, but you should anticipate
|
|
and plan for change.</p>
|
|
<p>The draft finding on Versioning and Extensibility details two
|
|
key approaches to versioning:</p>
|
|
<ul>
|
|
<li>
|
|
<p>compatible evolution; and</p>
|
|
</li>
|
|
<li>
|
|
<p>big bang.</p>
|
|
</li>
|
|
</ul>
|
|
<div class="div3">
|
|
<h4><a name="adv-versioning-compatible-evolution" id=
|
|
"adv-versioning-compatible-evolution"></a>5.2.1 Compatible
|
|
Evolution</h4>
|
|
<p>In <em>compatible evolution</em>, designers are expected to
|
|
limit changes to those that are either backward or forward
|
|
compatible, or both:</p>
|
|
<dl>
|
|
<dt class="label">Backward compatible</dt>
|
|
<dd>
|
|
<p>The receiver behaves correctly if it receives a message in an
|
|
<em>older</em> version of the interaction language.</p>
|
|
</dd>
|
|
<dt class="label">Forward compatible</dt>
|
|
<dd>
|
|
<p>The receiver behaves correctly if it receives a message in a
|
|
<em>newer</em> version of the interaction language.</p>
|
|
</dd>
|
|
</dl>
|
|
<p>Since Web services and their clients both send and receive
|
|
messages, these concepts can apply to both parties. However, since
|
|
WSDL 2.0 is service-centric, we will focus on the case of service
|
|
evolution.</p>
|
|
<p>There are three critical areas in which a service described in
|
|
WSDL 2.0 my evolve:</p>
|
|
<ul>
|
|
<li>
|
|
<p>The service now also supports additional binding. In compatible
|
|
evolution, this should be a safe addition, given that adding a new
|
|
binding should not impact any existing interactions using another
|
|
transport.</p>
|
|
</li>
|
|
<li>
|
|
<p>An interface supports new operations. Again, in compatible
|
|
evolution this is usually safe, given that adding an additional
|
|
operation to an abstract interface should not impact any existing
|
|
interactions.</p>
|
|
</li>
|
|
<li>
|
|
<p>The message bodies may include additional data. How the message
|
|
contents may change within a description depends to a large extent
|
|
upon the type system being used to describe the message contents.
|
|
RelaxNG [<cite><a href="#relax-ng">RELAX NG</a></cite>] has good
|
|
support for describing vocabularies that ignore unknown XML, as
|
|
does OWL/RDF. XML Schema 1.0 has limited support for extending the
|
|
description of a message via the <code>xs:any</code> and
|
|
<code>xs:anyAttribute</code> constructs. XML Schema 1.1 has been
|
|
chartered to provide "changes necessary to provide better support
|
|
for versioning of schemas", and it is anticipated that this may
|
|
include improved support for more "open content" and therefore
|
|
better support for compatible evolution of messages.</p>
|
|
</li>
|
|
<li>
|
|
<p>The protocol used to exchange messages may provide mechanisms
|
|
for exchanging data outside of the message body. In the case of
|
|
SOAP, the WSDL 2.0 binding provides the ability to describe
|
|
application data to be exchanged as headers. The SOAP processing
|
|
model has a very good extensibility model with unknown headers
|
|
being ignored by a receiver by default. There is also a mechanism
|
|
whereby headers which are required as a part of an incompatible
|
|
change may be marked with a 'mustUnderstand' flag. Passing
|
|
additional items as headers may be the only way to compatibly
|
|
evolve messages with fixed bodies.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="adv-versioning-big-bang" id=
|
|
"adv-versioning-big-bang"></a>5.2.2 Big Bang</h4>
|
|
<p>The <em>big bang</em> approach to versioning is the simplest to
|
|
currently represent in WSDL 2.0. In this approach, any change to a
|
|
WSDL 2.0 document implies a change to the document's namespace, a
|
|
change to the interface implies a new interface namespace and a
|
|
change to the message contents is communicated using a new message
|
|
namespace. This approach has particular benefits where an agent may
|
|
quickly tell if a service has changed by simply comparing the
|
|
namespace value.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="ad-versioing-migration" id=
|
|
"ad-versioing-migration"></a>5.2.3 Evolving a Service</h4>
|
|
<p>Compatible changes are far more easily managed than incompatible
|
|
ones:</p>
|
|
<ul>
|
|
<li>
|
|
<p>With a compatible change the service need only support the
|
|
latest version of a service. A client may continue to use a service
|
|
adjusting to new version of the interface description at a time of
|
|
its choosing.</p>
|
|
</li>
|
|
<li>
|
|
<p>With an incompatible change, the client receives a new version
|
|
of the interface description and is expected to adjust to the new
|
|
interface before old interface is terminated. Either the service
|
|
will need to continue to support both versions of the interface
|
|
during the hand over period, or the service and the clients are
|
|
coordinated to change at the same time. An alternative is for the
|
|
client to continue until it encounters an error, at which point it
|
|
uses the new version of the interface.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="adv-versioning-combined" id=
|
|
"adv-versioning-combined"></a>5.2.4 Combined Approaches</h4>
|
|
<p>It is feasible to combine the "compatible evolution" and "big
|
|
bang" approaches in a variety of different ways. For example, the
|
|
namespace could be changed when message descriptions are changed,
|
|
but the namespace could stay the same when new operations are
|
|
added.</p>
|
|
<p>While the big bang approach is currently the easiest to
|
|
implement in WSDL 2.0, it can lead to a large number of cloned
|
|
interfaces that become difficult to manage, thus making the
|
|
compatible approach preferable to many for widely distributed
|
|
systems. In the end, the choice of a versioning strategy for Web
|
|
services described in WSDL 2.0 is left as an exercise to the
|
|
reader.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="adv-versioning-examples" id=
|
|
"adv-versioning-examples"></a>5.2.5 Examples of Versioning and
|
|
Extending a Service</h4>
|
|
<div class="div4">
|
|
<h5><a name="id2301152" id="id2301152"></a>5.2.5.1 Additional
|
|
Optional Elements Added in Content</h5>
|
|
<p>The following example demonstrates how content may be extended
|
|
with additional content. The reservation service is changed to a
|
|
newer version that can accept an optional number of guests
|
|
parameter. The service provider wants existing clients to continue
|
|
to be able to use the service. The author adds the element into the
|
|
schema as an optional element.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-versioning-additional-elements" id=
|
|
"example-versioning-additional-elements"></a><em><span>Example
|
|
5-1.</span> XML Schema with Optional Elements</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<xs:complexType name="tCheckAvailability">
|
|
<xs:sequence>
|
|
<xs:element name="checkInDate" type="xs:date"/>
|
|
<xs:element name="checkOutDate" type="xs:date"/>
|
|
<xs:element name="roomType" type="xs:string"/>
|
|
<xs:element name="numberOfGuests" type="xs:integer" minOccurs="0"/>
|
|
<xs:any namespace="##other" processContents="lax"/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
|
|
</pre></div>
|
|
</div>
|
|
<p>The author has the choice of keeping the same namespace or using
|
|
a different namespace for the additional content and the existing
|
|
content. In this scenario, it is a compatible change and the author
|
|
decides to keep the same namespace. This allows existing clients to
|
|
interact with a new service, and it allows newer clients to
|
|
interact with older services.</p>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="id2301217" id="id2301217"></a>5.2.5.2 Additional
|
|
Optional Elements Added to a Header</h5>
|
|
<p>Another option is to add the extension as a header block. This
|
|
is accomplished by defining an element for the extension and adding
|
|
a header element that references the element into the binding
|
|
operation as child of the input.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-versioning-additional-header-elements" id=
|
|
"example-versioning-additional-header-elements"></a><em><span>Example
|
|
5-2.</span> Additional optional elements added to a SOAP
|
|
header</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<xs:element name="NumberOfGuests" type="tNumberOfGuests"/>
|
|
<xs:complexType name="tNumberOfGuests">
|
|
<xs:sequence>
|
|
<xs:element name="numberOfGuests" type="xs:integer" minOccurs="0"/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
|
|
<binding name="reservationSOAPBinding"
|
|
interface="tns:reservationInterface"
|
|
type="http://www.w3.org/ns/wsdl/soap"
|
|
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
|
|
|
|
<operation ref="tns:opCheckAvailability">
|
|
<input>
|
|
<wsoap:header element="tns:NumberOfGuests"/>
|
|
</input>
|
|
</operation>
|
|
...
|
|
</binding>
|
|
|
|
</pre></div>
|
|
</div>
|
|
<p>It is also possible for the header to be marked with
|
|
soap:mustUnderstand set to true. The HTTP Binding has similar
|
|
functionality though without a mustUnderstand attribute.</p>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="id2301271" id="id2301271"></a>5.2.5.3 Additional
|
|
Mandatory Elements in Content</h5>
|
|
<p>This following example demonstrates an extension with additional
|
|
content. The reservation service requires a number of guests
|
|
parameter. The service provider wants existing clients to be unable
|
|
to use the service. The author adds the element into the schema as
|
|
a mandatory element.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-versioning-additional-mandatory-elements" id=
|
|
"example-versioning-additional-mandatory-elements"></a><em><span>Example
|
|
5-3.</span> Additional Mandatory Elements in Content</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<xs:complexType name="tCheckAvailabilityV2">
|
|
<xs:sequence>
|
|
<xs:element name="checkInDate" type="xs:date"/>
|
|
<xs:element name="checkOutDate" type="xs:date"/>
|
|
<xs:element name="roomType" type="xs:string"/>
|
|
<xs:element name="numberOfGuests" type="xs:integer"/>
|
|
<xs:any namespace="##other" processContents="lax"/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
|
|
</pre></div>
|
|
</div>
|
|
<p>The author has the choice of keeping the same namespace or using
|
|
a different namespace for the additional content and the existing
|
|
content. In this scenario, it is an incompatible change and the
|
|
author decides to use a new name but the same namespace. This type
|
|
is then used in the interface operation, and then binding and
|
|
service endpoints.</p>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="id2301354" id="id2301354"></a>5.2.5.4 Additional
|
|
Optional Operation Added to Interface</h5>
|
|
<p>Section <a href="#more-interfaces-inheritance"><strong>2.4.2
|
|
Interface Inheritance</strong></a> shows another type of versioning
|
|
or extension, where the reservationInterface extends the
|
|
MessageLogInterface. By definition of interface inheritance, a
|
|
client that understands just the MessageLogInterface will continue
|
|
to work with the reservationInterface, that it is backwards
|
|
compatible.</p>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="id2301385" id="id2301385"></a>5.2.5.5 Additional
|
|
Mandatory Operation Added to Interface</h5>
|
|
<p>Often mandatory operations are added to an interface. The Hotel
|
|
service decides to add an operation to the reservation service
|
|
which is a confirmation. The Hotel service requires that all
|
|
clients upgrade to the new interface to use the service. They have
|
|
a variety of options for indicating that the old interface is
|
|
deprecated.</p>
|
|
<p>By the definition of interface inheritance, they cannot use
|
|
interface inheritance for defining the extension.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-versioning-additional-mandatory-operation" id=
|
|
"example-versioning-additional-mandatory-operation"></a><em><span>Example
|
|
5-4.</span> Additional Mandatory Operation Added to the
|
|
Interface</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<interface name="reservationWithConfirmation" extends="cc:creditCardFaults">
|
|
...
|
|
<operation name="makeReservation">
|
|
<input messageLabel="In" element="ghns:makeReservation" />
|
|
<output messageLabel="Out" element="ghns:makeReservationResponse" />
|
|
<outfault ref="invalidDataFault" messageLabel="Out" />
|
|
<outfault ref="cc:cancelledCreditCard" messageLabel="Out" />
|
|
<outfault ref="cc:expiredCreditCard" messageLabel="Out" />
|
|
<outfault ref="cc:invalidCreditCardNumber" messageLabel="Out" />
|
|
<outfault ref="cc:invalidExpirationDate" messageLabel="Out" />
|
|
</operation>
|
|
<operation name="confirmReservation">
|
|
<input messageLabel="In" element="ghns:makeReservationResponse" />
|
|
<output messageLabel="Out" element="ghns:confirmReservationResponse" />
|
|
<outfault ref="expiredReservation" messageLabel="Out" />
|
|
</operation>
|
|
</interface>
|
|
|
|
</pre></div>
|
|
</div>
|
|
<p>This interface cannot be bound and deployed at the existing URI
|
|
and indicate incompatibility, as the service will still accept the
|
|
makeReservation request. Changing the name of the interface from
|
|
reservation to reservationWithConfirmation or changing the name of
|
|
the operation from makeReservation to makeReservationV2 does not
|
|
affect the messages that are exchanged. Thus it can't be used as a
|
|
mechanism for indicating incompatibility. To indicate
|
|
incompatibility, a change must be made to something that appears in
|
|
the message. For a SOAP over HTTP request, the list is roughly the
|
|
URI, the SOAP Action HTTP Header, or the Message content.</p>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="id2301454" id="id2301454"></a>5.2.5.6 Indicating
|
|
Incompatibility by Changing the Endpoint URI</h5>
|
|
<p>To indicate incompatibility, the URI of the Hotel Endpoint can
|
|
be changed and messages send to the old Endpoint return a
|
|
Fault.</p>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="id2301490" id="id2301490"></a>5.2.5.7 Indicating
|
|
Incompatibility by Changing the SOAP Action</h5>
|
|
<p>The SOAP Action can be set for the makeReservation request, and
|
|
making it different than the earlier version should indicate
|
|
incompatibility.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-versioning-SOAP-Action" id=
|
|
"example-versioning-SOAP-Action"></a><em><span>Example 5-5.</span>
|
|
Indicating Incompatibility by changing the SOAP Action</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<binding name="reservationSOAPBinding"
|
|
interface="tns:reservationInterface"
|
|
type="http://www.w3.org/ns/wsdl/soap"
|
|
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
|
|
<operation ref="tns:makeReservation"
|
|
wsoap:action="tns:makeReservationV2"/>
|
|
. . .
|
|
|
|
</pre></div>
|
|
</div>
|
|
<p>Note that this mechanism is applicable on a per-binding basis.
|
|
The SOAP HTTP Binding provides for setting Action, but other
|
|
bindings may not provide such a facility.</p>
|
|
</div>
|
|
<div class="div4">
|
|
<h5><a name="id2301552" id="id2301552"></a>5.2.5.8 Indicating
|
|
Incompatibility by Changing the Element Content</h5>
|
|
<p>The namespace or name of the makeReservation element can be
|
|
changed, and then the interface and bindings changed. To indicate
|
|
incompatibility, requests using the old makeReservation QName
|
|
should probably return a fault. The new interface, with a changed
|
|
makeReservation, is:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example-versioning-changing-element-content" id=
|
|
"example-versioning-changing-element-content"></a><em><span>Example
|
|
5-6.</span> Indicating incompatibility by changing the element
|
|
content</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<xs:element name="ghns2:makeReservation" type="ghns:tmakeReservation"/>
|
|
|
|
<interface . . .>
|
|
|
|
<operation name="makeReservation">
|
|
|
|
<input messageLabel="In" element="ghns2:makeReservation" />
|
|
|
|
</interface>
|
|
|
|
</pre></div>
|
|
</div>
|
|
<p>The binding and service endpoints require no change.</p>
|
|
<p>Finally, the service could also provide an interface for
|
|
ghns:makeReservation that only returns a fault.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="adv-service-references" id=
|
|
"adv-service-references"></a>5.3 Describing Web Service Messages
|
|
That Refer to Other Web Services</h3>
|
|
<p>Hyperlinking is one of the defining characteristics of the Web.
|
|
The ability to navigate from one Web page to another is extremely
|
|
useful. It is therefore natural to apply this capability to Web
|
|
services. This section describes references to endpoints and
|
|
services, which are the Web service analogs of document
|
|
hyperlinks.</p>
|
|
<p>A <em>reference to an endpoint</em> is an element or attribute
|
|
that contains the address of a Web service endpoint. A
|
|
<em>reference to a service</em> is an element or attribute that
|
|
contains one or more references to the endpoints of a service. If
|
|
the interface or binding that the service or endpoint implements is
|
|
known at description time, it may be useful to add this information
|
|
to the WSDL 2.0 document that describes the Web service. This is
|
|
accomplished by using the <code>wsdlx:interface</code> or
|
|
<code>wsdlx:binding</code> attribute to annotate the XML Schema
|
|
component that defines the message.</p>
|
|
<p>One may wonder, from a Web architectural point of view, why
|
|
anything more than a URI would be needed to reference a Web
|
|
service. Indeed, a reference to a service does make use of one or
|
|
more URIs to indicate the endpoint addresses of a service. However,
|
|
it may also include additional metadata about that service, such as
|
|
the WSDL 2.0 interface and binding that the service supports.</p>
|
|
<p>References to services and endpoints will be illustrated by
|
|
expanding the GreatH example already discussed.</p>
|
|
<div class="div3">
|
|
<h4><a name="reservationDetails" id="reservationDetails"></a>5.3.1
|
|
The Reservation Details Web Service</h4>
|
|
<p>When designing a Web application it is natural to give each
|
|
important concept a URI. In the GreatH hotel reservation system,
|
|
the important concepts are reservations, so we begin our design by
|
|
assigning a URI to each reservation. Since each reservation has a
|
|
unique confirmation number, e.g OMX736, we create a URI for each
|
|
reservation by appending the confirmation number to a base URI,
|
|
e.g. http://greath.example.com/2004/reservation/OMX736. This URI
|
|
will be the endpoint address for a Reservation Details Web service
|
|
that can retrieve and update the state of a reservation. <a href=
|
|
"#reservationDetails-OMX736.xml">Example 5-7</a> shows the format
|
|
of the reservation detail.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"reservationDetails-OMX736.xml" id=
|
|
"reservationDetails-OMX736.xml"></a><em><span>Example 5-7.</span>
|
|
Detail for Reservation OMX736</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<reservationDetails
|
|
xmlns="http://greath.example.com/2004/schemas/reservationDetails">
|
|
|
|
<confirmationNumber>OMX736</confirmationNumber>
|
|
<checkInDate>2005-06-01</checkInDate>
|
|
<checkOutDate>2005-06-03</checkOutDate>
|
|
<roomType>single</roomType>
|
|
<smoking>false</smoking>
|
|
|
|
</reservationDetails>
|
|
</pre></div>
|
|
</div>
|
|
<p>The Reservation Details Web service provides operations for
|
|
retrieving and updating the detail for a reservation. <a href=
|
|
"#reservationDetails.wsdl">Example 5-8</a> shows the description
|
|
for this Web service. Note that there is no <code>service</code>
|
|
element in this description since the set of reservations is
|
|
dynamic. Instead, the endpoints for the reservations will be
|
|
returned by querying the Reservation List Web service.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"reservationDetails.wsdl" id=
|
|
"reservationDetails.wsdl"></a><em><span>Example 5-8.</span> The
|
|
Reservation Details Web Service Description:
|
|
reservationDetails.wsdl</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description
|
|
xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace="http://greath.example.com/2004/services/reservationDetails"
|
|
xmlns:tns="http://greath.example.com/2004/services/reservationDetails"
|
|
xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema">
|
|
|
|
<documentation>
|
|
This document describes the GreatH Reservation Details Web
|
|
services. Use these services to retrieve or update reservation
|
|
details. Each reservation has its own service and endpoint. To
|
|
obtain the reference for a reservation service, make a request to
|
|
the GreatH Reservation List Web service. See
|
|
reservationList.wsdl for a description of the Reservation List
|
|
Web service.
|
|
</documentation>
|
|
|
|
<types>
|
|
<xs:import
|
|
namespace="http://greath.example.com/2004/schemas/reservationDetails"
|
|
schemaLocation="reservationDetails.xsd" />
|
|
</types>
|
|
|
|
<interface name="reservationDetailsInterface">
|
|
|
|
<operation name="retrieve"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In" element="#none" />
|
|
<output messageLabel="Out"
|
|
element="wdetails:reservationDetails" />
|
|
</operation>
|
|
|
|
<operation name="update"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In"
|
|
element="wdetails:reservationDetails" />
|
|
<output messageLabel="Out"
|
|
element="wdetails:reservationDetails" />
|
|
</operation>
|
|
|
|
</interface>
|
|
|
|
<binding name="reservationDetailsSOAPBinding"
|
|
interface="tns:reservationDetailsInterface"
|
|
type="http://www.w3.org/ns/wsdl/soap"
|
|
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
|
|
|
|
<operation ref="tns:retrieve"
|
|
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />
|
|
|
|
<operation ref="tns:update"
|
|
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />
|
|
|
|
</binding>
|
|
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<p><a href="#reservationDetails.xsd">Example 5-9</a> shows the XML
|
|
schema elements that are used in this Web service.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"reservationDetails.xsd" id=
|
|
"reservationDetails.xsd"></a><em><span>Example 5-9.</span> The
|
|
Reservation Details Web Service XML Schema:
|
|
reservationDetails.xsd</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<schema xmlns="http://www.w3.org/2001/XMLSchema"
|
|
elementFormDefault="qualified"
|
|
targetNamespace="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:tns="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:wdetails="http://greath.example.com/2004/services/reservationDetails"
|
|
xmlns:wsdli="http://www.w3.org/ns/wsdl-instance"
|
|
xmlns:wsdlx="http://www.w3.org/ns/wsdl-extensions"
|
|
wsdli:wsdlLocation="http://greath.example.com/2004/services/reservationDetails reservationDetails.wsdl">
|
|
|
|
<element name="confirmationNumber" type="string" />
|
|
|
|
<element name="checkInDate" type="date" />
|
|
|
|
<element name="checkOutDate" type="date" />
|
|
|
|
<element name="reservationDetails">
|
|
<complexType>
|
|
<sequence>
|
|
<element ref="tns:confirmationNumber" />
|
|
<element ref="tns:checkInDate" />
|
|
<element ref="tns:checkOutDate" />
|
|
<element name="roomType" type="string" />
|
|
<element name="smoking" type="boolean" />
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<simpleType name="reservationDetailsSOAPEndpointType" wsdlx:binding="wdetails:reservationDetailsSOAPBinding">
|
|
<restriction base="anyURI"/>
|
|
</simpleType>
|
|
|
|
<element name="reservationDetailsSOAPEndpoint" type="tns:reservationDetailsSOAPEndpointType" />
|
|
|
|
<element name="reservationDetailsService">
|
|
<annotation>
|
|
<documentation>
|
|
This element contains references to the Reservation
|
|
Details Web Service endpoints for this reservation.
|
|
</documentation>
|
|
</annotation>
|
|
<complexType>
|
|
<sequence>
|
|
<element name="soap" type="tns:reservationDetailsSOAPEndpointType"/>
|
|
<element name="secure-soap" type="tns:reservationDetailsSOAPEndpointType"/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
</schema>
|
|
</pre></div>
|
|
</div>
|
|
<p>This XML schema contains the usual definitions for the elements
|
|
that appear in the messages of the Web service. For example, the
|
|
<code>reservationDetails</code> element is used in the messages of
|
|
the <code>retrieve</code> and <code>update</code> operations. In
|
|
addition, the schema defines the simple type
|
|
<code>reservationDetailsSOAPEndpointType</code> which is based on
|
|
<code>xs:anyURI</code> and has the annotation <code>wsdlx:binding =
|
|
"wdetails:reservationDetailsSOAPBinding"</code> which means that
|
|
the URI is the address of a Reservation Details Web service
|
|
endpoint that implements the
|
|
<code>wdetails:reservationDetailsSOAPBinding</code> binding. Note
|
|
that the <code>wsdli:wsdlLocation</code> attribute is used to
|
|
define the location of the WSDL 2.0 document that defines the
|
|
<code>wdetails:reservationDetailsSOAPBinding</code> binding. This
|
|
annotated simple type is used to define the
|
|
<code>reservationDetailsSOAPEndpoint</code> element which will be
|
|
used in the Reservation List service.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="reservationList" id="reservationList"></a>5.3.2 The
|
|
Reservation List Web Service</h4>
|
|
<p>Since the set of reservations changes as reservations are made
|
|
and cancelled, the Reservation Detail endpoints are not described
|
|
in a fixed WSDL 2.0 document. Instead they are returned as
|
|
references to endpoints in response to requests made on a
|
|
Reservation List Web service. The endpoint address for the
|
|
Reservation List service will be
|
|
http://greath.example.com/2004/reservationList.</p>
|
|
<p><a href="#reservationList-all.xml">Example 5-10</a> shows the
|
|
format of the response from the Reservation List service.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"reservationList-all.xml" id=
|
|
"reservationList-all.xml"></a><em><span>Example 5-10.</span>
|
|
Response from the Reservation List Web Service</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<reservationList
|
|
xmlns="http://greath.example.com/2004/schemas/reservationList"
|
|
xmlns:details="http://greath.example.com/2004/schemas/reservationDetails">
|
|
|
|
<reservation>
|
|
<details:confirmationNumber>HSG635</details:confirmationNumber>
|
|
<details:checkInDate>2005-06-27</details:checkInDate>
|
|
<details:checkOutDate>2005-06-28</details:checkOutDate>
|
|
<details:reservationDetailsSOAPEndpoint>
|
|
http://greath.example.com/2004/reservation/HSG635
|
|
</details:reservationDetailsSOAPEndpoint>
|
|
</reservation>
|
|
|
|
<reservation>
|
|
<details:confirmationNumber>OMX736</details:confirmationNumber>
|
|
<details:checkInDate>2005-06-01</details:checkInDate>
|
|
<details:checkOutDate>2005-06-03</details:checkOutDate>
|
|
<details:reservationDetailsSOAPEndpoint>
|
|
http://greath.example.com/2004/reservation/OMX736
|
|
</details:reservationDetailsSOAPEndpoint>
|
|
</reservation>
|
|
|
|
<reservation>
|
|
<details:confirmationNumber>WUH663</details:confirmationNumber>
|
|
<details:checkInDate>2005-06-11</details:checkInDate>
|
|
<details:checkOutDate>2005-06-15</details:checkOutDate>
|
|
<details:reservationDetailsSOAPEndpoint>
|
|
http://greath.example.com/2004/reservation/WUH663
|
|
</details:reservationDetailsSOAPEndpoint>
|
|
</reservation>
|
|
|
|
</reservationList>
|
|
</pre></div>
|
|
</div>
|
|
<p>Here, the
|
|
<code><details:reservationDetailsSOAPEndpoint></code>
|
|
elements contain references to the Reservation Details Web service
|
|
endpoints for the reservations HSG635, OMX736, and WUH663.</p>
|
|
<p><a href="#reservationList.wsdl">Example 5-11</a> shows the
|
|
description of the Reservation List Web service. Note that it
|
|
contains operations to retrieve the entire list and to query for a
|
|
list of reservations by confirmation number, check-in date, and
|
|
check-out date. In each case, the operation returns a list of
|
|
reservations.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"reservationList.wsdl" id=
|
|
"reservationList.wsdl"></a><em><span>Example 5-11.</span> The
|
|
Reservation List Web Service Description:
|
|
reservationList.wsdl</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="utf-8" ?>
|
|
<description
|
|
xmlns="http://www.w3.org/ns/wsdl"
|
|
targetNamespace="http://greath.example.com/2004/services/reservationList"
|
|
xmlns:tns="http://greath.example.com/2004/services/reservationList"
|
|
xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:list="http://greath.example.com/2004/schemas/reservationList"
|
|
xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
|
|
xmlns:xs="http://www.w3.org/2001/XMLSchema">
|
|
|
|
<documentation>
|
|
This document describes the GreatH Reservation List Web
|
|
services. Use this service to retrieve lists of reservations
|
|
based on a variety of search criteria.
|
|
</documentation>
|
|
|
|
<types>
|
|
<xs:import
|
|
namespace="http://greath.example.com/2004/schemas/reservationDetails"
|
|
schemaLocation="reservationDetails.xsd" />
|
|
<xs:import
|
|
namespace="http://greath.example.com/2004/schemas/reservationList"
|
|
schemaLocation="reservationList.xsd" />
|
|
</types>
|
|
|
|
<interface name="reservationListInterface">
|
|
|
|
<operation name="retrieve"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In" element="#none" />
|
|
<output messageLabel="Out" element="list:reservationList" />
|
|
</operation>
|
|
|
|
<operation name="retrieveByConfirmationNumber"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In"
|
|
element="details:confirmationNumber" />
|
|
<output messageLabel="Out" element="list:reservationList" />
|
|
</operation>
|
|
|
|
<operation name="retrieveByCheckInDate"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In" element="details:checkInDate" />
|
|
<output messageLabel="Out" element="list:reservationList" />
|
|
</operation>
|
|
|
|
<operation name="retrieveByCheckOutDate"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In" element="details:checkOutDate" />
|
|
<output messageLabel="Out" element="list:reservationList" />
|
|
</operation>
|
|
|
|
</interface>
|
|
|
|
<binding name="reservationListSOAPBinding"
|
|
interface="tns:reservationListInterface"
|
|
type="http://www.w3.org/ns/wsdl/soap"
|
|
wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/">
|
|
|
|
<operation ref="tns:retrieve"
|
|
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />
|
|
|
|
<operation ref="tns:retrieveByConfirmationNumber"
|
|
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />
|
|
|
|
<operation ref="tns:retrieveByCheckInDate"
|
|
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />
|
|
|
|
<operation ref="tns:retrieveByCheckOutDate"
|
|
wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />
|
|
|
|
</binding>
|
|
|
|
<service name="reservationListService"
|
|
interface="tns:reservationListInterface">
|
|
|
|
<endpoint name="reservationListEndpoint"
|
|
binding="tns:reservationListSOAPBinding"
|
|
address="http://greath.example.com/2004/reservationList" />
|
|
|
|
</service>
|
|
|
|
</description>
|
|
</pre></div>
|
|
</div>
|
|
<p><a href="#reservationList.xsd">Example 5-12</a> shows the schema
|
|
for the messages used in the Reservation List Web service.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"reservationList.xsd" id=
|
|
"reservationList.xsd"></a><em><span>Example 5-12.</span> The
|
|
Reservation List Schema: reservationList.xsd</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<schema xmlns="http://www.w3.org/2001/XMLSchema"
|
|
elementFormDefault="qualified"
|
|
targetNamespace="http://greath.example.com/2004/schemas/reservationList"
|
|
xmlns:tns="http://greath.example.com/2004/schemas/reservationList"
|
|
xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"
|
|
xmlns:wsdli="http://www.w3.org/ns/wsdl-instance">
|
|
|
|
<import
|
|
namespace="http://www.w3.org/ns/wsdl-instance" />
|
|
|
|
<import
|
|
namespace="http://greath.example.com/2004/schemas/reservationDetails"
|
|
schemaLocation="reservationDetails.xsd" />
|
|
|
|
<element name="reservation">
|
|
<annotation>
|
|
<documentation>
|
|
A reservation contains the confirmation number, check-in
|
|
and check-out dates, and a reference to a Reservation
|
|
Details Web service.
|
|
</documentation>
|
|
</annotation>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref="details:confirmationNumber" />
|
|
<element ref="details:checkInDate" />
|
|
<element ref="details:checkOutDate" />
|
|
<element ref="details:reservationDetailsSOAPEndpoint" />
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<element name="reservationList">
|
|
<annotation>
|
|
<documentation>
|
|
A reservation list contains a sequence of zero or more
|
|
reservations.
|
|
</documentation>
|
|
</annotation>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref="tns:reservation" minOccurs="0"
|
|
maxOccurs="unbounded">
|
|
</element>
|
|
</sequence>
|
|
<attribute ref="wsdli:wsdlLocation" />
|
|
</complexType>
|
|
</element>
|
|
|
|
</schema>
|
|
</pre></div>
|
|
</div>
|
|
<p>In the preceding example, there was a single endpoint associated
|
|
with each Reservation Detail Web service. Suppose GreatH hotel
|
|
decided to provide a second, secure endpoint. In this case,
|
|
references to services would be used to collect together the
|
|
endpoints for each reservation. The reservationDetails.xsd schema
|
|
defines the <code>reservationDetailsService</code> element for this
|
|
purpose. It contains the nested elements <code>soap</code> and
|
|
<code>secure-soap</code> which are each of type
|
|
<code>reservationDetailsSOAPEndpointType</code> and therefore
|
|
contain the address of an endpoint that implements the
|
|
<code>wdetails:reservationDetailsSOAPBinding</code> binding.</p>
|
|
<p><a href="#reservationServiceReferences-HSG635.xml">Example
|
|
5-13</a> shows an example of a message that contains a reference to
|
|
the service for reservation HGS635. Note that the service contains
|
|
two endpoints, one of which provides secure access to the
|
|
Reservation Details Web service.</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"reservationServiceReferences-HSG635.xml" id=
|
|
"reservationServiceReferences-HSG635.xml"></a><em><span>Example
|
|
5-13.</span> A Reference to the Reservation Details Web
|
|
Service</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<details:reservationDetailsService
|
|
xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"
|
|
|
|
<details:soap>
|
|
http://greath.example.com/2004/reservation/HSG635
|
|
</details:soap>
|
|
|
|
<details:secure-soap>
|
|
https://greath.example.com/2004/reservation/HSG635
|
|
</details:secure-soap>
|
|
|
|
</details:reservationDetailsService>
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="reservationDetails_HTTP" id=
|
|
"reservationDetails_HTTP"></a>5.3.3 Reservation Details Web Service
|
|
Using HTTP Transfer</h4>
|
|
<p>This section presents a variation on the example in <a href=
|
|
"#reservationDetails"><strong>5.3.1 The Reservation Details Web
|
|
Service</strong></a> . It illustrates the use of HTTP transfer
|
|
operations, GET and PUT, to retrieve and update GreatH hotel
|
|
reservation details using the Representational State Transfer
|
|
(REST) architectural style described by Roy Fielding
|
|
[<cite><a href="#rest">REST</a></cite>] . REST is a distillation of
|
|
the architectural properties that Dr. Fielding identified as being
|
|
vital to the Web's robustness and enormous scalability.</p>
|
|
<p>Since each reservation in our example will have a distinct URI,
|
|
the Reservation Details Web service can be offered using HTTP GET
|
|
and HTTP PUT. The binding would be modified as follows:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"reservationDetails_HTTP_example" id=
|
|
"reservationDetails_HTTP_example"></a><em><span>Example
|
|
5-14.</span> Reservation Details Web Service Using HTTP
|
|
Transfer</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
. . .
|
|
<binding name="reservationDetailsHTTPBinding"
|
|
type="http://www.w3.org/ns/wsdl/http"
|
|
interface="tns:reservationDetailsInterface" >
|
|
|
|
<operation ref="tns:retrieve"
|
|
whttp:method="GET" />
|
|
|
|
<operation ref="tns:update"
|
|
whttp:method="PUT" />
|
|
|
|
</binding>
|
|
. . .
|
|
</pre></div>
|
|
</div>
|
|
<p>As with the example in <a href=
|
|
"#reservationDetails"><strong>5.3.1 The Reservation Details Web
|
|
Service</strong></a> , service and endpoint elements are not
|
|
provided because the Reservation List Web service provides the
|
|
endpoints.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="reservationList_HTTP_GET" id=
|
|
"reservationList_HTTP_GET"></a>5.3.4 Reservation List Web Service
|
|
Using HTTP GET</h4>
|
|
<p>This section continues the REST-style example of <a href=
|
|
"#reservationDetails_HTTP"><strong>5.3.3 Reservation Details Web
|
|
Service Using HTTP Transfer</strong></a> by modifying the example
|
|
of <a href="#reservationList"><strong>5.3.2 The Reservation List
|
|
Web Service</strong></a> to use HTTP GET.</p>
|
|
<p>The SOAP version of the Reservation List Web service above
|
|
offers four different search operations. These can also be
|
|
expressed as various parameters in a URI used by HTTP GET:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example_reservationList_HTTP_GET" id=
|
|
"example_reservationList_HTTP_GET"></a><em><span>Example
|
|
5-15.</span> Reservation List Web Service Using HTTP GET</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
. . .
|
|
<binding name="reservationListHTTPBinding"
|
|
type="http://www.w3.org/ns/wsdl/http"
|
|
interface="tns:reservationListInterface"
|
|
whttp:methodDefault="GET">
|
|
|
|
<operation ref="tns:retrieve"
|
|
whttp:location="" />
|
|
|
|
<operation ref="tns:retrieveByConfirmationNumber"
|
|
whttp:location="reservationList/ConfirmationNumber/{confirmationNumber/}" />
|
|
|
|
<operation ref="tns:retrieveByCheckInDate"
|
|
whttp:location="reservationList/CheckInDate/{checkInDate/}" />
|
|
|
|
<operation ref="tns:retrieveByCheckOutDate"
|
|
whttp:location="reservationList/CheckOutDate/{checkOutDate/}" />
|
|
</binding>
|
|
. . .
|
|
<service . . . >
|
|
|
|
<endpoint name="reservationListEndpoint"
|
|
binding="tns:reservationListHTTPBinding"
|
|
address="http://greath.example.com/2004/reservationList" />
|
|
. . .
|
|
</service>
|
|
. . .
|
|
</pre></div>
|
|
</div>
|
|
<p>A retrieval by Confirmation Number URI would look like:
|
|
<code>http://greath.example.com/2004/reservationList/ConfirmationNumber/HSG635
|
|
.</code></p>
|
|
<p>Alternatively, a single query type may be provided. This query
|
|
type is a sequence of optional items. Any items in the sequence are
|
|
serialized into the URI query string. A query sequence for any of
|
|
ConfirmationNumber, checkInDate, checkOutDate would look like
|
|
this:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example_reservationList_HTTP_GET_single" id=
|
|
"example_reservationList_HTTP_GET_single"></a><em><span>Example
|
|
5-16.</span> Query Sequence Using a Single Query Type</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
<element name="reservationQuery">
|
|
<annotation>
|
|
<documentation>
|
|
A reservation contains the confirmation number, check-in
|
|
and check-out dates, and a reference to a Reservation
|
|
Details Web service.
|
|
</documentation>
|
|
</annotation>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref="details:confirmationNumber" minOccurs="0"/>
|
|
<element ref="details:checkInDate" minOccurs="0"/>/>
|
|
<element ref="details:checkOutDate" minOccurs="0"/>/>
|
|
</sequence>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
</pre></div>
|
|
</div>
|
|
<p>The WSDL 2.0 service that offers this type serialized as a
|
|
parameter would look like this:</p>
|
|
<div class="exampleOuter">
|
|
<p style="text-align: left" class="exampleHead"><a name=
|
|
"example_reservationList_HTTP_GET_single_wsdl" id=
|
|
"example_reservationList_HTTP_GET_single_wsdl"></a><em><span>Example
|
|
5-17.</span> WSDL 2.0 for Using a Single Query Type</em></p>
|
|
<div class="exampleInner">
|
|
<pre xml:space="preserve">
|
|
. . .
|
|
<interface name="reservationListInterfaceWithQuery">
|
|
|
|
<operation name="retrieveByReservationQuery"
|
|
pattern="http://www.w3.org/ns/wsdl/in-out">
|
|
<input messageLabel="In"
|
|
element="details:ReservationQuery" />
|
|
<output messageLabel="Out"
|
|
element="list:reservationList" />
|
|
</operation>
|
|
|
|
</interface>
|
|
|
|
<binding name="reservationListQueryHTTPBinding"
|
|
type="http://www.w3.org/ns/wsdl/http"
|
|
interface="tns:reservationListInterfaceWithQuery"
|
|
whttp:methodDefault="GET">
|
|
|
|
<operation ref="tns:retrieveByReservationQuery"
|
|
whttp:location="reservationList/{ReservationQuery}}" />
|
|
|
|
</binding>
|
|
|
|
. . .
|
|
<endpoint name="reservationListEndpoint"
|
|
binding="tns:reservationListHTTPBinding"
|
|
address="http://greath.example.com/2004/reservationList" />
|
|
. . .
|
|
</pre></div>
|
|
</div>
|
|
<p>Various URIs would be:
|
|
<code>http://greath.example.com/2004/reservationList/ReservationQuery?confirmationNumber=HSG635</code>
|
|
<code>http://greath.example.com/2004/reservationList/ReservationQuery?checkInDate=06-06-05</code>
|
|
.</p>
|
|
<p>It is important to observe that using the URI serialization can
|
|
result in very flexible queries and few operations. The previous
|
|
discrete SOAP operations are collapsed into one "parameterized"
|
|
operation.</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="adv-multiple-docs-describing-same-service" id=
|
|
"adv-multiple-docs-describing-same-service"></a>5.4 Multiple
|
|
Interfaces for the Same Service</h3>
|
|
<p>Suppose a Web service wishes to expose two different interfaces:
|
|
a customer interface for its regular users, and a management
|
|
interface for its operator. A <code>wsdl:service</code> specifies
|
|
only one wsdl:interface, so to achieve the desired effect the
|
|
service provider would somehow need to indicate a relationship
|
|
between two services. How can a service provider indicate a
|
|
relationship between services? Potential strategies include:</p>
|
|
<ul>
|
|
<li>
|
|
<p><strong>Declare both interfaces in the same wsdl:description
|
|
element.</strong> Although WSDL 2.0 does not ascribe any particular
|
|
significance to the fact that two wsdl:services are declared within
|
|
the same wsdl:description, an application or toolkit could
|
|
interpret this to mean that they are related in some way.</p>
|
|
</li>
|
|
<li>
|
|
<p><strong>Declare both interfaces in the same
|
|
wsdl:targetNamespace.</strong> Again, although WSDL 2.0 does not
|
|
ascribe any particular significance to the fact that two
|
|
wsdl:services are declared within the same wsdl:targetNamespace, an
|
|
application or toolkit could interpret this to mean that they are
|
|
related in some way.</p>
|
|
</li>
|
|
<li>
|
|
<p><strong>Add an extension to WSDL 2.0</strong> that links
|
|
together all services that are related in this way. WSDL 2.0's open
|
|
content model permits extension elements from other namespaces to
|
|
appear in a WSDL 2.0 document.</p>
|
|
</li>
|
|
<li>
|
|
<p><strong>Declare them in completely separate WSDL 2.0 documents,
|
|
but use the same endpoint address for both.</strong> I.e., declare
|
|
a <code>wsdl:interface</code> and <code>wsdl:service</code> for the
|
|
customer interface in one WSDL 2.0 document, and a
|
|
<code>wsdl:interface</code> and <code>wsdl:service</code> for the
|
|
management interface in a different WSDL 2.0 document, but use the
|
|
same endpoint address for both. (By "different WSDL 2.0 document"
|
|
we mean that both documents are never included or imported into the
|
|
same WSDL 2.0 descriptions component.) Although this approach may
|
|
work in some circumstances, it means that the same endpoint address
|
|
would be used for two different purposes, which is apt to cause
|
|
confusion or ambiguity. Furthermore, it is contrary to the Web
|
|
architectural principle that different URIs should be used to
|
|
identify different Web resources. (See the Web Architecture
|
|
[<cite><a href="#webarch">Web Architecture</a></cite>] section on
|
|
<a href="http://www.w3.org/TR/webarch/#URI-collision">URI
|
|
collision</a>.)</p>
|
|
</li>
|
|
<li>
|
|
<p><strong>Use inheritance to combine the customer interface and
|
|
management interface</strong> into a single, larger wsdl:interface.
|
|
Of course, this reduces modularity and means that the management
|
|
interface becomes exposed to the customers, which is not good.</p>
|
|
</li>
|
|
</ul>
|
|
<p>Bear in mind that since the above strategies step outside of the
|
|
WSDL 2.0 language specifies (and are therefore neither endorsed nor
|
|
forbidden by the WSDL 2.0 specification) the WSDL 2.0 specification
|
|
cannot define or standardize their semantics.</p>
|
|
<p>The desire to express relationships between services is also
|
|
relevant to Web service versioning, discussed next.</p>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="adv-rdf-mapping" id="adv-rdf-mapping"></a>5.5 Mapping
|
|
to RDF and Semantic Web</h3>
|
|
<p>WSDL 2.0 is a language designed primarily with XML syntax. While
|
|
XML is almost universally understood, it has several issues:</p>
|
|
<ul>
|
|
<li>
|
|
<p>The ability to compose two XML documents into one depends on the
|
|
languages of those documents. WSDL 2.0 does not permit Web service
|
|
descriptions in different targetNamespaces to be merged into a
|
|
single (physical) XML document.</p>
|
|
</li>
|
|
<li>
|
|
<p>The ability to extend XML languages with other XML languages
|
|
depends on the languages again. WSDL 2.0 is extremely extensible,
|
|
but the meaning of every single extension in WSDL 2.0 must be
|
|
defined explicitly. Putting a piece of XMI (XML format for UML)
|
|
into a WSDL 2.0 document may have different meaning from putting it
|
|
into an XHTML document. Therefore XML-based extensibility has very
|
|
high cost if many languages are involved.</p>
|
|
</li>
|
|
<li>
|
|
<p>Similarly, extending another XML language with pieces of WSDL
|
|
2.0, while possible, has to be defined for all the possible
|
|
destinations. Putting a WSDL 2.0 interface element into a UDDI
|
|
registry may mean a different thing from putting that interface
|
|
element into an XHTML document.</p>
|
|
</li>
|
|
<li>
|
|
<p>Finally, the meaning of a portion of a WSDL 2.0 document is not
|
|
defined by the WSDL 2.0 specification. While an interface element
|
|
could form a single XML document, it is not a WSDL 2.0 document, so
|
|
its meaning is largely undefined.</p>
|
|
</li>
|
|
</ul>
|
|
<p>Applications that require such levels of composability (or
|
|
decomposability) are increasingly being based on RDF
|
|
[<cite><a href="#rdf">RDF</a></cite>], a graph-based knowledge
|
|
representation language, and Web Ontology Language (OWL)
|
|
[<cite><a href="#owl">OWL</a></cite>], which can be thought of as
|
|
an advanced schema language for RDF. Effectively, a WSDL 2.0
|
|
document represented in RDF can be more easily extended with
|
|
arbitrary RDF assertions and the WSDL 2.0 information can be more
|
|
easily associated with arbitrary other knowledge.</p>
|
|
<div class="div3">
|
|
<h4><a name="adv-rdf-rep-wsdl" id="adv-rdf-rep-wsdl"></a>5.5.1 RDF
|
|
Representation of WSDL 2.0</h4>
|
|
<p><em>WSDL 2.0: Mapping to RDF</em> [<cite><a href="#RDFmap">WSDL
|
|
2.0 RDF Mapping</a></cite>] describes how WSDL 2.0 constructs can
|
|
be expressed in RDF using classes of resources (described with an
|
|
ontology expressed in OWL) and assertions over individual
|
|
resources. As RDF represents knowledge using resources and
|
|
relationships between them, we need to turn WSDL 2.0 concepts into
|
|
this model. This is done as follows.</p>
|
|
<ol class="enumar">
|
|
<li>
|
|
<p>First, all components in WSDL 2.0 (like Interfaces, Operations,
|
|
Bindings, Services, Endpoints etc., including extensions) are
|
|
turned into resources identified with the appropriate URIs created
|
|
according to <a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#wsdl-iri-references">
|
|
Appendix C IRI-References for WSDL 2.0 Components</a> of
|
|
[<cite><a href="#WSDL-PART1">WSDL 2.0 Core</a></cite>].</p>
|
|
</li>
|
|
<li>
|
|
<p>Further, things are represented as resources:</p>
|
|
<ol class="enumla">
|
|
<li>
|
|
<p>Element declarations gathered from XML Schema (or similarly,
|
|
other components from other type systems)</p>
|
|
</li>
|
|
<li>
|
|
<p>Message content models</p>
|
|
</li>
|
|
<li>
|
|
<p>Message exchange patterns (the URI identifying the MEP is the
|
|
URI of the resource)</p>
|
|
</li>
|
|
<li>
|
|
<p>Operation styles (similarly to MEPs, the URI of an operation
|
|
style is the URI of the resource)</p>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li>
|
|
<p>All the resources above are given the appropriate types using
|
|
rdf:type statements (an interface will belong to the class
|
|
Interface and an operation within an interface will belong to the
|
|
class InterfaceOperation, for example).</p>
|
|
</li>
|
|
<li>
|
|
<p>All relationships in WSDL 2.0 (like an Operation's belonging to
|
|
an Interface and having a given operation style) are turned into
|
|
RDF statements using appropriate properties, such as
|
|
<code>operation</code> and <code>operationStyle</code>.</p>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="adv-notes-on-uris" id="adv-notes-on-uris"></a>5.6
|
|
Notes on URIs</h3>
|
|
<div class="div3">
|
|
<h4><a name="adv-namespaces-and-schema-locations" id=
|
|
"adv-namespaces-and-schema-locations"></a>5.6.1 XML Namespaces and
|
|
Schema Locations</h4>
|
|
<p>It is a common misperception to equate either the target
|
|
namespace of an XML Schema or the value of the <code>xmlns</code>
|
|
attribute in XML instances with the location of the corresponding
|
|
schema. Even though namespaces are URIs, and URIs may be locations,
|
|
and it may be possible to retrieve a schema from such a location,
|
|
this does not mean that the retrieved schema is the <em>only</em>
|
|
schema that is associated with that namespace. There can be
|
|
multiple schemas associated with a particular namespace, and it is
|
|
up to a processor of XML to determine which one to use in a
|
|
particular processing context. The WSDL 2.0 specification provides
|
|
the processing context here via the <code>import</code> mechanism,
|
|
which is based on XML Schema's term for the similar concept.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="adv-relative-uris" id="adv-relative-uris"></a>5.6.2
|
|
Relative URIs</h4>
|
|
<p>Throughout this document there are fully qualified URIs used in
|
|
WSDL 2.0 and XSD examples. In some cases, fully qualified URIs were
|
|
used simply to illustrate the referencing concepts. However, the
|
|
use of relative URIs is allowed and warranted in many cases. For
|
|
information on processing relative URIs, see <a href=
|
|
"http://www.ietf.org/rfc/rfc3986.txt">RFC3986</a>.</p>
|
|
</div>
|
|
<div class="div3">
|
|
<h4><a name="adv-generating-uris" id=
|
|
"adv-generating-uris"></a>5.6.3 Generating Temporary URIs</h4>
|
|
<p>In general, when a WSDL 2.0 document is published for use by
|
|
others, it should only contain URIs that are globally unique. This
|
|
is usually done by allocating them under a domain name that is
|
|
controlled by the issuer. For example, the W3C allocates namespace
|
|
URIs under its base domain name, w3.org.</p>
|
|
<p>However, it is sometimes desirable to make up a temporary URI
|
|
for an entity, for use during development, but not make the URI
|
|
globally unique for all time and have it "mean" that version of the
|
|
entity (schema, WSDL 2.0 document, etc.). <em>Reserved Top Level
|
|
DNS Names</em> [<cite><a href="#RFC2606">IETF RFC 2606</a></cite>]
|
|
specifies some URI base names that are reserved for use for this
|
|
type of behavior. For example, the base URI "http://example.org/"
|
|
can be used to construct a temporary URI without any unique
|
|
association to an entity. This means that two people or programs
|
|
could choose to simultaneously use the temporary URI "
|
|
http://example.org/userSchema" for two completely different
|
|
schemas. As long as the scope of use of these URIs does not
|
|
intersect, then they would be unique enough. However, it is not
|
|
recommended that " http://example.org/" be used as a base for
|
|
stable, fixed entities.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="div1">
|
|
<h2><a name="References" id="References"></a>6. References</h2>
|
|
<div class="div2">
|
|
<h3><a name="Normative-References" id=
|
|
"Normative-References"></a>6.1 Normative References</h3>
|
|
<dl>
|
|
<dt class="label"><a name="RFC2119" id="RFC2119"></a>[IETF RFC
|
|
2119]</dt>
|
|
<dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">Key words
|
|
for use in RFCs to Indicate Requirement Levels</a></cite>, S.
|
|
Bradner, Author. Internet Engineering Task Force, March 1997.
|
|
Available at http://www.ietf.org/rfc/rfc2119.txt</dd>
|
|
<dt class="label"><a name="RFC3023" id="RFC3023"></a>[IETF RFC
|
|
3023]</dt>
|
|
<dd><cite><a href="http://www.ietf.org/rfc/rfc3023.txt">XML Media
|
|
Types</a></cite>, M. Murata, S. St. Laurent, D. Kohn, Authors.
|
|
Internet Engineering Task Force, January 2001. Available at
|
|
http://www.ietf.org/rfc/rfc3023.txt</dd>
|
|
<dt class="label"><a name="RFC3986" id="RFC3986"></a>[IETF RFC
|
|
3986]</dt>
|
|
<dd><cite><a href="http://www.ietf.org/rfc/rfc3986.txt">Uniform
|
|
Resource Identifier (URI): Generic Syntax</a></cite>, T.
|
|
Berners-Lee, R. Fielding, L. Masinter, Authors. Internet
|
|
Engineering Task Force, January 2005. Available at
|
|
http://www.ietf.org/rfc/rfc3986.txt</dd>
|
|
<dt class="label"><a name="RFC3987" id="RFC3987"></a>[IETF RFC
|
|
3987]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.ietf.org/rfc/rfc3987.txt">Internationalized Resource
|
|
Identifiers (IRIs)</a></cite>, M. Duerst, M. Suignard, Authors.
|
|
Internet Engineering Task Force, January 2005. Available at
|
|
http://www.ietf.org/rfc/rfc3987.txt</dd>
|
|
<dt class="label"><a name="XML10" id="XML10"></a>[XML 1.0]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2006/REC-xml-20060816">Extensible Markup
|
|
Language (XML) 1.0 (Fourth Edition)</a></cite>, T. Bray, J. Paoli,
|
|
C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web
|
|
Consortium, 10 February 1998, revised 16 August 2006. This version
|
|
of the XML 1.0 Recommendation is
|
|
http://www.w3.org/TR/2006/REC-xml-20060816. The <a href=
|
|
"http://www.w3.org/TR/xml">latest version of XML 1.0</a> is
|
|
available at http://www.w3.org/TR/xml.</dd>
|
|
<dt class="label"><a name="XMLInfoSet" id="XMLInfoSet"></a>[XML
|
|
Information Set]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2004/REC-xml-infoset-20040204/">XML
|
|
Information Set (Second Edition)</a></cite>, J. Cowan and R. Tobin,
|
|
Editors. World Wide Web Consortium, 24 October 2001, revised 4
|
|
February 2004. This version of the XML Information Set
|
|
Recommendation is
|
|
http://www.w3.org/TR/2004/REC-xml-infoset-20040204/. The <a href=
|
|
"http://www.w3.org/TR/xml-infoset">latest version of XML
|
|
Information Set</a> is available at
|
|
http://www.w3.org/TR/xml-infoset.</dd>
|
|
<dt class="label"><a name="XMLNS" id="XMLNS"></a>[XML
|
|
Namespaces]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2006/REC-xml-names-20060816/">Namespaces in
|
|
XML 1.0 (Second Edition)</a></cite>, T. Bray, D. Hollander, A.
|
|
Layman, and R. Tobin, Editors. World Wide Web Consortium, 14
|
|
January 1999, revised 16 August 2006. This version of Namespaces in
|
|
XML 1.0 Recommendation is
|
|
http://www.w3.org/TR/2006/REC-xml-names-20060816/. The <a href=
|
|
"http://www.w3.org/TR/xml-names/">latest version of Namespaces in
|
|
XML</a> is available at http://www.w3.org/TR/xml-names.</dd>
|
|
<dt class="label"><a name="XMLSchemaP1" id="XMLSchemaP1"></a>[XML
|
|
Schema Structures]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
|
|
Part 1: Structures Second Edition</a></cite>, H. Thompson, D.
|
|
Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web
|
|
Consortium, 2 May 2001, revised 28 October 2004. This version of
|
|
the XML Schema Part 1 Recommendation is
|
|
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The <a href=
|
|
"http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema
|
|
Part 1</a> is available at http://www.w3.org/TR/xmlschema-1.</dd>
|
|
<dt class="label"><a name="XMLSchemaP2" id="XMLSchemaP2"></a>[XML
|
|
Schema Datatypes]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema
|
|
Part 2: Datatypes Second Edition</a></cite>, P. Byron and A.
|
|
Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised
|
|
28 October 2004. This version of the XML Schema Part 2
|
|
Recommendation is
|
|
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The <a href=
|
|
"http://www.w3.org/TR/xmlschema-2/">latest version of XML Schema
|
|
Part 2</a> is available at http://www.w3.org/TR/xmlschema-2.</dd>
|
|
<dt class="label"><a name="WSDL-PART1" id="WSDL-PART1"></a>[WSDL
|
|
2.0 Core]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-20070626">Web Services
|
|
Description Language (WSDL) Version 2.0 Part 1: Core
|
|
Language</a></cite>, R. Chinnici, J-J. Moreau, A. Ryman, S.
|
|
Weerawarana, Editors. World Wide Web Consortium, 26 June 2007. This
|
|
version of the "Web Services Description Language (WSDL) Version
|
|
2.0 Part 1: Core Language" Recommendation is available is available
|
|
at http://www.w3.org/TR/2007/REC-wsdl20-20070626. The <a href=
|
|
"http://www.w3.org/TR/wsdl20">latest version of "Web Services
|
|
Description Language (WSDL) Version 2.0 Part 1: Core Language"</a>
|
|
is available at http://www.w3.org/TR/wsdl20.</dd>
|
|
<dt class="label"><a name="WSDL-PART2" id="WSDL-PART2"></a>[WSDL
|
|
2.0 Adjuncts]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626">Web
|
|
Services Description Language (WSDL) Version 2.0 Part 2:
|
|
Adjuncts</a></cite>, R. Chinnici, H. Haas, A. Lewis, J-J. Moreau,
|
|
D. Orchard, S. Weerawarana, Editors. World Wide Web Consortium, 26
|
|
June 2007. This version of the "Web Services Description Language
|
|
(WSDL) Version 2.0 Part 2: Adjuncts" Recommendation is available at
|
|
http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626. The
|
|
<a href="http://www.w3.org/TR/wsdl20-adjuncts">latest version of
|
|
"Web Services Description Language (WSDL) Version 2.0 Part 2:
|
|
Adjuncts"</a> is available at
|
|
http://www.w3.org/TR/wsdl20-adjuncts.</dd>
|
|
<dt class="label"><a name="WSDL-SOAP11" id="WSDL-SOAP11"></a>[WSDL
|
|
2.0 SOAP 1.1 Binding]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/NOTE-wsdl20-soap11-binding-20070626">Web
|
|
Services Description Language (WSDL) Version 2.0 SOAP 1.1
|
|
Binding</a></cite>, A. Vedamuthu, Editor. World Wide Web
|
|
Consortium, 26 June 2007. This version of the "Web Services
|
|
Description Language (WSDL) Version 2.0 SOAP 1.1 Binding" Working
|
|
Group Note is available at
|
|
http://www.w3.org/TR/2007/NOTE-wsdl20-soap11-binding-20070626. The
|
|
<a href="http://www.w3.org/TR/wsdl20-soap11-binding">latest version
|
|
of "Web Services Description Language (WSDL) Version 2.0 SOAP 1.1
|
|
Binding"</a> is available at
|
|
http://www.w3.org/TR/wsdl20-soap11-binding.</dd>
|
|
<dt class="label"><a name="RDFmap" id="RDFmap"></a>[WSDL 2.0 RDF
|
|
Mapping]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/NOTE-wsdl20-rdf-20070626">Web Services
|
|
Description Language (WSDL) Version 2.0: RDF Mapping</a></cite>, J.
|
|
Kopecký, B. Parsia, Editors. World Wide Web Consortium, 26 June
|
|
2007. This version of the "Web Services Description Language (WSDL)
|
|
Version 2.0: RDF Mapping" Working Group Note is available at
|
|
http://www.w3.org/TR/2007/NOTE-wsdl20-rdf-20070626. The <a href=
|
|
"http://www.w3.org/TR/wsdl20-rdf">latest version of "Web Services
|
|
Description Language (WSDL) Version 2.0: RDF Mapping"</a> is
|
|
available at http://www.w3.org/TR/wsdl20-rdf.</dd>
|
|
<dt class="label"><a name="webarch" id="webarch"></a>[Web
|
|
Architecture]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2004/REC-webarch-20041215/">Architecture of
|
|
the World Wide Web, Volume One</a></cite>, Ian Jacobs, Norman
|
|
Walsh, Editors. W3C Recommendation, 15 December, 2004. Available at
|
|
http://www.w3.org/TR/2004/REC-webarch-20041215/ .</dd>
|
|
<dt class="label"><a name="wsarch" id="wsarch"></a>[WS
|
|
Architecture]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2004/REC-webarch-20041215/">Web Services
|
|
Architecture</a></cite>, David Booth, et al., Editors. W3C Working
|
|
Group Note, 11 February 2004. Available at
|
|
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ .</dd>
|
|
<dt class="label"><a name="WSAGLOSS" id="WSAGLOSS"></a>[WS
|
|
Glossary]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/">Web Services
|
|
Glossary</a></cite>, Hugo Haas, Allen Brown, Editors. W3C Working
|
|
Group Note, 11 February 2004. Available at
|
|
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/ .</dd>
|
|
<dt class="label"><a name="DESCRIBEMEDIA" id=
|
|
"DESCRIBEMEDIA"></a>[Describing Media Content of Binary Data in
|
|
XML]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/xml-media-types/">Describing Media Content of
|
|
Binary Data in XML</a></cite>, Anish Karmarkar, Ümit Yalçınalp,
|
|
Editors. W3C Working Group Note 4 May 2005. Available at
|
|
http://www.w3.org/TR/xml-media-types/</dd>
|
|
</dl>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="Informative-References" id=
|
|
"Informative-References"></a>6.2 Informative References</h3>
|
|
<dl>
|
|
<dt class="label"><a name="RFC2606" id="RFC2606"></a>[IETF RFC
|
|
2606]</dt>
|
|
<dd><cite><a href="http://www.ietf.org/rfc/rfc2606.txt">Reserved
|
|
Top Level DNS Names</a></cite>, D. Eastlake, A. Panitz, Authors.
|
|
Network Working Group, Internet Engineering Task Force, June 1999.
|
|
Available at http://www.ietf.org/rfc/rfc2606.txt.</dd>
|
|
<dt class="label"><a name="RFC2616" id="RFC2616"></a>[IETF RFC
|
|
2616]</dt>
|
|
<dd><cite><a href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext
|
|
Transfer Protocol -- HTTP/1.1</a></cite>, R. Fielding, J. Gettys,
|
|
J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee,
|
|
Authors. Internet Engineering Task Force, June 1999. Available at
|
|
http://www.ietf.org/rfc/rfc2616.txt.</dd>
|
|
<dt class="label"><a name="RFC2818" id="RFC2818"></a>[IETF RFC
|
|
2818]</dt>
|
|
<dd><cite><a href="http://www.ietf.org/rfc/rfc2818.txt">HTTP Over
|
|
TLS</a></cite>, E. Rescorla, Author. Internet Engineering Task
|
|
Force, May 2000. Available at
|
|
http://www.ietf.org/rfc/rfc2818.txt.</dd>
|
|
<dt class="label"><a name="SOAP11" id="SOAP11"></a>[SOAP 1.1]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">Simple Object
|
|
Access Protocol (SOAP) 1.1</a></cite>, D. Box, D. Ehnebuske, G.
|
|
Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S. Thatte,
|
|
D. Winer, Editors. World Wide Web Consortium, 8 May 2000. This
|
|
version of the Simple Object Access Protocol 1.1 Note is
|
|
http://www.w3.org/TR/2000/NOTE-SOAP-20000508.</dd>
|
|
<dt class="label"><a name="SOAP12-PART1" id=
|
|
"SOAP12-PART1"></a>[SOAP 1.2 Part 1: Messaging Framework]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/REC-soap12-part1-20070427/">SOAP Version
|
|
1.2 Part 1: Messaging Framework (Second Edition)</a></cite>, M.
|
|
Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen,
|
|
Editors. World Wide Web Consortium, 24 June 2003, revised 27 April
|
|
2007. This version of the "SOAP Version 1.2 Part 1: Messaging
|
|
Framework" Recommendation is
|
|
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/. The <a href=
|
|
"http://www.w3.org/TR/soap12-part1/">latest version of "SOAP
|
|
Version 1.2 Part 1: Messaging Framework"</a> is available at
|
|
http://www.w3.org/TR/soap12-part1/.</dd>
|
|
<dt class="label"><a name="SOAP12-PART2" id=
|
|
"SOAP12-PART2"></a>[SOAP 1.2 Part 2: Adjuncts]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2007/REC-soap12-part2-20070427/">SOAP Version
|
|
1.2 Part 2: Adjuncts</a></cite>, M. Gudgin, M. Hadley, N.
|
|
Mendelsohn, J-J. Moreau, and H. Frystyk Nielsen, Editors. World
|
|
Wide Web Consortium, 7 May 2003, revised 27 April 2007. This
|
|
version of the "SOAP Version 1.2 Part 2: Adjuncts" Recommendation
|
|
is http://www.w3.org/TR/2007/REC-soap12-part2-20070427/. The
|
|
<a href="http://www.w3.org/TR/soap12-part2/">latest version of
|
|
"SOAP Version 1.2 Part 2: Adjuncts"</a> is available at
|
|
http://www.w3.org/TR/soap12-part2/.</dd>
|
|
<dt class="label"><a name="SOAP-MTOM" id="SOAP-MTOM"></a>[SOAP
|
|
MTOM]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">SOAP Message
|
|
Transmission Optimization Mechanism</a></cite> , M. Gudgin, N.
|
|
Mendelsohn, M. Nottingham, H. Ruellan, Editors. World Wide Web
|
|
Consortium, 25 January, 2005. This version of SOAP Message
|
|
Transmission Optimization Mechanism is available at <a href=
|
|
"http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/</a>
|
|
http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/.</dd>
|
|
<dt class="label"><a name="WSDReqs" id="WSDReqs"></a>[WSD
|
|
Requirements]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028">Web Services
|
|
Description Requirements</a></cite>, J. Schlimmer, Editor. World
|
|
Wide Web Consortium, 17 October 2002. This version of the Web
|
|
Services Description Requirements document is
|
|
http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028. The <a href=
|
|
"http://www.w3.org/TR/ws-desc-reqs/">latest version of Web Services
|
|
Description Requirements</a> is available at
|
|
http://www.w3.org/TR/ws-desc-reqs.</dd>
|
|
<dt class="label"><a name="WS-A" id="WS-A"></a>[WS-Addressing]</dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/ws-addr-core/">Web Services
|
|
Addressing 1.0 - Core</a></cite>, Martin Gudgin, Marc Hadley,
|
|
Editor. World Wide Web Consortium, 17 August 2005. This version of
|
|
the Web Services Addressing 1.0 - Core document is available at
|
|
http://www.w3.org/TR/ws-addr-core/. The <a href=
|
|
"http://www.w3.org/TR/ws-addr-core/">latest version of Web Services
|
|
Description Requirements</a> is available at
|
|
http://www.w3.org/TR/ws-addr-core/.</dd>
|
|
<dt class="label"><a name="XPTR" id="XPTR"></a>[XPointer
|
|
Framework]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2003/REC-xptr-framework-20030325/">XPointer
|
|
Framework</a></cite>, Paul Grosso, Eve Maler, Jonathan Marsh,
|
|
Norman Walsh, Editors. World Wide Web Consortium, 25 March 2003.
|
|
This version of the XPointer Framework Proposed Recommendation is
|
|
http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ The <a href=
|
|
"http://www.w3.org/TR/xptr-framework/">latest version of XPointer
|
|
Framework</a> is available at
|
|
http://www.w3.org/TR/xptr-framework/.</dd>
|
|
<dt class="label"><a name="TAG-whenToUseGET" id=
|
|
"TAG-whenToUseGET"></a>[W3C TAG Finding: Use of HTTP GET]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/2001/tag/doc/whenToUseGet">URIs, Addressability,
|
|
and the use of HTTP GET and POST</a></cite>, Ian Jacobs, Editor.
|
|
World Wide Web Consortium, 21 March 2004. Available at
|
|
http://www.w3.org/2001/tag/doc/whenToUseGet</dd>
|
|
<dt class="label"><a name="TAG-versioning" id=
|
|
"TAG-versioning"></a>[W3C TAG Finding: Extending and Versioning
|
|
Languages Part 1]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/2001/tag/doc/versioning">Extending and
|
|
Versioning Languages Part 1</a></cite> David Orchard, Editor. World
|
|
Wide Web Consortium, 26 March 2006. Available at
|
|
http://www.w3.org/2001/tag/doc/versioning</dd>
|
|
<dt class="label"><a name="web-extensible" id=
|
|
"web-extensible"></a>[WebArch: Extensible Languages]</dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/NOTE-webarch-extlang">Web
|
|
Architecture: Extensible Languages</a></cite> , Tim Berners-Lee,
|
|
Dan Connolly, Authors. W3C Note 10 Feb 1998. Available at
|
|
http://www.w3.org/TR/NOTE-webarch-extlang</dd>
|
|
<dt class="label"><a name="xsd-versioning" id=
|
|
"xsd-versioning"></a>[XML Schema: Versioning Use-Cases]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/XML/2005/xsd-versioning-use-cases/">XML Schema
|
|
Versioning Use Cases</a></cite> , Hoylen Sue. W3C XML Schema
|
|
Working Group Draft, 31 January 2006. Available at
|
|
http://www.w3.org/XML/2005/xsd-versioning-use-cases/</dd>
|
|
<dt class="label"><a name="xsd-versioning-guide" id=
|
|
"xsd-versioning-guide"></a>[Guide to Versioning XML Languages using
|
|
XML Schema 1.1]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/xmlschema-guide2versioning">Guide to
|
|
Versioning XML Languages using XML Schema 1.1</a></cite>, David
|
|
Orchard. W3C XML Schema Working Group Draft, 28 September 2006.
|
|
Available at http://www.w3.org/TR/xmlschema-guide2versioning</dd>
|
|
<dt class="label"><a name="xsd11" id="xsd11"></a>[XML Schema
|
|
1.1]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/">XML Schema
|
|
1.1 Part 1: Structures</a></cite>, H. Thompson, C. M.
|
|
Sperberg-McQueen, Shudi (Sandy) Gao, N. Mendelsohn, David Beech,
|
|
Murray Maloney, Editors. World Wide Web Consortium, 31 August 2006.
|
|
This Working Draft of XML Schema 1.1 Part 1 is
|
|
http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/. The <a href=
|
|
"http://www.w3.org/TR/xmlschema11-1/">latest version of XML Schema
|
|
1.1 Part 1</a> is available at
|
|
http://www.w3.org/TR/xmlschema11-1/.</dd>
|
|
<dt class="label"><a name="sw-vocabulary" id=
|
|
"sw-vocabulary"></a>[SW VocabManagementNote]</dt>
|
|
<dd><cite><a href=
|
|
"http://esw.w3.org/topic/VocabManagementNote">Vocabulary
|
|
Management</a></cite> , Thomas Baker, et al. Semantic Web Best
|
|
Practices and Deployment Working Group Note, 8 Feb 2005. Available
|
|
at http://esw.w3.org/topic/VocabManagementNote</dd>
|
|
<dt class="label"><a name="relax-ng" id="relax-ng"></a>[RELAX
|
|
NG]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.oasis-open.org/committees/relax-ng/spec-20011203.html">RELAX
|
|
NG Specification</a></cite>, James Clark, MURATA Makoto, Editors.
|
|
OASIS Committee Specification, 3 December 2001. Available at
|
|
http://www.oasis-open.org/committees/relax-ng/spec-20011203.html</dd>
|
|
<dt class="label"><a name="jaxrpc" id="jaxrpc"></a>[JAX RPC
|
|
1.1]</dt>
|
|
<dd><cite><a href=
|
|
"http://java.sun.com/xml/downloads/jaxrpc.html">Java(TM) API for
|
|
XML-based Remote Procedure Call (JAX-RPC) Specification, version
|
|
1.1</a></cite>, Roberto Chinnici,et al. 14 October, 2003. Available
|
|
at http://java.sun.com/xml/downloads/jaxrpc.html</dd>
|
|
<dt class="label"><a name="rest" id="rest"></a>[REST]</dt>
|
|
<dd><cite><a href=
|
|
"http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm">
|
|
Representational State Transfer (REST)</a></cite>, Roy Thomas
|
|
Fielding, Author. 2000. Available at
|
|
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm</dd>
|
|
<dt class="label"><a name="rdf" id="rdf"></a>[RDF]</dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/rdf-concepts/">Resource
|
|
Description Framework (RDF): Concepts and Abstract
|
|
Syntax</a></cite>, Graham Klyne, Jeremy J. Carroll, Editors. W3C
|
|
Recommendation, 10 February 2004. Available at
|
|
http://www.w3.org/TR/rdf-concepts/</dd>
|
|
<dt class="label"><a name="owl" id="owl"></a>[OWL]</dt>
|
|
<dd><cite><a href="http://www.w3.org/TR/owl-ref/">OWL Web Ontology
|
|
Language Reference</a></cite>, Mike Dean,Guus Schreiber, Editors.
|
|
W3C Recommendation 10 February 2004 . Available at
|
|
http://www.w3.org/TR/owl-ref/</dd>
|
|
<dt class="label"><a name="altschemalangs" id=
|
|
"altschemalangs"></a>[Alternative Schema Languages Support]</dt>
|
|
<dd><cite><a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/altschemalangs.html?content-type=text/html;%20charset=utf-8&rev=1.3">
|
|
Discussion of Alternative Schema Languages and Type System Support
|
|
in WSDL</a></cite>, A. Lewis, B. Parsia, Editors.</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="back div1">
|
|
<h2><a name="acknowledgments" id="acknowledgments"></a>A.
|
|
Acknowledgements (Non-Normative)</h2>
|
|
<p>This document is the work of the <a href=
|
|
"http://www.w3.org/2002/ws/desc/">W3C Web Service Description
|
|
Working Group</a>.</p>
|
|
<p>Members of the Working Group are (at the time of writing, and by
|
|
alphabetical order): Charlton Barreto (Adobe Systems, Inc), Allen
|
|
Brookes (Rogue Wave Softwave), Dave Chappell (Sonic Software),
|
|
Helen Chen (Agfa-Gevaert N. V.), Roberto Chinnici (Sun
|
|
Microsystems), Kendall Clark (University of Maryland), Glen Daniels
|
|
(Sonic Software), Paul Downey (British Telecommunications), Youenn
|
|
Fablet (Canon), Ram Jeyaraman (Microsoft), Tom Jordahl (Adobe
|
|
Systems), Anish Karmarkar (Oracle Corporation), Jacek Kopecky (DERI
|
|
Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria),
|
|
Amelia Lewis (TIBCO Software, Inc.), Philippe Le Hegaret (W3C),
|
|
Michael Liddy (Education.au Ltd.), Kevin Canyang Liu (SAP AG),
|
|
Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems), Josephine
|
|
Micallef (SAIC - Telcordia Technologies), Jeff Mischkinsky (Oracle
|
|
Corporation), Dale Moberg (Cyclone Commerce), Jean-Jacques Moreau
|
|
(Canon), David Orchard (BEA Systems, Inc.), Gilbert Pilz (BEA
|
|
Systems, Inc.), Tony Rogers (Computer Associates), Arthur Ryman
|
|
(IBM), Adi Sakala (IONA Technologies), Michael Shepherd (Xerox),
|
|
Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2),
|
|
Ümit Yalçınalp (SAP AG), Peter Zehler (Xerox).</p>
|
|
<p>Previous members were: Eran Chinthaka (WSO2), Mark Nottingham
|
|
(BEA Systems, Inc.), Hugo Haas (W3C), Vivek Pandey (Sun
|
|
Microsystems), Bijan Parsia (University of Maryland), Lily Liu
|
|
(webMethods, Inc.), Don Wright (Lexmark), Joyce Yang (Oracle
|
|
Corporation), Daniel Schutzer (Citigroup), Dave Solo (Citigroup),
|
|
Stefano Pogliani (Sun Microsystems), William Stumbo (Xerox),
|
|
Stephen White (SeeBeyond), Barbara Zengler (DaimlerChrysler
|
|
Research and Technology), Tim Finin (University of Maryland),
|
|
Laurent De Teneuille (L'Echangeur), Johan Pauhlsson (L'Echangeur),
|
|
Mark Jones (AT&T), Steve Lind (AT&T), Sandra Swearingen
|
|
(U.S. Department of Defense, U.S. Air Force), Philippe Le Hégaret
|
|
(W3C), Jim Hendler (University of Maryland), Dietmar Gaertner
|
|
(Software AG), Michael Champion (Software AG), Don Mullen (TIBCO
|
|
Software, Inc.), Steve Graham (Global Grid Forum), Steve Tuecke
|
|
(Global Grid Forum), Michael Mahan (Nokia), Bryan Thompson (Hicks
|
|
& Associates), Ingo Melzer (DaimlerChrysler Research and
|
|
Technology), Sandeep Kumar (Cisco Systems), Alan Davies
|
|
(SeeBeyond), Jacek Kopecky (Systinet), Mike Ballantyne (Electronic
|
|
Data Systems), Mike Davoren (W. W. Grainger), Dan Kulp (IONA
|
|
Technologies), Mike McHugh (W. W. Grainger), Michael Mealling
|
|
(Verisign), Waqar Sadiq (Electronic Data Systems), Yaron Goland
|
|
(BEA Systems, Inc.), Ümit Yalçınalp (Oracle Corporation), Peter
|
|
Madziak (Agfa-Gevaert N. V.), Jeffrey Schlimmer (Microsoft
|
|
Corporation), Hao He (The Thomson Corporation), Erik Ackerman
|
|
(Lexmark), Jerry Thrasher (Lexmark), Prasad Yendluri (webMethods,
|
|
Inc.), William Vambenepe (Hewlett-Packard Company), David Booth
|
|
(W3C), Sanjiva Weerawarana (IBM), Asir Vedamuthu (webMethods,
|
|
Inc.), Igor Sedukhin (Computer Associates), Martin Gudgin
|
|
(Microsoft Corporation), Rebecca Bergersen (IONA Technologies), Ugo
|
|
Corda (SeeBeyond).</p>
|
|
<p>The people who have contributed to <a href=
|
|
"http://lists.w3.org/Archives/Public/www-ws-desc/">discussions on
|
|
www-ws-desc@w3.org</a> are also gratefully acknowledged.</p>
|
|
</div>
|
|
</body>
|
|
</html>
|