- From: Kevin Liu via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 16 Jun 2005 22:47:52 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv3328/ws/desc/wsdl20
Modified Files:
wsdl20-primer.html wsdl20-primer.xml
Log Message:
incorporate group decision to moveing interface/operation@safe to predefined extension
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.97
retrieving revision 1.98
diff -C2 -d -r1.97 -r1.98
*** wsdl20-primer.xml 16 Jun 2005 01:29:43 -0000 1.97
--- wsdl20-primer.xml 16 Jun 2005 22:47:50 -0000 1.98
***************
*** 132,136 ****
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
xmlns:wsoap= "http://www.w3.org/2005/05/wsdl/soap"
! xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<documentation>
--- 132,137 ----
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
xmlns:wsoap= "http://www.w3.org/2005/05/wsdl/soap"
! xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
! xmlns:wsdlx= "http://www.w3.org/@@@@/@@/wsdl-extensions">
<documentation>
***************
*** 171,175 ****
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
--- 172,176 ----
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! wsdlx:safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
***************
*** 279,283 ****
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
! . . . >
. . .
--- 280,285 ----
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
! . . .
! xmlns:wsdlx= "http://www.w3.org/@@@@/@@/wsdl-extensions">
. . .
***************
*** 294,298 ****
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
--- 296,300 ----
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! wsdlx:safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
***************
*** 314,318 ****
</p></def></gitem>
! <gitem><label><code>safe="true" ></code></label><def><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 <specref ref="more-interfaces-operations"/>. </p></def></gitem><gitem><label><code><input messageLabel="In"</code></label><def><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 <xspecref href="&w3c-designation-part2;#in-out">in-out</xspecref> pattern tat 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 <emph>WSDL 2.0 Predefined Extensions</emph> <bibref ref="WSDL-PART2"/> section 2.2.3 <xspecref href="&w3c-designation-part2;#in-out">In-Out</xspecref> for the <xspecref href="&w3c-designation-part2;#in-out">in-out</xspecref> 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></def></gitem><gitem><label><code>element="ghns:checkAvailability" /></code></label><def><p>This specifies the message type for this input message, as defined previously in the <code>types</code> section.</p></def></gitem><gitem><label><code><output messageLabel="Out" . . .</code></label><def><p>This is similar to defining an input message.</p></def></gitem><gitem><label><code><outfault ref="tns:invalidDataFault" messageLabel="Out"/></code></label>def><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 <xspecref href="&w3c-designation-part2;#fault-trigger">message-triggers-fault rule</xspecref>; others use a <xspecref href="&w3c-designation-part2;#fault-replacement">fault-replaces-message</xspecref> rule. See <emph>WSDL 2.0 Predefied Extensions</emph> <bibref ref="WSDL-PART2"/> section 2.1.2 <xspecref href="&w3c-designation-part2;#fault-trigger">Message Triggers Fault</xspecref> and section 2.1.1 <xspecref href="&w3c-designation-part2;#fault-replacement">Fault Replaces Message</xspecref>.) </p></def></gitem></glist><p>Now that we've defined the abstract interface for the GreatH service, we're ready to define a binding for it.</p></div3></div2>
--- 316,320 ----
</p></def></gitem>
! <gitem><label><code>wsdlx:safe="true" ></code></label><def><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 <specref ref="more-interfaces-operations"/>. </p></def></gitem><gitem><label><code><input messageLabel="In"</code></label><def><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 <xspecref href="&w3c-designation-part2;#in-out">in-out</xspecref> patern 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 <emph>WSDL 2.0 Predefined Extensions</emph> <bibref ref="WSDL-PART2"/> section 2.2.3 <xspecref href="&w3c-designation-part2;#in-out">In-Out</xspecref> for the <xspecref href="&w3c-designation-part2;#in-out">in-out</xspecref> 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></def></gitem><gitem><label><code>element="ghns:checkAvailability" /></code></label><def><p>This specifies the message type for this input message, as defined previously in the <code>types</code> section.</p></def></gitem><gitem><label><code><output messageLabel="Out" . . .</code></label><def><p>This is similar to defining an input message.</p></def></gitem><gitem><label><code><outfault ref="tns:invalidDataFault" messageLabel="Out"/></code></abel><def><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 <xspecref href="&w3c-designation-part2;#fault-trigger">message-triggers-fault rule</xspecref>; others use a <xspecref href="&w3c-designation-part2;#fault-replacement">fault-replaces-message</xspecref> rule. See <emph>WSDL 2.0 Pedefined Extensions</emph> <bibref ref="WSDL-PART2"/> section 2.1.2 <xspecref href="&w3c-designation-part2;#fault-trigger">Message Triggers Fault</xspecref> and section 2.1.1 <xspecref href="&w3c-designation-part2;#fault-replacement">Fault Replaces Message</xspecref>.) </p></def></gitem></glist><p>Now that we've defined the abstract interface for the GreatH service, we're ready to define a binding for it.</p></div3></div2>
***************
*** 846,850 ****
pattern="<emph>xs:anyURI</emph>"
style="<emph>list of xs:anyURI</emph>"?
! safe="<emph>xs:boolean</emph>"? >
<input messageLabel="<emph>xs:NCName</emph>"?
--- 848,852 ----
pattern="<emph>xs:anyURI</emph>"
style="<emph>list of xs:anyURI</emph>"?
! wsdlx:safe="<emph>xs:boolean</emph>"? >
<input messageLabel="<emph>xs:NCName</emph>"?
***************
*** 950,954 ****
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
--- 952,956 ----
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! wsdlx:safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
***************
*** 1012,1016 ****
! <div3 id="more-interfaces-op-attr"><head>Operation Attributes</head><p>An <code>operation</code> has two required and two optional attributes:</p>
<ulist>
<item>
--- 1014,1018 ----
! <div3 id="more-interfaces-op-attr"><head>Operation Attributes</head><p>An <code>operation</code> has two required and an optional attributes:</p>
<ulist>
<item>
***************
*** 1033,1038 ****
! </item>
! </ulist></div3><div3><head>Operation Message References</head><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 <specref ref="basics-interface"/>, this section will merely comment on additional capabilities that were not previously explained.</p>
<div4>
<head>The messageLabel Attribute</head>
--- 1035,1044 ----
! </item>
!
! </ulist>
! <p>Note that <bibref ref="WSDL-PART2"/> provides a predefined extension for indicating operation safety. The <att>wsdlx:safe</att> 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 <bibref ref="webarch"/>) 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 <att>wsdlx:safe</att> 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 <bibref ref="webarch"/>, because tis 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>
!
! </div3><div3><head>Operation Message References</head><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 <specref ref="basics-interface"/>, this section will merely comment on additional capabilities that were not previously explained.</p>
<div4>
<head>The messageLabel Attribute</head>
***************
*** 1299,1303 ****
<description xmlns="http://www.w3.org/2005/05/wsdl"
. . .
- type="http://www.w3.org/2005/05/wsdl/http"
xmlns:whttp="http://www.w3.org/2005/05/wsdl/http" >
--- 1305,1308 ----
***************
*** 1305,1308 ****
--- 1310,1314 ----
<binding name="reservationHTTPBinding"
interface="tns:reservationInterface"
+ type="http://www.w3.org/2005/05/wsdl/http"
whttp:methodDefault="GET">
***************
*** 1324,1328 ****
</example>
<div3><head>Explanation of
! Example</head><ednote><name>dbooth</name><date>2005-04-15</date><edtext>ToDo: Check this section. I'm not sure I got it all right, particularly regarding whttp:location. Is the first sample request URI correct? Shouldn't instance data for tCheckAvailability be in the path component? What happens if a non-leaf element type is specified, such as tCheckAvailability?</edtext></ednote><p><glist><gitem>
<label><code>type="http://www.w3.org/2005/05/wsdl/http"</code></label>
<def>
--- 1330,1343 ----
</example>
<div3><head>Explanation of
! Example</head><ednote><name>dbooth</name><date>2005-04-15</date><edtext>ToDo: Check this section. I'm not sure I got it all right, particularly regarding whttp:location. Is the first sample request URI correct? Shouldn't instance data for tCheckAvailability be in the path component? What happens if a non-leaf element type is specified, such as tCheckAvailability?</edtext></ednote>
!
!
! <p>Most of this example is the same as previously explained in <specref ref="basics-binding"/>, so we'll only point out lines that are demonstrating something new.
!
! <glist>
! <gitem>
! <label><code>xmlns:whttp="http://www.w3.org/2005/05/wsdl/http" ></code></label><def><p>This defines the namespace prefix for elements and attributes defined by the WSDL 2.0 HTTP binding extension.</p></def></gitem>
!
! <gitem>
<label><code>type="http://www.w3.org/2005/05/wsdl/http"</code></label>
<def>
***************
*** 1331,1336 ****
</p>
</def>
! </gitem><gitem>
! <label><code>xmlns:whttp="http://www.w3.org/2005/05/wsdl/http" ></code></label><def><p>This defines the namespace prefix for elements and attributes defined by the WSDL 2.0 HTTP binding extension.</p></def></gitem><gitem><label><code>whttp:methodDefault="GET"></code></label><def><p>The default method for operations in this interface will be HTTP GET.</p></def></gitem><gitem><label><code>whttp:location="{checkInDate}" ></code></label><def><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 for would therefore be
<code>http://greath.example.com/2004/5-5-5?checkOutDate=6-6-5&roomType=foo</code>. </p></def></gitem></glist></p>
--- 1346,1352 ----
</p>
</def>
! </gitem>
!
! <gitem><label><code>whttp:methodDefault="GET"></code></label><def><p>The default method for operations in this interface will be HTTP GET.</p></def></gitem><gitem><label><code>whttp:location="{checkInDate}" ></code></label><def><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 for would therefore be
<code>http://greath.example.com/2004/5-5-5?checkOutDate=6-6-5&roomType=foo</code>. </p></def></gitem></glist></p>
***************
*** 1349,1353 ****
This would instead serialize to a request URI such as: <code>http://greath.example.com/2004/bycheckInDate/5-5-5</code>. The rest of the message content would go to the HTTP message body.</p></div3></div2>
<div2 id="adv-get-vs-post"><head>HTTP GET Versus POST: Which to Use?</head>
! <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 <emph>URIs, Addressability, and the use of HTTP GET and POST</emph> (<bibref ref="TAG-whenToUseGET"/>). From the abstract:</p><p><quote><emph>. . . 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.</emph></quote></p><p>Recall that the concept of a safe operation was disussed in <specref ref="more-interfaces-op-attr"/>. (Briefly, a safe operation is one that does not cause the invoker to incur new obligations.) Although the <code>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><ulist><item><p>If the WSDL 2.0 SOAP binding extension is used (<specref ref="more-bindings-soap"/>), with HTTP as the underlying transport protocol, then GET may be specified by setting:<glist><gitem><label><code>wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"</code></label><def><p>on the <code>binding</code> element (to indicate the use of HTTP as the underlying protocol); and</p></def></gitem><gitem><label><code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response/"</code></label><def><p>on the binding <code>operation</code> element, which causes GET to be used by defalt.</p></def></gitem></glist> </p></item><item><p>If the WSDL 2.0 HTTP binding extension is used directly (<specref ref="more-bindings-http"/>), GET may be specified by setting either:<glist><gitem><label><code>whttp:methodDefault="GET"</code></label><def><p>on the <code>binding</code> element; or</p></def></gitem><gitem><label><code>whttp:method="GET"</code></label><def><p>on the binding <code>operation</code> element, which overrides <code>whttp:methodDefault</code> if set on the <code>binding</code> element.</p></def></gitem></glist></p></item></ulist>
</div2></div1>
--- 1365,1369 ----
This would instead serialize to a request URI such as: <code>http://greath.example.com/2004/bycheckInDate/5-5-5</code>. The rest of the message content would go to the HTTP message body.</p></div3></div2>
<div2 id="adv-get-vs-post"><head>HTTP GET Versus POST: Which to Use?</head>
! <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 <emph>URIs, Addressability, and the use of HTTP GET and POST</emph> (<bibref ref="TAG-whenToUseGET"/>). From the abstract:</p><p><quote><emph>. . . 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.</emph></quote></p><p>Recall that the concept of a safe operation was disussed in <specref ref="more-interfaces-op-attr"/>. (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><ulist><item><p>If the WSDL 2.0 SOAP binding extension is used (<specref ref="more-bindings-soap"/>), with HTTP as the underlying transport protocol, then GET may be specified by setting:<glist><gitem><label><code>wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"</code></label><def><p>on the <code>binding</code> element (to indicate the use of HTTP as the underlying protocol); and</p></def></gitem><gitem><label><code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response/"</code></label><def><p>on the binding <code>operation</code> element, which causes GET to be used b default.</p></def></gitem></glist> </p></item><item><p>If the WSDL 2.0 HTTP binding extension is used directly (<specref ref="more-bindings-http"/>), GET may be specified by setting either:<glist><gitem><label><code>whttp:methodDefault="GET"</code></label><def><p>on the <code>binding</code> element; or</p></def></gitem><gitem><label><code>whttp:method="GET"</code></label><def><p>on the binding <code>operation</code> element, which overrides <code>whttp:methodDefault</code> if set on the <code>binding</code> element.</p></def></gitem></glist></p></item></ulist>
</div2></div1>
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.68
retrieving revision 1.69
diff -C2 -d -r1.68 -r1.69
*** wsdl20-primer.html 16 Jun 2005 01:30:39 -0000 1.68
--- wsdl20-primer.html 16 Jun 2005 22:47:50 -0000 1.69
***************
*** 1,3 ****
! <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html 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">
code { font-family: monospace; }
--- 1,3 ----
! <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<html 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">
code { font-family: monospace; }
***************
*** 45,49 ****
div.exampleHeader { font-weight: bold;
margin: 4px}
! </style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/base.css"><link type="" href="" title="" rel="alternate"><link href="#contents" rel="contents"></head><body>
<div class="head">
<h1>Web Services Description Language (WSDL) Version 2.0 Part 0: Primer</h1>
--- 45,49 ----
div.exampleHeader { font-weight: bold;
margin: 4px}
! </style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/base.css"><link rel="alternate" title="" href="" type=""><link rel="contents" href="#contents"></head><body>
<div class="head">
<h1>Web Services Description Language (WSDL) Version 2.0 Part 0: Primer</h1>
***************
*** 96,103 ****
<hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#Introduction">Introduction</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br>3. <a href="#wsdl-xml-representation">WSDL 2.0 Infoset, Schema and Component Model</a><br>4. <a href="#more-types">More on Message Types</a><br>5. <a href="#more-interfaces">More on Interfaces</a><br>6. <a href="#more-bindings">More on Bindings</a><br>7. <a href="#advanced-topic_ii">Advanced Topics</a><br>8. <a href="#References">References</a><br>A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="toc">
! <h2><a name="contents">Table of Contents</a></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="#notation">Notational Conventions</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br> 2.1 <a href="#basics-greath-scenario">Example Scenario: The GreatH Hotel Reservation Service</a><br> 2.2 <a href="#basics-getting-started">Getting Started: Defining a WSDL 2.0 Target Namespace</a><br> 2.2.1 <a href="#example-empty-shell-explanation">Explanation of Example</a><br> 2.3 <a href="#basics-types">Defining Message Types</a><br> 2.3.1 <a href="#example-initial-types-explanation">Explanation of Example</a><br> 2.4 <a href="#bascs-interface">Defining an Interface</a><br> 2.4.1 <a href="#example-initial-interface-explanation">Explanation of Example</a><br> 2.5 <a href="#basics-binding">Defining a Binding</a><br> 2.5.1 <a href="#example-initial-binding-explanation">Explanation of Example</a><br> 2.6 <a href="#basics-service">Defining a Service</a><br> 2.6.1 <a href="#example-initial-service-explanation">Explanation of Example</a><br> 2.7 <a href="#basics-documentation">Documenting the Service</a><br> 2.7.1 <a href="#example-initial-documentation-explanation">Explanation of Example</a><br>3. <a href="#wsdl-xml-representation">WSDL 2.0 Infoset, Schema and Component Model</a><br> 3.1 <a href="#wsdl-infoset-diagram">WSDL 2.0 Infoset</a><br> &nbs;3.2 <a href="#wsdl-schema">WSDL 2.0 Schema and Element Ordering</a><br> 3.3 <a href="#component-model">WSDL 2.0 Component Model</a><br>4. <a href="#more-types">More on Message Types</a><br> 4.1 <a href="#more-types-schema-inline">Inlining XML Schema</a><br> 4.2 <a href="#more-types-schema-import">Importing XML Schema</a><br> 4.3 <a href="#more-types-import-include-summary">Summary of Import and Include Mechanisms</a><br>5. <a href="#more-interfaces">More on Interfaces</a><br> 5.1 <a href="#more-interfaces-interfaces">Interface Syntax </a><br> 5.2 <a href="#more-interfaces-inheritance">Interface Inheritance</a><br> 5.3 <a href="#more-interfaces-faults">Interface Faults</a><br> 5.4 <a href="#more-interfaces-operations">Interface Operations</a><br> 5.4.1 <a href="#more-interfaces-opattr">Operation Attributes</a><br> 5.4.2 <a href="#N10912">Operation Message References</a><br> 5.4.2.1 <a href="#N1092F">The messageLabel Attribute</a><br> 5.4.2.2 <a href="#N10947">The element Attribute</a><br> 5.4.2.3 <a href="#N1098F">Multiple infault or outfault Elements</a><br> 5.4.3 <a href="#more-interfaces-meps">Understanding Message Exchange Patterns (MEPs)</a><br>6. <a href="#more-bindings">More on Bindings</a><br> 6.1 <a href="#more-bindings-wsdl">Syntax Summary for Bindings</a><br> 6.2 <a href="#more-bindings-reusable">Reusable Bindings</a><br> 6.3 <a href="#more-bindings-faults">Binding Faults</a><br> .4 <a href="#bindingOperations">Binding Operations</a><br> 6.5 <a href="#more-bindings-soap">The SOAP Binding Extension</a><br> 6.5.1 <a href="#more-bindings-soap-example-explanation">Explanation of Example</a><br> 6.6 <a href="#more-bindings-http">The HTTP Binding Extension</a><br> 6.6.1 <a href="#N10B4C">Explanation of
! Example</a><br> 6.7 <a href="#adv-get-vs-post">HTTP GET Versus POST: Which to Use?</a><br>7. <a href="#advanced-topic_ii">Advanced Topics</a><br> 7.1 <a href="#adv-extensibility">Extensibility</a><br> 7.1.1 <a href="#adv-optional-versus-required">Optional Versus Required Extensions</a><br> 7.2 <a href="#adv-FP">Features and Properties</a><br> 7.2.1 <a href="#adv-FP-soap-modules">SOAP Modules</a><br> 7.2.2 <a href="#adv-FP-abstract-features">Abstract Features</a><br> 7.2.3 <a href="#adv-fp-properties">Properties</a><br> 7.3 <a href="#adv-MEP">Defining New MEPs</a><br> 7.3.1 <a href="#challenge-confirm">Confirmed Challenge</a><br> 7.4 <a href="#adv-import-and-athoring">Import mechanism and authoring style</a><br> 7.5 <a href="#adv-multiple-docs-describing-same-service">Multiple Interfaces for the Same Service</a><br> 7.6 <a href="#adv-versioning">Web Service Versioning</a><br> 7.6.1 <a href="#adv-versioning-compatible-evolution">Compatible Evolution</a><br> 7.6.2 <a href="#adv-versioning-big-bang">Big Bang</a><br> 7.6.3 <a href="#ad-versioing-migration">Evolving a Service</a><br> 7.6.4 <a href="#adv-versioning-combined">Combined Approaches</a><br> 7.7 <a href="#adv-MTOM">MTOM Support</a><br> 7.8 <a href="#adv-RPCstyle">RPC Style</a><br> 7.9 <a href="#adv-message-dispatch">Enabling Easy Message Dispatch</a><br> 7.10 <a href="#adv-service-refereces">Service and Endpoint References</a><br> 7.10.1 <a href="#reservationDetails">The Reservation Details Web Service</a><br> 7.10.2 <a href="#reservationList">The Reservation List Web Service</a><br> 7.10.3 <a href="#reservationDetails_HTTP">Reservation Details Web Service Using HTTP Transfer</a><br> 7.10.4 <a href="#reservationList_HTTP_GET">Reservation List Web Service Using HTTP GET</a><br> 7.11 <a href="#adv-multiple-inline-schemas">Importing Schemas</a><br> 7.11.1 <a href="#N1118B">Schemas in Imported Documents</a><br> 7.11.2 <a href="#N11216">Multiple Inline Schemas in One Document</a><br> 7.11.3 <a href="#adv-schema-location">The schemaLocation Attribute/a><br> 7.11.3.1 <a href="#N11276">Using the id Attribute to Identify Inline
Schemas</a><br> 7.12 <a href="#adv-rdf-mapping">Mapping to RDF and Semantic Web</a><br> 7.12.1 <a href="#adv-rdf-rep-wsdl">RDF Representation of WSDL 2.0</a><br> 7.13 <a href="#adv-notes-on-uris">Notes on URIs</a><br> 7.13.1 <a href="#adv-namespaces-and-schema-locations">XML Namespaces and Schema Locations</a><br> 7.13.2 <a href="#adv-relative-uris">Relative URIs</a><br> 7.13.3 <a href="#adv-generating-uris">Generating Temporary URIs</a><br>8. <a href="#References">References</a><br> 8.1 <a href="#Normative-References">Normative References</a><br> 8.2 <a href="#Informative-References">Informative References</a><br></p>
! <h3><a id="appendix" name="appendix">Appendix</a></h3><p class="toc">A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="body">
--- 96,103 ----
<hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#Introduction">Introduction</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br>3. <a href="#wsdl-xml-representation">WSDL 2.0 Infoset, Schema and Component Model</a><br>4. <a href="#more-types">More on Message Types</a><br>5. <a href="#more-interfaces">More on Interfaces</a><br>6. <a href="#more-bindings">More on Bindings</a><br>7. <a href="#advanced-topic_ii">Advanced Topics</a><br>8. <a href="#References">References</a><br>A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="toc">
! <h2><a name="contents">Table of Contents</a></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="#notation">Notational Conventions</a><br>2. <a href="#basics">WSDL 2.0 Basics</a><br> 2.1 <a href="#basics-greath-scenario">Example Scenario: The GreatH Hotel Reservation Service</a><br> 2.2 <a href="#basics-getting-started">Getting Started: Defining a WSDL 2.0 Target Namespace</a><br> 2.2.1 <a href="#example-empty-shell-explanation">Explanation of Example</a><br> 2.3 <a href="#basics-types">Defining Message Types</a><br> 2.3.1 <a href="#example-initial-types-explanation">Explanation of Example</a><br> 2.4 <a href="#bascs-interface">Defining an Interface</a><br> 2.4.1 <a href="#example-initial-interface-explanation">Explanation of Example</a><br> 2.5 <a href="#basics-binding">Defining a Binding</a><br> 2.5.1 <a href="#example-initial-binding-explanation">Explanation of Example</a><br> 2.6 <a href="#basics-service">Defining a Service</a><br> 2.6.1 <a href="#example-initial-service-explanation">Explanation of Example</a><br> 2.7 <a href="#basics-documentation">Documenting the Service</a><br> 2.7.1 <a href="#example-initial-documentation-explanation">Explanation of Example</a><br>3. <a href="#wsdl-xml-representation">WSDL 2.0 Infoset, Schema and Component Model</a><br> 3.1 <a href="#wsdl-infoset-diagram">WSDL 2.0 Infoset</a><br> &nbs;3.2 <a href="#wsdl-schema">WSDL 2.0 Schema and Element Ordering</a><br> 3.3 <a href="#component-model">WSDL 2.0 Component Model</a><br>4. <a href="#more-types">More on Message Types</a><br> 4.1 <a href="#more-types-schema-inline">Inlining XML Schema</a><br> 4.2 <a href="#more-types-schema-import">Importing XML Schema</a><br> 4.3 <a href="#more-types-import-include-summary">Summary of Import and Include Mechanisms</a><br>5. <a href="#more-interfaces">More on Interfaces</a><br> 5.1 <a href="#more-interfaces-interfaces">Interface Syntax </a><br> 5.2 <a href="#more-interfaces-inheritance">Interface Inheritance</a><br> 5.3 <a href="#more-interfaces-faults">Interface Faults</a><br> 5.4 <a href="#more-interfaces-operations">Interface Operations</a><br> 5.4.1 <a href="#more-interfaces-opattr">Operation Attributes</a><br> 5.4.2 <a href="#N67881">Operation Message References</a><br> 5.4.2.1 <a href="#N67910">The messageLabel Attribute</a><br> 5.4.2.2 <a href="#N67934">The element Attribute</a><br> 5.4.2.3 <a href="#N68006">Multiple infault or outfault Elements</a><br> 5.4.3 <a href="#more-interfaces-meps">Understanding Message Exchange Patterns (MEPs)</a><br>6. <a href="#more-bindings">More on Bindings</a><br> 6.1 <a href="#more-bindings-wsdl">Syntax Summary for Bindings</a><br> 6.2 <a href="#more-bindings-reusable">Reusable Bindings</a><br> 6.3 <a href="#more-bindings-faults">Binding Faults</a><br> .4 <a href="#bindingOperations">Binding Operations</a><br> 6.5 <a href="#more-bindings-soap">The SOAP Binding Extension</a><br> 6.5.1 <a href="#more-bindings-soap-example-explanation">Explanation of Example</a><br> 6.6 <a href="#more-bindings-http">The HTTP Binding Extension</a><br> 6.6.1 <a href="#N68451">Explanation of
! Example</a><br> 6.7 <a href="#adv-get-vs-post">HTTP GET Versus POST: Which to Use?</a><br>7. <a href="#advanced-topic_ii">Advanced Topics</a><br> 7.1 <a href="#adv-extensibility">Extensibility</a><br> 7.1.1 <a href="#adv-optional-versus-required">Optional Versus Required Extensions</a><br> 7.2 <a href="#adv-FP">Features and Properties</a><br> 7.2.1 <a href="#adv-FP-soap-modules">SOAP Modules</a><br> 7.2.2 <a href="#adv-FP-abstract-features">Abstract Features</a><br> 7.2.3 <a href="#adv-fp-properties">Properties</a><br> 7.3 <a href="#adv-MEP">Defining New MEPs</a><br> 7.3.1 <a href="#challenge-confirm">Confirmed Challenge</a><br> 7.4 <a href="#adv-import-and-athoring">Import mechanism and authoring style</a><br> 7.5 <a href="#adv-multiple-docs-describing-same-service">Multiple Interfaces for the Same Service</a><br> 7.6 <a href="#adv-versioning">Web Service Versioning</a><br> 7.6.1 <a href="#adv-versioning-compatible-evolution">Compatible Evolution</a><br> 7.6.2 <a href="#adv-versioning-big-bang">Big Bang</a><br> 7.6.3 <a href="#ad-versioing-migration">Evolving a Service</a><br> 7.6.4 <a href="#adv-versioning-combined">Combined Approaches</a><br> 7.7 <a href="#adv-MTOM">MTOM Support</a><br> 7.8 <a href="#adv-RPCstyle">RPC Style</a><br> 7.9 <a href="#adv-message-dispatch">Enabling Easy Message Dispatch</a><br> 7.10 <a href="#adv-service-refereces">Service and Endpoint References</a><br> 7.10.1 <a href="#reservationDetails">The Reservation Details Web Service</a><br> 7.10.2 <a href="#reservationList">The Reservation List Web Service</a><br> 7.10.3 <a href="#reservationDetails_HTTP">Reservation Details Web Service Using HTTP Transfer</a><br> 7.10.4 <a href="#reservationList_HTTP_GET">Reservation List Web Service Using HTTP GET</a><br> 7.11 <a href="#adv-multiple-inline-schemas">Importing Schemas</a><br> 7.11.1 <a href="#N70058">Schemas in Imported Documents</a><br> 7.11.2 <a href="#N70197">Multiple Inline Schemas in One Document</a><br> 7.11.3 <a href="#adv-schema-location">The schemaLocation Attribute/a><br> 7.11.3.1 <a href="#N70293">Using the id Attribute to Identify Inline
Schemas</a><br> 7.12 <a href="#adv-rdf-mapping">Mapping to RDF and Semantic Web</a><br> 7.12.1 <a href="#adv-rdf-rep-wsdl">RDF Representation of WSDL 2.0</a><br> 7.13 <a href="#adv-notes-on-uris">Notes on URIs</a><br> 7.13.1 <a href="#adv-namespaces-and-schema-locations">XML Namespaces and Schema Locations</a><br> 7.13.2 <a href="#adv-relative-uris">Relative URIs</a><br> 7.13.3 <a href="#adv-generating-uris">Generating Temporary URIs</a><br>8. <a href="#References">References</a><br> 8.1 <a href="#Normative-References">Normative References</a><br> 8.2 <a href="#Informative-References">Informative References</a><br></p>
! <h3><a name="appendix" id="appendix">Appendix</a></h3><p class="toc">A. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="body">
***************
*** 147,151 ****
<div class="div2">
<h3><a name="basics-greath-scenario"></a>2.1 Example Scenario: The GreatH Hotel Reservation Service</h3><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: <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><p>The next several sections proceed step-by-step through the process of deeloping 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 class="exampleHead" style="text-align: left"><a name="example-initial"></a><i><span>Example 2-1. </span>WSDL 2.0 Document for the GreatH Web Service (Initial Example)</i></p>
<div class="exampleInner"><pre>
<?xml version="1.0" encoding="utf-8" ?>
--- 147,151 ----
<div class="div2">
<h3><a name="basics-greath-scenario"></a>2.1 Example Scenario: The GreatH Hotel Reservation Service</h3><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: <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><p>The next several sections proceed step-by-step through the process of deeloping 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"></a><i><span>Example 2-1. </span>WSDL 2.0 Document for the GreatH Web Service (Initial Example)</i></p>
<div class="exampleInner"><pre>
<?xml version="1.0" encoding="utf-8" ?>
***************
*** 156,160 ****
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
xmlns:wsoap= "http://www.w3.org/2005/05/wsdl/soap"
! xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<documentation>
--- 156,161 ----
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
xmlns:wsoap= "http://www.w3.org/2005/05/wsdl/soap"
! xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
! xmlns:wsdlx= "http://www.w3.org/@@@@/@@/wsdl-extensions">
<documentation>
***************
*** 195,199 ****
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
--- 196,200 ----
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! wsdlx:safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
***************
*** 233,237 ****
</div><div class="div2">
<h3><a name="basics-getting-started"></a>2.2 Getting Started: Defining a WSDL 2.0 Target Namespace</h3><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 trget 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 2.0 document as the following empty shell.</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-empty-shell"></a><i><span>Example 2-2. </span>An Initial Empty WSDL 2.0 2.0 Document</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description
--- 234,238 ----
</div><div class="div2">
<h3><a name="basics-getting-started"></a>2.2 Getting Started: Defining a WSDL 2.0 Target Namespace</h3><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 trget 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 2.0 document as the following empty shell.</p><div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-empty-shell"></a><i><span>Example 2-2. </span>An Initial Empty WSDL 2.0 2.0 Document</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description
***************
*** 258,262 ****
<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/1999/REC-xml-names-19990114/#ns-qualnames">Qualified Names/a>.)</p></dd></dl><p></p><p> Now we can start describing the GreatH service. </p></div></div><div class="div2">
<h3><a name="basics-types"></a>2.3 Defining Message Types</h3><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>elemens</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 class="exampleHead" style="text-align: left"><a name="example-initial-types"></a><i><span>Example 2-3. </span>GreatH Message Types</i></p>
<div class="exampleInner"><pre>
<?xml version="1.0" encoding="utf-8" ?>
--- 259,263 ----
<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/1999/REC-xml-names-19990114/#ns-qualnames">Qualified Names/a>.)</p></dd></dl><p></p><p> Now we can start describing the GreatH service. </p></div></div><div class="div2">
<h3><a name="basics-types"></a>2.3 Defining Message Types</h3><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>elemens</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"></a><i><span>Example 2-3. </span>GreatH Message Types</i></p>
<div class="exampleInner"><pre>
<?xml version="1.0" encoding="utf-8" ?>
***************
*** 300,304 ****
<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="wsdl20-adjuncts.html#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="wsdl20-adjuncts.html#in-out">in-only</a> and <a href="wsdl20-adjuncts.html#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="wsdl20-adjuncts.html#in-only">In-Only</a> and section 2.2.5 <a href="wsdl20-adjuncts.html#out-only">Out-Only</a>), but that would just complicate matters for the client, because we would then have to separately indicate to the cient 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 class="exampleHead" style="text-align: left"><a name="example-initial-interface"></a><i><span>Example 2-4. </span>GreatH Interface Definition</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
--- 301,305 ----
<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="wsdl20-adjuncts.html#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="wsdl20-adjuncts.html#in-out">in-only</a> and <a href="wsdl20-adjuncts.html#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="wsdl20-adjuncts.html#in-only">In-Only</a> and section 2.2.5 <a href="wsdl20-adjuncts.html#out-only">Out-Only</a>), but that would just complicate matters for the client, because we would then have to separately indicate to the cient 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"></a><i><span>Example 2-4. </span>GreatH Interface Definition</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
***************
*** 308,312 ****
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
! . . . >
. . .
--- 309,314 ----
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
! . . .
! xmlns:wsdlx= "http://www.w3.org/@@@@/@@/wsdl-extensions">
. . .
***************
*** 323,327 ****
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
--- 325,329 ----
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! wsdlx:safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
***************
*** 344,348 ****
</p></dd>
! <dt class="label"><code>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"><b>5.4 Interface Operations</b></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="wsdl20-adjuncts.html#in-out">in-out</a> patten 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="wsdl20-adjuncts.html#in-out">In-Out</a> for the <a href="wsdl20-adjuncts.html#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 ouput 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="wsdl20-adjuncts.html#fault-trigger">message-triggers-fault rule</a>; others use a <a href="wsdl20-adjuncts.html#fault-replacement">fault-replaces-message</a> rule. See <em>WSDL 2.0 Predefined Extensions</em> [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjunct</a></cite>] section 2.1.2 <a href="wsdl20-adjuncts.html#fault-trigger">Message Triggers Fault</a> and section 2.1.1 <a href="wsdl20-adjuncts.html#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>
--- 346,350 ----
</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"><b>5.4 Interface Operations</b></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="wsdl20-adjuncts.html#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="wsdl20-adjuncts.html#in-out">In-Out</a> for the <a href="wsdl20-adjuncts.html#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 associatesan 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="wsdl20-adjuncts.html#fault-trigger">message-triggers-fault rule</a>; others use a <a href="wsdl20-adjuncts.html#fault-replacement">fault-replaces-message</a> rule. See <em>WSDL 2.0 Predefined Extensions</em> [<cite><a href="#WSDL-PART2">WSDL 2.0 Ajuncts</a></cite>] section 2.1.2 <a href="wsdl20-adjuncts.html#fault-trigger">Message Triggers Fault</a> and section 2.1.1 <a href="wsdl20-adjuncts.html#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>
***************
*** 401,405 ****
</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 class="exampleHead" style="text-align: left"><a name="example-initial-binding"></a><i><span>Example 2-5. </span>GreatH Binding Definition</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description
--- 403,407 ----
</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"></a><i><span>Example 2-5. </span>GreatH Binding Definition</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description
***************
*** 454,458 ****
<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"><b>6.7 HTTP GET Versus POST: Which to Use?</b></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 f subcodes can also be specified using the optional <code>wsoap:subcodes</code> attribute.</p></dd></dl></div></div><div class="div2">
<h3><a name="basics-service"></a>2.6 Defining a Service</h3><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"><b>7.5 Multiple Interfaces for the Same Service</b></a> for further discussion of this limitation.) </p><p>Here is a definition for our GreatH service.</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-initial-service"></a><i><span>Example 2-6. </span>GreatH Service Definition</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description
--- 456,460 ----
<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"><b>6.7 HTTP GET Versus POST: Which to Use?</b></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 f subcodes can also be specified using the optional <code>wsoap:subcodes</code> attribute.</p></dd></dl></div></div><div class="div2">
<h3><a name="basics-service"></a>2.6 Defining a Service</h3><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"><b>7.5 Multiple Interfaces for the Same Service</b></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"></a><i><span>Example 2-6. </span>GreatH Service Definition</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description
***************
*** 494,498 ****
<div class="div2">
<h3><a name="basics-documentation"></a>2.7 Documenting the Service</h3><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"><b>3.1 SDL 2.0 Infoset</b></a>), though in this example we have only demonstrated its use at the beginning.</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-initial-documentation"></a><i><span>Example 2-7. </span>Documenting the GreatH Service</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description
--- 496,500 ----
<div class="div2">
<h3><a name="basics-documentation"></a>2.7 Documenting the Service</h3><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"><b>3.1 SDL 2.0 Infoset</b></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"></a><i><span>Example 2-7. </span>Documenting the GreatH Service</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description
***************
*** 526,530 ****
<p>The following diagram gives an overview of the XML Infoset for a WSDL 2.0 document.
! <div style="text-align: center" class="figure"><br><img src="images/WSDL20InfosetModel.png" alt="WSDL 2.0 Infoset Diagram"><p style="text-align:left"><i><span>Figure 3-1. </span>WSDL 2.0 Infoset Diagram</i></p><br></div>
</p>
--- 528,532 ----
<p>The following diagram gives an overview of the XML Infoset for a WSDL 2.0 document.
! <div class="figure" style="text-align: center"><br><img src="images/WSDL20InfosetModel.png" alt="WSDL 2.0 Infoset Diagram"><p style="text-align:left"><i><span>Figure 3-1. </span>WSDL 2.0 Infoset Diagram</i></p><br></div>
</p>
***************
*** 541,545 ****
<p>The WSDL 2.0 specification supplies a <a href="http://www.w3.org/2005/05/wsdl">normative WSDL 2.0 schema</a>, defined in XML Schema [<cite><a href="#XMLSchemaP1">XML Schema: Structures</a></cite>] [<cite><a href="#XMLSchemaP2">XML Schema: Datatypes</a></cite>], which can be used as an aid in validating WSDL 2.0 documents.
! <table border="1" summary="Editorial note: KevinL"><tr><td width="50%" valign="top" align="left"><b>Editorial note: KevinL</b></td><td width="50%" valign="top" align="right">20050428</td></tr><tr><td valign="top" align="left" colspan="2">
ToDo: update link to wsdl2.0 schema when final uri is available
</td></tr></table>
--- 543,547 ----
<p>The WSDL 2.0 specification supplies a <a href="http://www.w3.org/2005/05/wsdl">normative WSDL 2.0 schema</a>, defined in XML Schema [<cite><a href="#XMLSchemaP1">XML Schema: Structures</a></cite>] [<cite><a href="#XMLSchemaP2">XML Schema: Datatypes</a></cite>], which can be used as an aid in validating WSDL 2.0 documents.
! <table border="1" summary="Editorial note: KevinL"><tr><td align="left" valign="top" width="50%"><b>Editorial note: KevinL</b></td><td align="right" valign="top" width="50%">20050428</td></tr><tr><td colspan="2" align="left" valign="top">
ToDo: update link to wsdl2.0 schema when final uri is available
</td></tr></table>
***************
*** 633,637 ****
<h3><a name="component-model"></a>3.3 WSDL 2.0 Component Model</h3><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 hiearchy.
! <div style="text-align: center" class="figure"><br><img src="images/WSDL20Components.png" alt="WSDL 2.0 Components Containment Hiearchy"><p style="text-align:left"><i><span>Figure 3-2. </span>WSDL 2.0 Components Containment Hiearchy</i></p><br></div></p>
--- 635,639 ----
<h3><a name="component-model"></a>3.3 WSDL 2.0 Component Model</h3><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 hiearchy.
! <div class="figure" style="text-align: center"><br><img src="images/WSDL20Components.png" alt="WSDL 2.0 Components Containment Hiearchy"><p style="text-align:left"><i><span>Figure 3-2. </span>WSDL 2.0 Components Containment Hiearchy</i></p><br></div></p>
***************
*** 706,713 ****
<p>The WSDL 2.0 <code>types</code> element provides a mechanism for enclosing message schemas in a WSDL 2.0 document. Because WSDL 2.0 directly supports schemas written in XML Schema
[<cite><a href="#XMLSchemaP1">XML Schema: Structures</a></cite>], we will focus here on the use of XML Schema to define message types. Schemas written in other type definition languages must be defined using a WSDL 2.0 language extension. For examples of other schema languages, see WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0 Core Language</a></cite>] Appendix E "<a href="wsdl20.html#other-schemalang">Examples of Specifications of Extension Elements for Alternative Schema Language Support. (Non-Normative)</a>".
! <table border="1" summary="Editorial note: dbooth"><tr><td width="50%" valign="top" align="left"><b>Editorial note: dbooth</b></td><td width="50%" valign="top" align="right">2005-04-13</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Update the above reference to appendix E, as the WG decided to move it to a separate document.</td></tr></table></p>
! <table border="1" summary="Editorial note: dbooth"><tr><td width="50%" valign="top" align="left"><b>Editorial note: dbooth</b></td><td width="50%" valign="top" align="right">2005-04-13</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Check the sections below on import and include mechanisms for correctness. (Be sure to check the table also.) I'm not sure I got them all right.</td></tr></table><p>There are two ways to indicate XML Schema message definitions using the <code>types</code> element.
One way is to inline schema definitions within <code>xs:schema</code> elements that are children of <code>types</code>, as we have already seen. The other way is to use <code>xs:import</code> directly under <code>types</code>. It is perfectly reasonable to use both ways in one WSDL 2.0 document.</p>
--- 708,715 ----
<p>The WSDL 2.0 <code>types</code> element provides a mechanism for enclosing message schemas in a WSDL 2.0 document. Because WSDL 2.0 directly supports schemas written in XML Schema
[<cite><a href="#XMLSchemaP1">XML Schema: Structures</a></cite>], we will focus here on the use of XML Schema to define message types. Schemas written in other type definition languages must be defined using a WSDL 2.0 language extension. For examples of other schema languages, see WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0 Core Language</a></cite>] Appendix E "<a href="wsdl20.html#other-schemalang">Examples of Specifications of Extension Elements for Alternative Schema Language Support. (Non-Normative)</a>".
! <table border="1" summary="Editorial note: dbooth"><tr><td align="left" valign="top" width="50%"><b>Editorial note: dbooth</b></td><td align="right" valign="top" width="50%">2005-04-13</td></tr><tr><td colspan="2" align="left" valign="top">ToDo: Update the above reference to appendix E, as the WG decided to move it to a separate document.</td></tr></table></p>
! <table border="1" summary="Editorial note: dbooth"><tr><td align="left" valign="top" width="50%"><b>Editorial note: dbooth</b></td><td align="right" valign="top" width="50%">2005-04-13</td></tr><tr><td colspan="2" align="left" valign="top">ToDo: Check the sections below on import and include mechanisms for correctness. (Be sure to check the table also.) I'm not sure I got them all right.</td></tr></table><p>There are two ways to indicate XML Schema message definitions using the <code>types</code> element.
One way is to inline schema definitions within <code>xs:schema</code> elements that are children of <code>types</code>, as we have already seen. The other way is to use <code>xs:import</code> directly under <code>types</code>. It is perfectly reasonable to use both ways in one WSDL 2.0 document.</p>
***************
*** 777,781 ****
<p>Here is an example of importing a schema. 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 imported into the WSDL 2.0 as follows: </p>
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-schema-import"></a><i><span>Example 4-1. </span>Example of Importing Message Definitions</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description
--- 779,783 ----
<p>Here is an example of importing a schema. 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 imported into the WSDL 2.0 as follows: </p>
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-schema-import"></a><i><span>Example 4-1. </span>Example of Importing Message Definitions</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description
***************
*** 887,891 ****
pattern="<em>xs:anyURI</em>"
style="<em>list of xs:anyURI</em>"?
! safe="<em>xs:boolean</em>"? >
<input messageLabel="<em>xs:NCName</em>"?
--- 889,893 ----
pattern="<em>xs:anyURI</em>"
style="<em>list of xs:anyURI</em>"?
! wsdlx:safe="<em>xs:boolean</em>"? >
<input messageLabel="<em>xs:NCName</em>"?
***************
*** 971,975 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-faults"></a><i><span>Example 5-1. </span>Interface Inheritance</i></p>
<div class="exampleInner"><pre>
--- 973,977 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-faults"></a><i><span>Example 5-1. </span>Interface Inheritance</i></p>
<div class="exampleInner"><pre>
***************
*** 991,995 ****
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
--- 993,997 ----
pattern="http://www.w3.org/2005/05/wsdl/in-out"
style="http://www.w3.org/2005/05/wsdl/style/uri"
! wsdlx:safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
***************
*** 1056,1060 ****
<div class="div3">
! <h4><a name="more-interfaces-op-attr"></a>5.4.1 Operation Attributes</h4><p>An <code>operation</code> has two required and two optional attributes:</p>
<ul>
<li>
--- 1058,1062 ----
<div class="div3">
! <h4><a name="more-interfaces-op-attr"></a>5.4.1 Operation Attributes</h4><p>An <code>operation</code> has two required and an optional attributes:</p>
<ul>
<li>
***************
*** 1077,1086 ****
! </li>
! </ul></div><div class="div3">
! <h4><a name="N10912"></a>5.4.2 Operation Message References</h4><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"><b>2.4 Defining an Interface</b></a>, this section will merely comment on additional capabilities that were not previously explained.</p>
<div class="div4">
! <h5><a name="N1092F"></a>5.4.2.1 The messageLabel Attribute</h5>
<p>
The
--- 1079,1092 ----
! </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 Setion 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="div3">
! <h4><a name="N67881"></a>5.4.2 Operation Message References</h4><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"><b>2.4 Defining an Interface</b></a>, this section will merely comment on additional capabilities that were not previously explained.</p>
<div class="div4">
! <h5><a name="N67910"></a>5.4.2.1 The messageLabel Attribute</h5>
<p>
The
***************
*** 1102,1106 ****
<div class="div4">
! <h5><a name="N10947"></a>5.4.2.2 The element Attribute</h5>
<p>
The
--- 1108,1112 ----
<div class="div4">
! <h5><a name="N67934"></a>5.4.2.2 The element Attribute</h5>
<p>
The
***************
*** 1161,1165 ****
</div>
<div class="div4">
! <h5><a name="N1098F"></a>5.4.2.3 Multiple infault or outfault Elements</h5><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>
--- 1167,1171 ----
</div>
<div class="div4">
! <h5><a name="N68006"></a>5.4.2.3 Multiple infault or outfault Elements</h5><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>
***************
*** 1180,1184 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-outbound-operation"></a><i><span>Example 5-2. </span>Use of outbound MEPs</i></p>
<div class="exampleInner"><pre>
--- 1186,1190 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-outbound-operation"></a><i><span>Example 5-2. </span>Use of outbound MEPs</i></p>
<div class="exampleInner"><pre>
***************
*** 1277,1281 ****
<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"><b>2.5 Defining a Binding</b></a>, but some additional points are worth mentioning:<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 bth), 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"><b>6.7 HTTP GET Versus POST: Which to Use?</b></a>.)</p></li></ul></p><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 class="exampleHead" style="text-align: left"><a name="example-binding-soap"></a><i><span>Example 6-1. </span>SOAP 1.2 and SOAP 1.1 Bindings</i></p>
<div class="exampleInner"><pre>
--- 1283,1287 ----
<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"><b>2.5 Defining a Binding</b></a>, but some additional points are worth mentioning:<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 bth), 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"><b>6.7 HTTP GET Versus POST: Which to Use?</b></a>.)</p></li></ul></p><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"></a><i><span>Example 6-1. </span>SOAP 1.2 and SOAP 1.1 Bindings</i></p>
<div class="exampleInner"><pre>
***************
*** 1351,1360 ****
<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:<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><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 n 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 class="exampleHead" style="text-align: left"><a name="example-bindings-http"></a><i><span>Example 6-2. </span>HTTP Binding Extension</i></p>
<div class="exampleInner"><pre>
<?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
. . .
- type="http://www.w3.org/2005/05/wsdl/http"
xmlns:whttp="http://www.w3.org/2005/05/wsdl/http" >
--- 1357,1365 ----
<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:<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><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 n 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"></a><i><span>Example 6-2. </span>HTTP Binding Extension</i></p>
<div class="exampleInner"><pre>
<?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
. . .
xmlns:whttp="http://www.w3.org/2005/05/wsdl/http" >
***************
*** 1362,1365 ****
--- 1367,1371 ----
<binding name="reservationHTTPBinding"
interface="tns:reservationInterface"
+ type="http://www.w3.org/2005/05/wsdl/http"
whttp:methodDefault="GET">
***************
*** 1381,1386 ****
</div>
<div class="div3">
! <h4><a name="N10B4C"></a>6.6.1 Explanation of
! Example</h4><table border="1" summary="Editorial note: dbooth"><tr><td width="50%" valign="top" align="left"><b>Editorial note: dbooth</b></td><td width="50%" valign="top" align="right">2005-04-15</td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Check this section. I'm not sure I got it all right, particularly regarding whttp:location. Is the first sample request URI correct? Shouldn't instance data for tCheckAvailability be in the path component? What happens if a non-leaf element type is specified, such as tCheckAvailability?</td></tr></table><p></p><dl>
<dt class="label"><code>type="http://www.w3.org/2005/05/wsdl/http"</code></dt>
<dd>
--- 1387,1401 ----
</div>
<div class="div3">
! <h4><a name="N68451"></a>6.6.1 Explanation of
! Example</h4><table border="1" summary="Editorial note: dbooth"><tr><td align="left" valign="top" width="50%"><b>Editorial note: dbooth</b></td><td align="right" valign="top" width="50%">2005-04-15</td></tr><tr><td colspan="2" align="left" valign="top">ToDo: Check this section. I'm not sure I got it all right, particularly regarding whttp:location. Is the first sample request URI correct? Shouldn't instance data for tCheckAvailability be in the path component? What happens if a non-leaf element type is specified, such as tCheckAvailability?</td></tr></table>
!
!
! <p>Most of this example is the same as previously explained in <a href="#basics-binding"><b>2.5 Defining a Binding</b></a>, so we'll only point out lines that are demonstrating something new.
!
! </p><dl>
!
! <dt class="label"><code>xmlns:whttp="http://www.w3.org/2005/05/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>type="http://www.w3.org/2005/05/wsdl/http"</code></dt>
<dd>
***************
*** 1390,1399 ****
</dd>
! <dt class="label"><code>xmlns:whttp="http://www.w3.org/2005/05/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>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 for would therefore be
<code>http://greath.example.com/2004/5-5-5?checkOutDate=6-6-5&roomType=foo</code>. </p></dd></dl><p></p>
<p>Here is an alternate example that serializes appends "/" to the type name in order to serialize the remaining instance data into the message body:</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-bindings-http-path-subsset"></a><i><span>Example 6-3. </span>Serializing a Subset of Types in the Path</i></p>
<div class="exampleInner"><pre>
--- 1405,1415 ----
</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 for would therefore be
<code>http://greath.example.com/2004/5-5-5?checkOutDate=6-6-5&roomType=foo</code>. </p></dd></dl><p></p>
<p>Here is an alternate example that serializes 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"></a><i><span>Example 6-3. </span>Serializing a Subset of Types in the Path</i></p>
<div class="exampleInner"><pre>
***************
*** 1408,1412 ****
<div class="div2">
<h3><a name="adv-get-vs-post"></a>6.7 HTTP GET Versus POST: Which to Use?</h3>
! <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 o a safe operation was discussed in <a href="#more-interfaces-op-attr"><b>5.4.1 Operation Attributes</b></a>. (Briefly, a safe operation is one that does not cause the invoker to incur new obligations.) Although the <code>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"><b>6.5 The SOAP Binding Extension</b></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>o the binding <code>operation</code> element, which causes GET to be used by default.</p></dd></dl><p> </p></li><li><p>If the WSDL 2.0 HTTP binding extension is used directly (<a href="#more-bindings-http"><b>6.6 The HTTP Binding Extension</b></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.</p></dd></dl><p></p></li></ul>
</div></div>
--- 1424,1428 ----
<div class="div2">
<h3><a name="adv-get-vs-post"></a>6.7 HTTP GET Versus POST: Which to Use?</h3>
! <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 o a safe operation was discussed in <a href="#more-interfaces-op-attr"><b>5.4.1 Operation Attributes</b></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"><b>6.5 The SOAP Binding Extension</b></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><d><p>on the binding <code>operation</code> element, which causes GET to be used by default.</p></dd></dl><p> </p></li><li><p>If the WSDL 2.0 HTTP binding extension is used directly (<a href="#more-bindings-http"><b>6.6 The HTTP Binding Extension</b></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.</p></dd></dl><p></p></li></ul>
</div></div>
***************
*** 1436,1440 ****
<h3><a name="adv-FP"></a>7.2 Features and Properties</h3>
! <table border="1" summary="Editorial note: KevinL"><tr><td width="50%" valign="top" align="left"><b>Editorial note: KevinL</b></td><td width="50%" valign="top" align="right">20050519</td></tr><tr><td valign="top" align="left" colspan="2">
The section is subject to change. Pending on the resolution of the minority opinions filed about Feature and Property.
</td></tr></table>
--- 1452,1456 ----
<h3><a name="adv-FP"></a>7.2 Features and Properties</h3>
! <table border="1" summary="Editorial note: KevinL"><tr><td align="left" valign="top" width="50%"><b>Editorial note: KevinL</b></td><td align="right" valign="top" width="50%">20050519</td></tr><tr><td colspan="2" align="left" valign="top">
The section is subject to change. Pending on the resolution of the minority opinions filed about Feature and Property.
</td></tr></table>
***************
*** 1443,1447 ****
<div class="div3">
<h4><a name="adv-FP-soap-modules"></a>7.2.1 SOAP Modules</h4><p>The first step GreatH takes is to require the usage of the SOAP module in their normal SOAP/HTTP endpoint, which looks like this:</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-fp-requiring-soap-module"></a><i><span>Example 7-1. </span>Requiring a SOAP Module in an Endpoint</i></p>
<div class="exampleInner"><pre>
--- 1459,1463 ----
<div class="div3">
<h4><a name="adv-FP-soap-modules"></a>7.2.1 SOAP Modules</h4><p>The first step GreatH takes is to require the usage of the SOAP module in their normal SOAP/HTTP endpoint, which looks like this:</p><div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-fp-requiring-soap-module"></a><i><span>Example 7-1. </span>Requiring a SOAP Module in an Endpoint</i></p>
<div class="exampleInner"><pre>
***************
*** 1464,1468 ****
</p><p>If the "required" attribute was not present, or if it was set to "<code>false</code>", then the <code><wsoap:module></code> syntax would indicate optional the availability of the referenced module, rather than a requirement to engage it, as explained in <a href="#adv-optional-versus-required"><b>7.1.1 Optional Versus Required Extensions</b></a>.</p></div><div class="div3">
<h4><a name="adv-FP-abstract-features"></a>7.2.2 Abstract Features</h4><p>Since GreatH began the web service improvements, they have been talking to several travel agents. The possibility of making their simple hotel interface an industry standard amongst a consortium of hotels has come up, and as such they would like to enable specifying the requirement for the "makeReservation" operation to be secure at the interface level – in other words indicating that the operation must be secure, but without specifying exactly how that should concretely be achieved (to enable maximal reuse of the interface). The next example uses the WSDL 2.0 Feature element to indicate this.</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-fp-declaring-abstract-feature"></a><i><span>Example 7-2. </span>Declaring an Abstract Feature Requirement</i></p>
<div class="exampleInner"><pre>
. . .
--- 1480,1484 ----
</p><p>If the "required" attribute was not present, or if it was set to "<code>false</code>", then the <code><wsoap:module></code> syntax would indicate optional the availability of the referenced module, rather than a requirement to engage it, as explained in <a href="#adv-optional-versus-required"><b>7.1.1 Optional Versus Required Extensions</b></a>.</p></div><div class="div3">
<h4><a name="adv-FP-abstract-features"></a>7.2.2 Abstract Features</h4><p>Since GreatH began the web service improvements, they have been talking to several travel agents. The possibility of making their simple hotel interface an industry standard amongst a consortium of hotels has come up, and as such they would like to enable specifying the requirement for the "makeReservation" operation to be secure at the interface level – in other words indicating that the operation must be secure, but without specifying exactly how that should concretely be achieved (to enable maximal reuse of the interface). The next example uses the WSDL 2.0 Feature element to indicate this.</p><div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-fp-declaring-abstract-feature"></a><i><span>Example 7-2. </span>Declaring an Abstract Feature Requirement</i></p>
<div class="exampleInner"><pre>
. . .
***************
*** 1476,1480 ****
. . .</pre></div>
</div><p>This declaration indicates that understanding of, and compliance with, the specified security feature is required for all uses of the "makeReservation" operation. The security feature is <em>abstract</em>, which means that although it defines semantics and a level of detail about its general operation, it expects a concrete component (like a SOAP module or binding) to actually realize the functionality.</p><p>By definition, if you understand a SOAP module, you understand which (if any) abstract features it implements. Therefore, since the security module in this example is defined as an implementation of the abstract security feature, we know that the use of this module satisfies the requirement to implement the feature. Therefore users of the HTTP endpoint shown above (with the required SOAP module) will be able to make use of it. GreatH also defines a new endpoint:</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-fp-soap-over-shttp"></a><i><span>Example 7-3. </span>A SOAP Binding Over a Secure HTTP Protocol</i></p>
<div class="exampleInner"><pre>
. . .
--- 1492,1496 ----
. . .</pre></div>
</div><p>This declaration indicates that understanding of, and compliance with, the specified security feature is required for all uses of the "makeReservation" operation. The security feature is <em>abstract</em>, which means that although it defines semantics and a level of detail about its general operation, it expects a concrete component (like a SOAP module or binding) to actually realize the functionality.</p><p>By definition, if you understand a SOAP module, you understand which (if any) abstract features it implements. Therefore, since the security module in this example is defined as an implementation of the abstract security feature, we know that the use of this module satisfies the requirement to implement the feature. Therefore users of the HTTP endpoint shown above (with the required SOAP module) will be able to make use of it. GreatH also defines a new endpoint:</p><div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-fp-soap-over-shttp"></a><i><span>Example 7-3. </span>A SOAP Binding Over a Secure HTTP Protocol</i></p>
<div class="exampleInner"><pre>
. . .
***************
*** 1495,1499 ****
</div><p>The user will have a choice as to which of the endpoints, and therefore which binding, is to be used, but they both satisfy the abstract feature requirement specified in the interface.</p><p>Note that it is not necessary to declare the abstract feature in order to use/require the SOAP module, or in order to use/require the secure binding. Abstract feature declarations serve purely to indicate requirements which must be fulfilled by more concrete components such as modules or bindings. In other words, the abstract feature declaration allows components such as interfaces to be reused without caring exactly which SOAP modules or bindings satisfy the feature.</p></div><div class="div3">
<h4><a name="adv-fp-properties"></a>7.2.3 Properties</h4><p>So far we've discussed how to indicate the availability or the "requiredness" of features and modules. Often it is not enough to indicate that a particular extension is available/required: you also need some way to control or parameterize aspects of its behavior. This is achieved by the use of WSDL 2.0 <em>properties</em>. Each feature, SOAP module, or SOAP binding may express a variety of <em>properties</em> in its specification. These properties are very much like variables in a programming language. If GreatH would like to indicate that the <code>securityLevel</code> property should be 5 for the "makeReservation" operation, it would look like this:</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-fp-def-prop"></a><i><span>Example 7-4. </span>Defining a Property</i></p>
<div class="exampleInner"><pre>
. . .
--- 1511,1515 ----
</div><p>The user will have a choice as to which of the endpoints, and therefore which binding, is to be used, but they both satisfy the abstract feature requirement specified in the interface.</p><p>Note that it is not necessary to declare the abstract feature in order to use/require the SOAP module, or in order to use/require the secure binding. Abstract feature declarations serve purely to indicate requirements which must be fulfilled by more concrete components such as modules or bindings. In other words, the abstract feature declaration allows components such as interfaces to be reused without caring exactly which SOAP modules or bindings satisfy the feature.</p></div><div class="div3">
<h4><a name="adv-fp-properties"></a>7.2.3 Properties</h4><p>So far we've discussed how to indicate the availability or the "requiredness" of features and modules. Often it is not enough to indicate that a particular extension is available/required: you also need some way to control or parameterize aspects of its behavior. This is achieved by the use of WSDL 2.0 <em>properties</em>. Each feature, SOAP module, or SOAP binding may express a variety of <em>properties</em> in its specification. These properties are very much like variables in a programming language. If GreatH would like to indicate that the <code>securityLevel</code> property should be 5 for the "makeReservation" operation, it would look like this:</p><div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-fp-def-prop"></a><i><span>Example 7-4. </span>Defining a Property</i></p>
<div class="exampleInner"><pre>
. . .
***************
*** 1510,1514 ****
</div><p>The <code>property</code> element specifies which property is to be set. By setting the <code>value</code> element, a toolkit processing this WSDL 2.0 document is informed that the securityLevel property must be set to 5. The particular meanings of any such values are up to the implementations of the modules/bindings that use them. The <code>property</code> element can be placed at many different levels in a WSDL 2.0 document (see "Property Composition Model", section 2.8.1.1 in WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0 Core Language</a></cite>]).
</p><p>It is also possible to provide a <em>constraint</em> on the value space for a given property. This allows the author of the WSDL 2.0 document to indicate that several valid values for the property are possible for a given scope, limiting the value space already described in the specification that defined the property. Let's extend our example to make this clearer.</p><p>The security feature specification defines securityLevel as an integer with values between 1 and 10, each of which indicates, according to the spec, a progressively higher level of security. The GreatH service authors, having read the relevant specifications, have decided that any security level between 3 and 7 will be supported by their infrastructure. Levels less than 3 are deemed unsafe for GreatH's purposes, and levels greater than 7 require too much in the way of resources to make it worthwhile. We can express this in WSDL 2.0 as follows:</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-fp-def-prop-constraints"></a><i><span>Example 7-5. </span>Defining Property Constraints</i></p>
<div class="exampleInner"><pre>
. . .
--- 1526,1530 ----
</div><p>The <code>property</code> element specifies which property is to be set. By setting the <code>value</code> element, a toolkit processing this WSDL 2.0 document is informed that the securityLevel property must be set to 5. The particular meanings of any such values are up to the implementations of the modules/bindings that use them. The <code>property</code> element can be placed at many different levels in a WSDL 2.0 document (see "Property Composition Model", section 2.8.1.1 in WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0 Core Language</a></cite>]).
</p><p>It is also possible to provide a <em>constraint</em> on the value space for a given property. This allows the author of the WSDL 2.0 document to indicate that several valid values for the property are possible for a given scope, limiting the value space already described in the specification that defined the property. Let's extend our example to make this clearer.</p><p>The security feature specification defines securityLevel as an integer with values between 1 and 10, each of which indicates, according to the spec, a progressively higher level of security. The GreatH service authors, having read the relevant specifications, have decided that any security level between 3 and 7 will be supported by their infrastructure. Levels less than 3 are deemed unsafe for GreatH's purposes, and levels greater than 7 require too much in the way of resources to make it worthwhile. We can express this in WSDL 2.0 as follows:</p><div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-fp-def-prop-constraints"></a><i><span>Example 7-5. </span>Defining Property Constraints</i></p>
<div class="exampleInner"><pre>
. . .
***************
*** 1565,1569 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="weather-not-initial"></a><i><span>Example 7-6. </span>Weather Notification Service (Initial)</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
--- 1581,1585 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="weather-not-initial"></a><i><span>Example 7-6. </span>Weather Notification Service (Initial)</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
***************
*** 1674,1678 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="weather-not-final"></a><i><span>Example 7-7. </span>Weather Notification Service (Revised)</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
--- 1690,1694 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="weather-not-final"></a><i><span>Example 7-7. </span>Weather Notification Service (Revised)</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
***************
*** 1749,1753 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="credit-card-faults"></a><i><span>Example 7-8. </span>Standard Credit Card Validation Faults (credit-card-faults.wsdl)</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
--- 1765,1769 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="credit-card-faults"></a><i><span>Example 7-8. </span>Standard Credit Card Validation Faults (credit-card-faults.wsdl)</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
***************
*** 1800,1804 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="use-credit-card-faults"></a><i><span>Example 7-9. </span>Using the Standard Credit Card Validation Faults (use-credit-card-faults.wsdl)</i></p>
<div class="exampleInner"><pre><?xml version="1.0"?>
<description
--- 1816,1820 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="use-credit-card-faults"></a><i><span>Example 7-9. </span>Using the Standard Credit Card Validation Faults (use-credit-card-faults.wsdl)</i></p>
<div class="exampleInner"><pre><?xml version="1.0"?>
<description
***************
*** 1991,1995 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-MTOM-schema"></a><i><span>Example 7-10. </span>XML Schema with Optimizable Elements </i></p>
<div class="exampleInner"><pre>. . .
--- 2007,2011 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-MTOM-schema"></a><i><span>Example 7-10. </span>XML Schema with Optimizable Elements </i></p>
<div class="exampleInner"><pre>. . .
***************
*** 2036,2040 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-MTOM-soap-message"></a><i><span>Example 7-11. </span>Non-optimized SOAP Message with Embedded Binary Data </i></p>
<div class="exampleInner"><pre>
--- 2052,2056 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-MTOM-soap-message"></a><i><span>Example 7-11. </span>Non-optimized SOAP Message with Embedded Binary Data </i></p>
<div class="exampleInner"><pre>
***************
*** 2061,2065 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-MTOM-soap-binding"></a><i><span>Example 7-12. </span>Specifying MTOM in a WSDL 2.0 Binding</i></p>
<div class="exampleInner"><pre>
--- 2077,2081 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="example-MTOM-soap-binding"></a><i><span>Example 7-12. </span>Specifying MTOM in a WSDL 2.0 Binding</i></p>
<div class="exampleInner"><pre>
***************
*** 2115,2119 ****
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 class="exampleHead" style="text-align: left"><a name="example-rpc-style"></a><i><span>Example 7-13. </span>Specifying RPC Style </i></p>
<div class="exampleInner"><pre>. . .
--- 2131,2135 ----
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"></a><i><span>Example 7-13. </span>Specifying RPC Style </i></p>
<div class="exampleInner"><pre>. . .
***************
*** 2174,2178 ****
for mapping simple types to Java types and
designated inout and output parameters by using Holder classes.</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example-rpc-style-java-sig"></a><i><span>Example 7-14. </span>Sample Java(TM) Signature for RPC Style</i></p>
<div class="exampleInner"><pre>public interface reservationInterface extends Remote{
--- 2190,2194 ----
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"></a><i><span>Example 7-14. </span>Sample Java(TM) Signature for RPC Style</i></p>
<div class="exampleInner"><pre>public interface reservationInterface extends Remote{
***************
*** 2248,2252 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="reservationDetails-OMX736.xml"></a><i><span>Example 7-15. </span>Detail for Reservation OMX736</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="UTF-8"?>
<reservationDetails
--- 2264,2268 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="reservationDetails-OMX736.xml"></a><i><span>Example 7-15. </span>Detail for Reservation OMX736</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="UTF-8"?>
<reservationDetails
***************
*** 2277,2281 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="reservationDetails.wsdl"></a><i><span>Example 7-16. </span>The Reservation Details Web Service Description: reservationDetails.wsdl</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
--- 2293,2297 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="reservationDetails.wsdl"></a><i><span>Example 7-16. </span>The Reservation Details Web Service Description: reservationDetails.wsdl</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
***************
*** 2342,2346 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="reservationDetails.xsd"></a><i><span>Example 7-17. </span>
The Reservation Details Web Service XML Schema:
reservationDetails.xsd
--- 2358,2362 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="reservationDetails.xsd"></a><i><span>Example 7-17. </span>
The Reservation Details Web Service XML Schema:
reservationDetails.xsd
***************
*** 2526,2530 ****
</p>
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="reservationList-all.xml"></a><i><span>Example 7-18. </span>
Response from the Reservation List Web
Service</i></p>
--- 2542,2546 ----
</p>
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="reservationList-all.xml"></a><i><span>Example 7-18. </span>
Response from the Reservation List Web
Service</i></p>
***************
*** 2603,2607 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="reservationList.wsdl"></a><i><span>Example 7-19. </span>
The Reservation List Web Service
Description: reservationList.wsdl
--- 2619,2623 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="reservationList.wsdl"></a><i><span>Example 7-19. </span>
The Reservation List Web Service
Description: reservationList.wsdl
***************
*** 2696,2700 ****
<p><a href="#reservationList.xsd">Example 7-20</a> shows the schema for the messages used in the Reservation List Web service.</p>
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="reservationList.xsd"></a><i><span>Example 7-20. </span>The Reservation List Schema: reservationList.xsd</i></p>
<div class="exampleInner"><pre>
<?xml version="1.0" encoding="UTF-8"?>
--- 2712,2716 ----
<p><a href="#reservationList.xsd">Example 7-20</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"></a><i><span>Example 7-20. </span>The Reservation List Schema: reservationList.xsd</i></p>
<div class="exampleInner"><pre>
<?xml version="1.0" encoding="UTF-8"?>
***************
*** 2787,2791 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="reservationServiceReferences-HSG635.xml"></a><i><span>Example 7-21. </span>A Service Reference to the Reservation Details Web Service</i></p>
<div class="exampleInner"><pre>
<?xml version="1.0" encoding="UTF-8"?>
--- 2803,2807 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="reservationServiceReferences-HSG635.xml"></a><i><span>Example 7-21. </span>A Service Reference to the Reservation Details Web Service</i></p>
<div class="exampleInner"><pre>
<?xml version="1.0" encoding="UTF-8"?>
***************
*** 2815,2819 ****
<h4><a name="reservationDetails_HTTP"></a>7.10.3 Reservation Details Web Service Using HTTP Transfer</h4><p>This section presents a variation on the example in <a href="#reservationDetails"><b>7.10.1 The Reservation Details Web Service</b></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 class="exampleHead" style="text-align: left"><a name="reservationDetails_HTTP_example"></a><i><span>Example 7-22. </span>
Reservation Details Web Service Using HTTP Transfer</i></p>
<div class="exampleInner"><pre>
--- 2831,2835 ----
<h4><a name="reservationDetails_HTTP"></a>7.10.3 Reservation Details Web Service Using HTTP Transfer</h4><p>This section presents a variation on the example in <a href="#reservationDetails"><b>7.10.1 The Reservation Details Web Service</b></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"></a><i><span>Example 7-22. </span>
Reservation Details Web Service Using HTTP Transfer</i></p>
<div class="exampleInner"><pre>
***************
*** 2838,2842 ****
operations. These can also be expressed as various parameters in a URI
used by HTTP GET:</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example_reservationList_HTTP_GET"></a><i><span>Example 7-23. </span>
Reservation List Web Service Using HTTP GET</i></p>
<div class="exampleInner"><pre>
--- 2854,2858 ----
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"></a><i><span>Example 7-23. </span>
Reservation List Web Service Using HTTP GET</i></p>
<div class="exampleInner"><pre>
***************
*** 2874,2878 ****
into the URI query string. A query sequence for any of
ConfirmationNumber, checkInDate, checkOutDate would look like this:</p><div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="example_reservationList_HTTP_GET_single"></a><i><span>Example 7-24. </span>Query Sequence Using a Single Query Type</i></p>
<div class="exampleInner"><pre>
<element name="reservationQuery">
--- 2890,2894 ----
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"></a><i><span>Example 7-24. </span>Query Sequence Using a Single Query Type</i></p>
<div class="exampleInner"><pre>
<element name="reservationQuery">
***************
*** 2895,2899 ****
</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 class="exampleHead" style="text-align: left"><a name="example_reservationList_HTTP_GET_single_wsdl"></a><i><span>Example 7-25. </span>WSDL 2.0 for Using a Single Query Type</i></p>
<div class="exampleInner"><pre>
. . .
--- 2911,2915 ----
</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"></a><i><span>Example 7-25. </span>WSDL 2.0 for Using a Single Query Type</i></p>
<div class="exampleInner"><pre>
. . .
***************
*** 2954,2958 ****
<div class="div3">
! <h4><a name="N1118B"></a>7.11.1 Schemas in Imported Documents</h4>
<p>
In this example, we consider some GreatH Hotel
--- 2970,2974 ----
<div class="div3">
! <h4><a name="N70058"></a>7.11.1 Schemas in Imported Documents</h4>
<p>
In this example, we consider some GreatH Hotel
***************
*** 2991,2995 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="retrieveDetails.wsdl"></a><i><span>Example 7-26. </span>
The Retrieve Reservation Details Web
Service: retrieveDetails.wsdl
--- 3007,3011 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="retrieveDetails.wsdl"></a><i><span>Example 7-26. </span>
The Retrieve Reservation Details Web
Service: retrieveDetails.wsdl
***************
*** 3118,3122 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="updateDetails.wsdl"></a><i><span>Example 7-27. </span>The Update Reservation Details Web Service: updateDetails.wsdl</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
--- 3134,3138 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="updateDetails.wsdl"></a><i><span>Example 7-27. </span>The Update Reservation Details Web Service: updateDetails.wsdl</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
***************
*** 3161,3165 ****
<div class="div3">
! <h4><a name="N11216"></a>7.11.2 Multiple Inline Schemas in One Document</h4>
<p>
A WSDL 2.0 document may define multiple inline
--- 3177,3181 ----
<div class="div3">
! <h4><a name="N70197"></a>7.11.2 Multiple Inline Schemas in One Document</h4>
<p>
A WSDL 2.0 document may define multiple inline
***************
*** 3217,3221 ****
<div class="exampleOuter">
! <p class="exampleHead" style="text-align: left"><a name="retrieveItems.wsdl"></a><i><span>Example 7-28. </span>
Multiple Inline Schemas: retrieveItems.wsdl
</i></p>
--- 3233,3237 ----
<div class="exampleOuter">
! <p style="text-align: left" class="exampleHead"><a name="retrieveItems.wsdl"></a><i><span>Example 7-28. </span>
Multiple Inline Schemas: retrieveItems.wsdl
</i></p>
***************
*** 3295,3299 ****
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="N11276"></a>7.11.3.1 Using the id Attribute to Identify Inline
Schemas</h5><p>
<a href="#schemaIds.wsdl">Example 7-29</a>
--- 3311,3315 ----
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="N70293"></a>7.11.3.1 Using the id Attribute to Identify Inline
Schemas</h5><p>
<a href="#schemaIds.wsdl">Example 7-29</a>
***************
*** 3312,3316 ****
attribute, i.e. <code>#items</code>.
</p>
! <div class="exampleOuter"><p class="exampleHead" style="text-align: left"><a name="schemaIds.wsdl"></a><i><span>Example 7-29. </span>Using Ids in Inline Schemas: schemaIds.wsdl</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
--- 3328,3332 ----
attribute, i.e. <code>#items</code>.
</p>
! <div class="exampleOuter"><p style="text-align: left" class="exampleHead"><a name="schemaIds.wsdl"></a><i><span>Example 7-29. </span>Using Ids in Inline Schemas: schemaIds.wsdl</i></p>
<div class="exampleInner"><pre><?xml version="1.0" encoding="utf-8" ?>
<description xmlns="http://www.w3.org/2005/05/wsdl"
***************
*** 3379,3383 ****
<h3><a name="adv-rdf-mapping"></a>7.12 Mapping to RDF and Semantic Web</h3>
! <table border="1" summary="Editorial note: KevinL"><tr><td width="50%" valign="top" align="left"><b>Editorial note: KevinL</b></td><td width="50%" valign="top" align="right">20050429</td></tr><tr><td valign="top" align="left" colspan="2">
This section might be removed - pending on the availability of the RDF mapping note. </td></tr></table>
--- 3395,3399 ----
<h3><a name="adv-rdf-mapping"></a>7.12 Mapping to RDF and Semantic Web</h3>
! <table border="1" summary="Editorial note: KevinL"><tr><td align="left" valign="top" width="50%"><b>Editorial note: KevinL</b></td><td align="right" valign="top" width="50%">20050429</td></tr><tr><td colspan="2" align="left" valign="top">
This section might be removed - pending on the availability of the RDF mapping note. </td></tr></table>
Received on Thursday, 16 June 2005 22:48:07 UTC