- From: David Booth via cvs-syncmail <cvsmail@w3.org>
- Date: Sat, 16 Apr 2005 17:23:45 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv2994
Modified Files:
wsdl20-primer.xml wsdl20-primer.html
Log Message:
Finished editing/updating through section 6.5.
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.48
retrieving revision 1.49
diff -C2 -d -r1.48 -r1.49
*** wsdl20-primer.xml 14 Apr 2005 21:40:45 -0000 1.48
--- wsdl20-primer.xml 16 Apr 2005 17:23:43 -0000 1.49
***************
*** 325,329 ****
element, as shown in the example below. However, in some
cases it is possible to use defaulting rules to supply
! the information. The WSDL 2.0 SOAP binding, for example,
defines some defaulting rules for operations. (See
<emph>
--- 325,329 ----
element, as shown in the example below. However, in some
cases it is possible to use defaulting rules to supply
! the information. The WSDL 2.0 SOAP binding extension, for example,
defines some defaulting rules for operations. (See
<emph>
***************
*** 338,352 ****
extensions to the WSDL 2.0 language, via WSDL 2.0's open
content model. (See
! <specref ref="adv-extensibility" />
for more on extensibility.) WSDL 2.0 Part 2
! <bibref ref="WSDL-PART2" />
! defines binding constructs for SOAP 1.2
! <bibref ref="SOAP12-PART1" />
and HTTP 1.1
! <bibref ref="RFC2616" />
as predefined extensions, so that SOAP 1.2 or HTTP 1.1
bindings can be easily defined in WSDL documents.
However, other specifications could define new binding
! constructs that could also be used to define bindings.
(As with any extension, other WSDL processors would have
to know about the new constructs in order to make use of
--- 338,352 ----
extensions to the WSDL 2.0 language, via WSDL 2.0's open
content model. (See
! <specref ref="adv-extensibility"/>
for more on extensibility.) WSDL 2.0 Part 2
! <bibref ref="WSDL-PART2"/>
! defines binding extensions for SOAP 1.2
! <bibref ref="SOAP12-PART1"/>
and HTTP 1.1
! <bibref ref="RFC2616"/>
as predefined extensions, so that SOAP 1.2 or HTTP 1.1
bindings can be easily defined in WSDL documents.
However, other specifications could define new binding
! extensions that could also be used to define bindings.
(As with any extension, other WSDL processors would have
to know about the new constructs in order to make use of
***************
*** 396,400 ****
. . .
</description>]]></eg>
! </example><div3 id="example-initial-binding-explanation"><head>Explanation of Example</head><glist><gitem><label><code>xmlns:wsoap= "http://www.w3.org/2004/08/wsdl/soap12"</code></label><def><p>We've added two more namespace declarations. This one is the namespace for the SOAP 1.2 binding construct that is defined in WSDL 2.0 Part 3 <bibref ref="SOAP12-PART1"/>. Elements and attributes prefixed with <code>wsoap:</code> are constructs defined there. </p></def></gitem><gitem><label><code>xmlns:soap="http://www.w3.org/2003/05/soap-envelope"</code></label><def><p>This namespace is defined by the SOAP 1.2 specification itself. The SOAP 1.2 specification defines certain terms within this namespace to unambiguously identify particular concepts. Thus, we will use the <code>soap:</code> prefix when we need to refer to one of those terms.</p></def></gitem><gitem><label><code><binding name="reservationSOAPBinding"</code></label><def><p>Bindings are declared directly inside the <code>description</code>element. The <att>name</att> attribute defines a name for this binding. Each name must be unique among all bindings in this WSDL target namespace, and will be used later when we define a service endpoint that references this binding. WSDL 2.0 uses separate symbol spaces for interfaces, bindings and services, so interface "foo", binding "foo" and service "foo" are all distinct. </p></def></gitem><gitem><label><code>interface="tns:reservationInterface"</code></label><def><p>This is the name of the interface whose message format and transmission protocols we are specifying. As discussed in <specref ref="more-bindings"/>, a reusable binding can be defined by omitting the <att>interface</att> attribute. Note also the use of the <code>tns:</code> prefix, which refers to the previously defined WSDL target namespace for this WSDL document. In this case it may seem silly to have to specify the <code>tns:</code> prefix, but in <specref ref="adv-import-and-authoring"/> we will see how WSDL 2.0's import mechanim can be used to combine components that are defined in different WSDL target namespaces.</p></def></gitem><gitem><label><code>type="http://www.w3.org/2004/08/wsdl/soap12"</code></label><def><p>This specifies what kind of concrete message format to use, in this case SOAP 1.2.</p></def></gitem><gitem><label><code>wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"</code></label><def><p>This attribute is specific to WSDL 2.0's SOAP binding (thus it uses the <code>wsoap:</code> prefix). It specifies the underlying transmission protocol that should be used, in this case HTTP. </p></def></gitem><gitem><label><code><operation ref="tns:opCheckAvailability"</code></label><def>
<p>
This not defining a new operation; rather, it is referencing the
--- 396,400 ----
. . .
</description>]]></eg>
! </example><div3 id="example-initial-binding-explanation"><head>Explanation of Example</head><glist><gitem><label><code>xmlns:wsoap= "http://www.w3.org/2004/08/wsdl/soap12"</code></label><def><p>We've added two more namespace declarations. This one is the namespace for the SOAP 1.2 binding extension that is defined in WSDL 2.0 Part 3 <bibref ref="SOAP12-PART1"/>. Elements and attributes prefixed with <code>wsoap:</code> are constructs defined there. </p></def></gitem><gitem><label><code>xmlns:soap="http://www.w3.org/2003/05/soap-envelope"</code></label><def><p>This namespace is defined by the SOAP 1.2 specification itself. The SOAP 1.2 specification defines certain terms within this namespace to unambiguously identify particular concepts. Thus, we will use the <code>soap:</code> prefix when we need to refer to one of those terms.</p></def></gitem><gitem><label><code><binding name="reservationSOAPBinding"</code></label><def><p>Bindings are declared directly inside the <code>description</code>element. The <att>name</att> attribute defines a name for this binding. Each name must be unique among all bindings in this WSDL target namespace, and will be used later when we define a service endpoint that references this binding. WSDL 2.0 uses separate symbol spaces for interfaces, bindings and services, so interface "foo", binding "foo" and service "foo" are all distinct. </p></def></gitem><gitem><label><code>interface="tns:reservationInterface"</code></label><def><p>This is the name of the interface whose message format and transmission protocols we are specifying. As discussed in <specref ref="more-bindings"/>, a reusable binding can be defined by omitting the <att>interface</att> attribute. Note also the use of the <code>tns:</code> prefix, which refers to the previously defined WSDL target namespace for this WSDL document. In this case it may seem silly to have to specify the <code>tns:</code> prefix, but in <specref ref="adv-import-and-authoring"/> we will see how WSDL 2.0's import mechanim can be used to combine components that are defined in different WSDL target namespaces.</p></def></gitem><gitem><label><code>type="http://www.w3.org/2004/08/wsdl/soap12"</code></label><def><p>This specifies what kind of concrete message format to use, in this case SOAP 1.2.</p></def></gitem><gitem><label><code>wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"</code></label><def><p>This attribute is specific to WSDL 2.0's SOAP binding extension (thus it uses the <code>wsoap:</code> prefix). It specifies the underlying transmission protocol that should be used, in this case HTTP. </p></def></gitem><gitem><label><code><operation ref="tns:opCheckAvailability"</code></label><def>
<p>
This not defining a new operation; rather, it is referencing the
***************
*** 403,408 ****
operation in order to specify binding details for it. This
element can be omitted if defaulting rules are instead used to
! supply the necessary information. (See the SOAP binding in
! <emph>WSDL 2.0 Bindings</emph>
<bibref ref="WSDL-PART2"/>
section 4.3
--- 403,408 ----
operation in order to specify binding details for it. This
element can be omitted if defaulting rules are instead used to
! supply the necessary information. (See the SOAP binding extension in
! WSDL 2.0 Part 2
<bibref ref="WSDL-PART2"/>
section 4.3
***************
*** 411,415 ****
</xspecref>.)
</p>
! </def></gitem><gitem><label><code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"></code></label><def><p>This attribute is also specific to WSDL 2.0's SOAP binding. It specifies the SOAP message exchange pattern that will be used to implement the abstract WSDL 2.0 message exchange pattern (<xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</xspecref>) that was specified when the <code>opCheckAvailability</code> operation was defined. </p></def></gitem><gitem><label><code><fault ref="tns:invalidDataFault"</code></label><def><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></def></gitem><gitem><label><code>wsoap:code="soap:Sender"/></code></label><def><p>This attribute is also specific to WSDL 2.0's SOAP binding. This specifies th SOAP 1.2 fault code that will cause this fault message to be sent. If desired, a list of subcodes can also be specified using the optional <att>wsoap:subcodes</att> attribute.</p></def></gitem></glist></div3></div2><div2 id="basics-service"><head>Defining a Service</head><p>Now that our binding has specified <emph>how</emph> messages will be transmitted, we are ready to specify <emph>where</emph> the service can be accessed, by use of the <code>service</code> element. </p><p>A WSDL 2.0 <emph>service</emph> specifies a single interface that the service will support, and a list of <emph>endpoint</emph> 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 <specref ref="adv-multiple-docs-describing-same-service"/> for further discussion of this limitation.) </p><p>Here is a definition for our GreatH service</p><example id="example-initial-service">
<head>GreatH Service Definition</head>
<eg><![CDATA[<?xml version="1.0" encoding="utf-8" ?>
--- 411,415 ----
</xspecref>.)
</p>
! </def></gitem><gitem><label><code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"></code></label><def><p>This attribute is also specific to WSDL 2.0's SOAP binding extension. It specifies the SOAP message exchange pattern that will be used to implement the abstract WSDL 2.0 message exchange pattern (<xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">in-out</xspecref>) that was specified when the <code>opCheckAvailability</code> operation was defined. </p></def></gitem><gitem><label><code><fault ref="tns:invalidDataFault"</code></label><def><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></def></gitem><gitem><label><code>wsoap:code="soap:Sender"/></code></label><def><p>This attribute is also specific to WSDL 2.0's SOAP binding extension. This specifies the SOAP 1.2 fault code that will cause this fault message to be sent. If desired, a list of subcodes can also be specified using the optional <att>wsoap:subcodes</att> attribute.</p></def></gitem></glist></div3></div2><div2 id="basics-service"><head>Defining a Service</head><p>Now that our binding has specified <emph>how</emph> messages will be transmitted, we are ready to specify <emph>where</emph> the service can be accessed, by use of the <code>service</code> element. </p><p>A WSDL 2.0 <emph>service</emph> specifies a single interface that the service will support, and a list of <emph>endpoint</emph> 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 <specref ref="adv-multiple-docs-describing-same-service"/> for further discussion of this limitation.) </p><p>Here is a definition fo our GreatH service.</p><example id="example-initial-service">
<head>GreatH Service Definition</head>
<eg><![CDATA[<?xml version="1.0" encoding="utf-8" ?>
***************
*** 471,475 ****
<div1 id="wsdl-xml-representation"><head>WSDL 2.0 Infoset, Schema and Component Model</head>
! <p>In conventional computer science theory, a language consists of a (possibly infinite) set of sentences, and each sentence is a string of literal symbols or characters. The language specification must therefore define two things: the set of permissible sentences, and the meaning of each sentence. Indeed, this is the purpose of the WSDL 2.0 specification.</p><p>However, instead of defining WSDL 2.0 in terms of literal symbols or characters, to avoid dependency on any particular character encoding, WSDL 2.0 is defined in terms of the <emph>XML Infoset</emph> <bibref ref="XMLInfoSet"/>. Specifically, a <emph>WSDL 2.0 document</emph> consists of a <code>description</code> element information item (in the XML Infoset) that conforms to the WSDL 2.0 specification. In other words, a sentence in the WSDL 2.0 language is a <code>description</code> element information item that obeys the additional constraints spelled out in the WSDL 2.0 specification.</p><p>Since an XML Infoset can be created from morethan one physical document, a WSDL 2.0 document does not necessarily correspond to a single physical document: the word "document" is used figuratively, for convenience. Furthermore, since WSDL 2.0 provides <code>import</code> and <code>include</code> mechanisms, a WSDL 2.0 document may reference other WSDL 2.0 documents to facilitate convenient organization or reuse. </p><p>Unfortunately, the terms "element information item" and "attribute information item" are rather lengthy. Thus, for convenience, this primer often uses the terms "element" and "attribute" instead, as a shorthand. It should be understood, however, that since WSDL 2.0 is based on the XML Infoset, we really mean "element information item" and "attribute information item", respectively.</p>
<div2 id="wsdl-infoset-diagram"><head>WSDL 2.0 Infoset</head>
--- 471,475 ----
<div1 id="wsdl-xml-representation"><head>WSDL 2.0 Infoset, Schema and Component Model</head>
! <p>In computer science theory, a language consists of a (possibly infinite) set of sentences, and each sentence is a finite string of literal symbols or characters. A language specification must therefore define the set sentences in that language, and, to be useful, it should also indicate the meaning of each sentence. Indeed, this is the purpose of the WSDL 2.0 specification.</p><p>However, instead of defining WSDL 2.0 in terms of literal symbols or characters, to avoid dependency on any particular character encoding, WSDL 2.0 is defined in terms of the <emph>XML Infoset</emph> <bibref ref="XMLInfoSet"/>. Specifically, a <emph>WSDL 2.0 document</emph> consists of a <code>description</code> element information item (in the XML Infoset) that conforms to the WSDL 2.0 specification. In other words, a sentence in the WSDL 2.0 language is a <code>description</code> element information item that obeys the additional constraints spelled out in the WSDL 2.0 specification.</p><p>Since an XML Infoset cn be created from more than one physical document, a WSDL 2.0 document does not necessarily correspond to a single <emph>physical</emph> document: the word "document" is used figuratively, for convenience. Furthermore, since WSDL 2.0 provides <code>import</code> and <code>include</code> mechanisms, a WSDL 2.0 document may reference other WSDL 2.0 documents to facilitate convenient organization or reuse. In such cases, the meaning of the including or importing document as a whole will depend (in part) on the meaning of the included or imported document.</p><p>The XML Infoset uses terms like "element information item" and "attribute information item". Unfortunately, those terms are rather lengthy to repeat often. Thus, for convenience, this primer often uses the terms "element" and "attribute" instead, as a shorthand. It should be understood, however, that since WSDL 2.0 is based on the XML Infoset, we really mean "element information item" and "attribute information item", respectively.</p>
<div2 id="wsdl-infoset-diagram"><head>WSDL 2.0 Infoset</head>
***************
*** 575,579 ****
</div2>
! <div2 id="component-model"><head>WSDL 2.0 Component Model</head><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 <emph>component model</emph> 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. </p><p>In general, the WSDL 2.0 component model parallels the structure of the required XML Infoset illustrated above. For example, the <emph>Description</emph>, <emph>Interface</emph>, <emph>Binding</emph>, <emph>Servce</emph> and <emph>Endpoint</emph> <emph>components</emph> correspond to the <code>description</code>, <code>interface</code>, <code>binding</code>, <code>service</code>, and <code>endpoint</code> element information items, respectively. The Description component represents the meaning of the <code>description</code> element information item, and hence, it represents the meaning of the WSDL 2.0 document as a whole. </p><p>Furthermore, each of these components has <emph>properties</emph> whose values are (usually) derived from the element and attribute information item children of those element information items. For example, the Service component corresponds to the <code>service</code> element information item, so the Service component has an {endpoints} property whose value is a set of Endpoint components corresponding to the <code>endpoint</code> element information item children of that <code>service</code> element information item. (Whew!)<ednote><name>dbooth</name><date>2005-04-12</date><edtex>ToDo: Should we add a graphic illustrating the parallel structure of the component model and the XML Infoset? I think it would be helpful.</edtext></ednote></p><p>The WSDL 2.0 component model is particularly helpful in defining the meaning of <code>import</code> and <code>include</code>. WSDL 2.0 <code>include</code> allows components from another WSDL 2.0 document having the same targetNamespace to be merged in with the components of the current WSDL 2.0 document, and is transitive (i.e., if the included document also includes a WSDL 2.0 document, then those components will also be merged, and so on). WSDL 2.0 <code>import</code> allows components from another WSDL 2.0 document having a different targetNamespace to be merged in with comonents of the current WSDL 2.0 document, and is not transitive.</p></div2></div1>
--- 575,579 ----
</div2>
! <div2 id="component-model"><head>WSDL 2.0 Component Model</head><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 <emph>component model</emph> 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. </p><p>In general, the WSDL 2.0 component model parallels the structure of the required XML Infoset illustrated above. For example, the <emph>Description</emph>, <emph>Interface</emph>, <emph>Binding</emph>, <emph>Servce</emph> and <emph>Endpoint</emph> <emph>components</emph> correspond to the <code>description</code>, <code>interface</code>, <code>binding</code>, <code>service</code>, and <code>endpoint</code> element information items, respectively. Since WSDL 2.0 relies heavily on the component model to convey the meaning of the constructs in the WSDL 2.0 language, you can think of the Description component as representing the meaning of the <code>description</code> element information item, and hence, it represents the meaning of the WSDL 2.0 document as a whole. </p><p>Furthermore, each of these components has <emph>properties</emph> whose values are (usually) derived from the element and attribute information item children of those element information items. For example, the Service component corresponds to the <code>service</code> element information item, so the Service component has an {endpoints} property whose value is a set of Endpoint components corresponding to the <code>endpoint</code> element infomation item children of that <code>service</code> element information item. (Whew!)<ednote><name>dbooth</name><date>2005-04-12</date><edtext>ToDo: Should we add a graphic illustrating the parallel structure of the component model and the XML Infoset? I think it would be helpful.</edtext></ednote></p><p>The WSDL 2.0 component model is particularly helpful in defining the meaning of <code>import</code> and <code>include</code>. WSDL 2.0 <code>include</code> allows components from another WSDL 2.0 document having the same targetNamespace to be merged in with the components of the current WSDL 2.0 document, and is transitive (i.e., if the included document also includes a WSDL 2.0 document, then those components will also be merged, and so on). WSDL 2.0 <code>import</code> allows components from another WSDL 2.0 document having a different targetNamespace to be merged in with comonents of the current WSDL 2.0 document, and is not transitive.</p></div2></div1>
***************
*** 718,724 ****
</div2>
<div2 id="more-interfaces-faults">
! <head>Reusable Faults</head>
<p>The <code>fault</code> element is used to declare faults that may occur during execution of operations of an interface. They are declared directly under <code>interface</code>, and referenced from operations where they apply, in order to permit reuse across multiple operations. </p>
! <p>The <code>fault</code> element has a required <att>name</att> attribute that must be unique within the WSDL document's target namespace, and permits it to be referenced from operation declarations. The optional <att>element</att> attribute can be used to indicate a schema for the content or payload of the fault message. Its value should be the QName of a global element defined in the <code>types</code> section. Please note when other type systems are used to define the schema for a fault message, additional attributes may need to be defined via WSDL's attribute extension mechanism to allow the schema to be associated with the fault.</p>
<p>Here is an example of reusing faults.</p>
<ednote><name>dbooth</name><date>2005-04-14</date><edtext>To do: Update and simplify the fault example below. It should be a slight modification of the initial example, but illustrate: (a) fault reuse; and (b) two alternative faults for an operation.</edtext></ednote><example id="example-faults">
--- 718,737 ----
</div2>
<div2 id="more-interfaces-faults">
! <head>Interface Faults</head>
<p>The <code>fault</code> element is used to declare faults that may occur during execution of operations of an interface. They are declared directly under <code>interface</code>, and referenced from operations where they apply, in order to permit reuse across multiple operations. </p>
! <p>Faults are very similar to messages and can be viewed as a special kind of
! message. Both faults and messages may carry a payload that is normally described
! by an element declaration. However, WSDL treats faults and messages slighly
! differently. The messages of an operation directly refer to their element
! declaration, however the faults of an operation indirectly refer to their
! element declaration via a fault element that is defined on the interface. </p>
!
! <p>The reason for defining faults at
! the interface level is to allow their reuse across multiple operations. This
! design is especially beneficial when bindings are defined, since in binding extensions like
! SOAP there is additional information that is associated with faults. In the case
! of SOAP, faults have codes and subcodes in addition to a payload. By defining
! faults at the interface level, common codes and subcodes can be associated with
! them, thereby ensuring consistency across all operations that use the faults </p><p>The <code>fault</code> element has a required <att>name</att> attribute that must be unique within the WSDL document's target namespace, and permits it to be referenced from operation declarations. The optional <att>element</att> attribute can be used to indicate a schema for the content or payload of the fault message. Its value should be the QName of a global element defined in the <code>types</code> section. Please note when other type systems are used to define the schema for a fault message, additional attributes may need to be defined via WSDL's attribute extension mechanism to allow the schema to be associated with the fault.</p>
<p>Here is an example of reusing faults.</p>
<ednote><name>dbooth</name><date>2005-04-14</date><edtext>To do: Update and simplify the fault example below. It should be a slight modification of the initial example, but illustrate: (a) fault reuse; and (b) two alternative faults for an operation.</edtext></ednote><example id="example-faults">
***************
*** 802,806 ****
<!-- ************************MEPs*************************** -->
<div3 id="more-interfaces-meps">
! <head>Understanding Message Exchange Patterns</head>
<p>WSDL 2.0 message exchange patterns (MEPs) are used to define the sequence and cardinality of the abstract messages in an operation. By design, WSDL 2.0 MEPs are abstract. First of all, they abstract out specific message types. MEPs identify placeholders for messages, and placeholders are associated with specific message types when an operation is defined, which includes specifying which MEP to use for that operation. Secondly, unless explicitly stated otherwise, MEPs also abstract out binding-specific information like timing between messages, whether the pattern is synchronous or asynchronous, and whether the messages are sent over a single or multiple channels.</p>
<p>It's worth pointing out that like interfaces and operations, WSDL MEPs do not exhaustively describe the set of messages that may be exchanged between a service and other
--- 815,819 ----
<!-- ************************MEPs*************************** -->
<div3 id="more-interfaces-meps">
! <head>Understanding Message Exchange Patterns (MEPs)</head>
<p>WSDL 2.0 message exchange patterns (MEPs) are used to define the sequence and cardinality of the abstract messages in an operation. By design, WSDL 2.0 MEPs are abstract. First of all, they abstract out specific message types. MEPs identify placeholders for messages, and placeholders are associated with specific message types when an operation is defined, which includes specifying which MEP to use for that operation. Secondly, unless explicitly stated otherwise, MEPs also abstract out binding-specific information like timing between messages, whether the pattern is synchronous or asynchronous, and whether the messages are sent over a single or multiple channels.</p>
<p>It's worth pointing out that like interfaces and operations, WSDL MEPs do not exhaustively describe the set of messages that may be exchanged between a service and other
***************
*** 891,950 ****
<head>More on Bindings</head>
! <p>A <code>binding</code> can be defined for different levels of reusability. It can be used to describe binding information in a re-usable manner for any
! interface or specifically for a given interface. Furthermore,
! binding information MAY be specified on a per-operation basis if needed.
! If a <code>binding</code> specifies any operation-specific
! binding details or any fault binding details, then it MUST specify an interface the binding information applies to, so as to indicate which interface the operations come from. </p><p>To define a reusable binding, a <code>binding</code> should omit any
! operation-specific binding details and any fault binding details
! MAY omit specifying an interface. <code>bindings</code> that do not
! specify an interface MAY be used to specify
! operation-independent binding details for Service components
! with different interfaces. That is, such <code>bindings</code> are
! reusable across one or more interfaces.</p>
! <p>A <code>binding</code> tied to a particular interface
! MUST define bindings for all the operations of that
! interface. The bindings may occur via defaulting rules
! which allow one to specify default bindings for all operations
! (for example, see the SOAP binding in <emph>WSDL 2.0 Bindings</emph>
<bibref ref="WSDL-PART2"/>
section 4.3
! <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-adjuncts/#soap-defaults">Default Binding Rules</xspecref>) or by directly
! listing each operation of the interface and
! defining bindings for them. Thus, it is an error for a binding to not define bindings for all the operations of the corresponding interface.</p>
! <p>The binding constructs can be grouped into two categories: those in the WSDL namespace of "http://www.w3.org/2004/08/wsdl" and those not in WSDL namespace. WSDL 2.0 Part 1 <bibref ref="WSDL-PART1"/>defines a set of binding constructs within the WSDL namespace that can be used to host binding detail definitions. Constructs for defining binding details are defined within their own namespaces which must be different from the WSDL namespace. ll these binding detail constructs are defined outside WSDL namespace, and are typically used as extensions of the hosting WSDL binding constructs. In the following sections, we will introduce the hosting WSDL binding constructs first, and then move on the the binding extensions.
! </p><div2 id="more-bindings-wsdl">
! <head>Binding Constructs in WSDL Namespace</head>
! <p>Let's have a look at the constructs defined within the WSDL namespace first. The XML syntax of these constructs is summarized below:</p>
<eg xml:space="preserve">
<description targetNamespace="<emph>xs:anyURI</emph>" >
!
<<b>binding</b> name="<emph>xs:NCName</emph>" interface="<emph>xs:QName</emph>"? >
- <documentation />?
! <fault ref="<emph>xs:QName</emph>" >
! <documentation />?
! </fault>*
<operation ref="<emph>xs:QName</emph>" >
! <documentation />?
!
! <input messageLabel="<emph>xs:NCName</emph>"? >
! <documentation />?
! </input>*
!
! <output messageLabel="<emph>xs:NCName</emph>"? >
! <documentation />?
! </output>*
!
! <feature ... />*
!
! <property ... />*
</operation>*
- <feature ... />*
-
- <property ... />*
</<b>binding</b>>*
!
</description>
</eg>
--- 904,929 ----
<head>More on Bindings</head>
! <p>Bindings are used to supply protocol and encoding details that specify <emph>how</emph> messages are to be sent or received. Each <code>binding</code> element uses a particular <emph>binding extension</emph> to specify such information. WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/> defines several binding extensions that are typically used. However, binding extensions that are not defined in WSDL 2.0 Part 2 can also be used, provided that client and service toolkits support them.</p><p>Binding information must be supplied for every operation in an interface that is used in an endpoint. However, if the desired binding extension provides suitable defaulting rules, then the information will only need to be explicitly supplied at the interface level, and the defaulting rules will implicitly propagate the information to the operations of the interface. For example, see the SOAP binding extension in WSDL 2.0 Part 2
<bibref ref="WSDL-PART2"/>
section 4.3
! <xspecref href="http://www.w3.org/TR/2004/WD-wsdl20-adjuncts/#soap-defaults">Default Binding Rules</xspecref>.</p>
!
! <div2 id="more-bindings-wsdl">
! <head>Syntax Summary for Bindings</head>
! <p>Since bindings are specified using extensions to the WSDL 2.0 language (i.e., binding extensions are not in the WSDL 2.0 namespace), the XML for expressing a binding will consist of a mixture of elements and attributes from WSDL 2.0 namespace and from the binding extension's namespace, using WSDL 2.0's open content model. </p><p>Here is a syntax summary for <code>binding</code>, simplified by omitting optional <code>documentation</code>, <code>feature</code> and <code>property</code> elements. Bear in mind that this syntax summary only shows the elements and attributes defined within the WSDL 2.0 namespace. When an actual binding is defined, elements and attributes from the namespace of the desired binding extension will also be intermingled as required by that particular binding extension.</p>
<eg xml:space="preserve">
<description targetNamespace="<emph>xs:anyURI</emph>" >
! . . .
<<b>binding</b> name="<emph>xs:NCName</emph>" interface="<emph>xs:QName</emph>"? >
! <fault ref="<emph>xs:QName</emph>" > </fault>*
<operation ref="<emph>xs:QName</emph>" >
! <input messageLabel="<emph>xs:NCName</emph>"? > </input>*
! <output messageLabel="<emph>xs:NCName</emph>"? > </output>*
</operation>*
</<b>binding</b>>*
! . . .
</description>
</eg>
***************
*** 956,1019 ****
</edtext>
</ednote>
! <ednote><name>dbooth</name><edtext>Trim some of this? Redundant?</edtext></ednote><p>One WSDL <code>description</code> element may contain zero or more <code>binding</code> elements as its direct children.</p>
! <p>The <code>binding</code> element has a required <att>name</att> attribute. Within the same WSDL target namespace , each binding must have a unique name. The optional <att>interface</att> attribute refers, by QName, to an <code>interface</code>. See the previous section for how the <att>interface</att>attribute can be used to achieve different levels of reusability of the <code>binding</code>. </p>
! <p>Careful readers may have already noticed that the <code>binding</code> syntax is to some extent symmetric with the syntax of <code>interface</code>, in other words, each interface construct has a binding counterpart. Simliar to <code>interface</code>,a <code>binding</code> element can contain zero or more <code>fault</code>, zero or more <code>operation</code>, zero or more <code>feature</code>, and zero or more <code>property</code>. Be aware that despite of the syntax similarity, they are indeed different constructs since they are in different symbol spaces and are designed for different purpose. The <code>feature</code> and <code>property</code> element will be examined in section @@@@. We will explain the binding <code>fault</code> and <code>operation</code> constructs in the following sections. </p>
! <div3 id="more-bindings-faults">
! <head>Binding Faults</head>
- <ednote>
- <name>KevinL</name>
- <date>20050310</date>
- <edtext>Incoporated contribution from Arthur. Need to check back this section for integration with rest of document.
- </edtext>
- </ednote>
-
- <p>Faults are very similar to messages and can be viewed as a special kind of
- message. Both faults and messages may carry a payload that is normally described
- by an element declaration. However, WSDL treats faults and messages slighly
- differently. The messages of an operation directly refer to their element
- declaration, however the faults of an operation indirectly refer to their
- element declaration via a fault element that is defined on the interface. </p>
- <p>The reason for defining faults at
- the interface level is to allow their reuse accross multiple operations. This
- design is especially beneficial when bindings are defined since in bindings like
- SOAP there is additional information that is associated with faults. In the case
- of SOAP, faults have codes and subcodes in addition to a payload. By defining
- faults at the interface level, common codes and subcodes can be associated with
- them, thereby ensuring consistency accross all operations that use the faults </p>
! <p>A binding <code>fault</code> describes a concrete binding of an abstract fault
! within an interface to a particular concrete message format. More precisely, it describes how faults that occur within a message exchange of an operation will be formatted since the fault does not occur by itself - it occurs as part of a message
! exchange as defined by an interface <code>operation</code> and its binding
! counterpart the binding <code>operation</code>. </p>
! <p>A binding <code>fault</code> has one required <att>ref</att> attribute which is a reference, by QName, to an <code>interface</code>
! <att>fault</att>. It identifies the abstract interface <code>fault</code> for which binding information is being specified. Be aware that the value of <att>ref</att> attribute of all the <code>faults</code> under a <code>binding</code>
MUST be unique. That is, one cannot define multiple bindings for the same interface fault within a given <code>binding</code>.</p>
! </div3>
! <div3 id="bindingOperations">
! <head id="more-bindings-operations">Binding Operations</head>
! <p>A binding <code>operation</code> describes a concrete binding of a particular
! operation of an interface to a particular concrete message format.A particular
operation of an interface is uniquely identified by the WSDL target namespace of the
! interface and the name of the operation within that interface, via the required <att>ref</att> attribute of binding <code>operation</code>. For each <code>operation</code> within a <code>binding</code>, the value of <att>ref</att> attribute MUST be unique. That is,
! one cannot define multiple bindings for the same interface operation within a given
! <code>binding</code>.</p>
! <ednote>
! <name>KevinL</name>
! <date>20040527</date>
! <edtext>
! Need clarification - wording about QName uniqueness in part 1 section 2.10.1 and 2.11.1 need to change. it's not correct to say "A particular
operation of an interface is uniquely identified by the WSDL target namespace of the interface and the name of the operation within that interface"
! </edtext>
! </ednote>
! <p>Corresponding to its interface <code>operation</code> counterpart, binding <code>operation</code> may also have zero or more <code>input</code>,<code>output</code>, <code>infault</code>, and/or <code>outfault</code>. The presence or absence of these message and/or fault reference constructs within a particular binding <code>operation</code> is governed by the interface <code>operation</code> counterpart.</p>
! </div3>
</div2>
<div2 id="more-bindings-soap">
! <head>Extensions for SOAP Binding</head>
--- 935,983 ----
</edtext>
</ednote>
!
!
! <p>The <code>binding</code> syntax parallels the syntax of <code>interface</code>: each interface construct has a binding counterpart. Despite this syntactic similarity, they are indeed different constructs, since they are in different symbol spaces and are designed for different purposes. </p>
! </div2>
! <div2 id="more-bindings-reusable"><head>Reusable Bindings</head><p>A binding can either be reusable (applicable to any
! interface) or non-reusable (specified for a particular interface). Non-reusable bindings may be specified at the granularity of the interface (assuming the binding extension provides suitable defaulting rules), or on a per-operation basis if needed. A non-reusable binding was demonstrated in <specref ref="basics-binding"/>.</p><p>To define a reusable binding, the <code>binding</code> element simply omits the <code>interface</code> attribute and omits specifying any
! operation-specific and fault-specific binding details. Endpoints can later refer to a resuable binding in the same manner as for a non-reusable binding. Thus, a reusable binding becomes associated with a particular interface when it is referenced from an endpoint, because an endpoint is part of a service, and the service specifies a particular interface that it implements. Since a reusable binding does not specify an interface, reusable bindings cannot specify operation-specific details. Therefore, reusable bindings can only be defined using binding extensions that have suitable defaulting rules, such that the binding information only needs to be explicitly supplied at the interface level.</p></div2><div2 id="more-bindings-faults">
! <head>Binding Faults</head>
+
+
! <p>A binding <code>fault</code> associates a concrete message format with an abstract fault
! of an interface. It describes how faults that occur within a message exchange of an operation will be formatted, since the fault does not occur by itself. Rather, a fault occurs as part of a message
! exchange specified by an interface <code>operation</code> and its binding
! counterpart, the binding <code>operation</code>. </p>
! <p>A binding <code>fault</code> has one required <att>ref</att> attribute which is a reference, by QName, to an <code>interface</code>
! <att>fault</att>. It identifies the abstract interface <code>fault</code> for which binding information is being specified. Be aware that the value of <att>ref</att> attribute of all the <code>faults</code> under a <code>binding</code>
MUST be unique. That is, one cannot define multiple bindings for the same interface fault within a given <code>binding</code>.</p>
! </div2>
! <div2 id="bindingOperations">
! <head id="more-bindings-operations">Binding Operations</head>
! <p>A binding <code>operation</code> describes a concrete binding of a particular
! operation of an interface to a particular concrete message format. A particular
operation of an interface is uniquely identified by the WSDL target namespace of the
! interface and the name of the operation within that interface, via the required <att>ref</att> attribute of binding <code>operation</code>. As with faults, for each <code>operation</code> within a <code>binding</code>, the value of the <att>ref</att> attribute MUST be unique.</p>
! <ednote>
! <name>KevinL</name>
! <date>20040527</date>
! <edtext>ToDo:
! Need clarification - wording about QName uniqueness in part 1 section 2.10.1 and 2.11.1 need to change. it's not correct to say "A particular
operation of an interface is uniquely identified by the WSDL target namespace of the interface and the name of the operation within that interface"
! </edtext>
! </ednote>
!
</div2>
+
+
+
<div2 id="more-bindings-soap">
! <head>The SOAP Binding Extension</head>
***************
*** 1025,1030 ****
</ednote>
! <example id="example-binding-soap">
! <head>SOAP 1.1 and SOAP 1.2 bindings for the reservation interface</head>
<eg><![CDATA[
--- 989,994 ----
</ednote>
! <p>The WSDL 2.0 SOAP Binding Extension (see WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/>) was primarily designed to support the features of SOAP 1.2 <bibref ref="SOAP12-PART1"/>. However, for backwards compatibility, it also provides some support for SOAP 1.1 <bibref ref="SOAP11"/>. </p><p>An example using the WSDL 2.0 SOAP binding extension was already presented in <specref ref="basics-binding"/>, but some additional points are worth mentioning:<ulist><item><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></item><item><p>The WSDL 2.0 SOAP binding extension defines a set of default rules, so that bindings can be specified at the interface level or at the operation level (or both), with the operation level taking precedence. However, it does not define default binding rules for faults. Thus, if a iven interface defines any faults, then corresponding binding infomation must be explicitly provided for each such fault.</p></item></ulist></p><p>Here is an example that illustrates both a SOAP 1.2 binding (as seen before) and a SOAP 1.1 binding.</p><example id="example-binding-soap">
! <head>SOAP 1.2 and SOAP 1.1 Bindings</head>
<eg><![CDATA[
***************
*** 1091,1117 ****
- <p>In this example, I like to highlight the following two constructs (using
- xpath):</p>
- <ulist>
- <item><p>/description/binding[@name="reservationSOAP11Binding"]</p></item>
- <item><p>/description/service/endpoint[@name="reservationEndpoint2"]</p></item>
- </ulist>
- <p>In the above example WSDL, reservation service has two endpoints. Of them,
- one supports SOAP 1.1 message protocol, reservationEndpoint2. This endpoint
- offers reservationInterface via reservationSOAP11Binding, a SOAP 1.1
- binding.</p>
- <p>reservationSOAP11Binding uses the version independent SOAP binding
- extensions, specifies the version of SOAP by assigning 1.1 to wsoap:version
- attribute and indicates SOAP 1.1 HTTP Binding by assigning
- http://www.w3.org/@@@@/@@/soap11/bindings/HTTP to wsoap:protocol attribute.
- This binding also specifies the SOAP 1.1 fault code for transmitting
- invalidDataFault, an Interface Fault Compontent, by assigning soap11:Client
- to wsoap:code attribute.
- </p>
! </div2>
<div2 id="more-bindings-http">
<head>Extensions for HTTP Binding</head>
--- 1055,1067 ----
!
!
! <div3 id="more-bindings-soap-example-explanation"><head>Explanation of Example</head><p><glist><gitem><label><code>xmlns:wsoap= "http://www.w3.org/2004/08/wsdl/soap12"</code></label><def><p>This is the namespace for the WSDL 2.0 SOAP binding extension defined in WSDL 2.0 Part 3 <bibref ref="SOAP12-PART1"/>. </p></def></gitem><gitem><label><code>xmlns:soap="http://www.w3.org/2003/05/soap-envelope"</code></label><def><p>This is the namespace for terms defined within the SOAP 1.2 specification <bibref ref="SOAP12-PART1"/>.</p></def></gitem><gitem><label><code>xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"></code></label><def><p>This is the namespace for terms defined within the SOAP 1.1 specification <bibref ref="SOAP11"/>.</p></def></gitem><gitem><label><code>wsoap:version="1.1"</code></label><def><p>This line indicates that this binding uses SOAP 1.1, rather than SOAP 1.2.</p></def></gitem><gitem><label><code>wsoap:protocol="http://www.w3.org/@@@@/@@/soap11/bindings/HTTP"></code></labl><def><p>This line specifies that HTTP should be used as the underlying transmission protocol.</p></def></gitem><gitem><label><code>wsoap:code="soap11:Client"/></code></label><def><p>This line specifies the SOAP 1.1 fault code that will be used in transmitting invalidDataFault.</p></def></gitem></glist></p>
!
! </div3></div2>
<div2 id="more-bindings-http">
<head>Extensions for HTTP Binding</head>
***************
*** 1361,1365 ****
</ednote>
<!-- =============== -->
! <p>This section shows how the <bibref ref="SOAP-MTOM"/> SOAP Message Transmission Optimization Mechanism may be engaged in the WSDL 2.0 SOAP binding.</p>
<p>Let’s modify the CheckAvailability operation of the GreatH Hotel Reservation Service [ref] to return not only the room rate, but images of the room and the floorplan. We’ll modify the checkAvailabilityResponse data structure to include binary data representing these two images, indicated by xs:base64Binary data type:</p>
--- 1311,1315 ----
</ednote>
<!-- =============== -->
! <p>This section shows how the <bibref ref="SOAP-MTOM"/> SOAP Message Transmission Optimization Mechanism (MTOM) may be engaged in the WSDL 2.0 SOAP binding extension.</p>
<p>Let’s modify the CheckAvailability operation of the GreatH Hotel Reservation Service [ref] to return not only the room rate, but images of the room and the floorplan. We’ll modify the checkAvailabilityResponse data structure to include binary data representing these two images, indicated by xs:base64Binary data type:</p>
***************
*** 1433,1437 ****
]]></eg></example>
! <p>While this (non-optimized) message satisfies the schema definition, a service may choose to allow or require that the binary data be sent in an optimized format using the Message Transmission and Optimization feature. The use of this feature by the SOAP binding is indicated as follows:</p>
--- 1383,1387 ----
]]></eg></example>
! <p>While this (non-optimized) message satisfies the schema definition, a service may choose to allow or require that the binary data be sent in an optimized format using the Message Transmission and Optimization feature. The use of this feature by the SOAP binding extension is indicated as follows:</p>
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.28
retrieving revision 1.29
diff -C2 -d -r1.28 -r1.29
*** wsdl20-primer.html 14 Apr 2005 21:40:45 -0000 1.28
--- wsdl20-primer.html 16 Apr 2005 17:23:43 -0000 1.29
***************
*** 272,305 ****
href="#more-interfaces-inheritance">Interface Inheritance</a><br />
    5.3 <a
! href="#more-interfaces-faults">Reusable Faults</a><br />
    5.4 <a
href="#more-interfaces-operations">Interface Operations</a><br />
        5.4.1 <a
! href="#id5208143">Operation Attributes</a><br />
        5.4.2 <a
! href="#id5208299">Operation Message References</a><br />
            5.4.2.1
! <a href="#id5208352">The messageLabel Attribute</a><br />
            5.4.2.2
! <a href="#id5208387">The element Attribute</a><br />
            5.4.2.3
! <a href="#id5208452">Multiple infault or outfault
Elements</a><br />
        5.4.3 <a
href="#more-interfaces-meps">Understanding Message Exchange
! Patterns</a><br />
        5.4.4 <a
href="#more-interfaces-defining-meps">Defining New Message Exchange
Patterns (MEPs)</a><br />
6. <a href="#more-bindings">More on Bindings</a><br />
!     6.1 <a href="#more-bindings-wsdl">Binding
! Constructs in WSDL Namespace</a><br />
!         6.1.1 <a
! href="#more-bindings-faults">Binding Faults</a><br />
!         6.1.2 <a
! href="#bindingOperations">Binding Operations</a><br />
    6.2 <a
! href="#more-bindings-soap">Extensions for SOAP Binding</a><br />
!     6.3 <a
href="#more-bindings-http">Extensions for HTTP Binding</a><br />
7. <a href="#more-service">More on Service Endpoints</a><br />
--- 272,310 ----
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="#id5208184">Operation Attributes</a><br />
        5.4.2 <a
! href="#id5208340">Operation Message References</a><br />
            5.4.2.1
! <a href="#id5208392">The messageLabel Attribute</a><br />
            5.4.2.2
! <a href="#id5208428">The element Attribute</a><br />
            5.4.2.3
! <a href="#id5208492">Multiple infault or outfault
Elements</a><br />
        5.4.3 <a
href="#more-interfaces-meps">Understanding Message Exchange
! Patterns (MEPs)</a><br />
        5.4.4 <a
href="#more-interfaces-defining-meps">Defining New 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 />
!     6.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">Extensions for HTTP Binding</a><br />
7. <a href="#more-service">More on Service Endpoints</a><br />
***************
*** 347,357 ****
Schemas</a><br />
        8.13.1 <a
! href="#id5211715">Schemas in Imported Documents</a><br />
        8.13.2 <a
! href="#id5212538">Multiple Inline Schemas on One Document</a><br />
    8.14 <a href="#adv-schema-location">The
schemaLocation Attribute</a><br />
        8.14.1 <a
! href="#id5211870">Using the id Attribute to Identify Inline
Schemas</a><br />
    8.15 <a href="#adv-rdf-mapping">Mapping to
--- 352,362 ----
Schemas</a><br />
        8.13.1 <a
! href="#id5195262">Schemas in Imported Documents</a><br />
        8.13.2 <a
! href="#id5212550">Multiple Inline Schemas on One Document</a><br />
    8.14 <a href="#adv-schema-location">The
schemaLocation Attribute</a><br />
        8.14.1 <a
! href="#id5212857">Using the id Attribute to Identify Inline
Schemas</a><br />
    8.15 <a href="#adv-rdf-mapping">Mapping to
***************
*** 1197,1204 ****
as shown in the example below. However, in some cases it is
possible to use defaulting rules to supply the information. The
! WSDL 2.0 SOAP binding, for example, defines some defaulting rules
! for operations. (See <em>Web Services Description Language (WSDL)
! Version 2.0 Part 2: Adjuncts</em> [<cite><a href="#WSDL-PART2">WSDL
! 2.0 Adjuncts</a></cite>], <a
href="http://www.w3.org/TR/2004/WD-wsdl20-adjuncts/#soap-defaults">Default
Binding Rules</a>.)</p>
--- 1202,1209 ----
as shown in the example below. However, in some cases it is
possible to use defaulting rules to supply the information. The
! WSDL 2.0 SOAP binding extension, for example, defines some
! defaulting rules for operations. (See <em>Web Services Description
! Language (WSDL) Version 2.0 Part 2: Adjuncts</em> [<cite><a
! href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>], <a
href="http://www.w3.org/TR/2004/WD-wsdl20-adjuncts/#soap-defaults">Default
Binding Rules</a>.)</p>
***************
*** 1209,1218 ****
href="#adv-extensibility"><b>8.1 Extensibility</b></a> for more on
extensibility.) WSDL 2.0 Part 2 [<cite><a href="#WSDL-PART2">WSDL
! 2.0 Adjuncts</a></cite>] defines binding constructs for SOAP 1.2
[<cite><a href="#SOAP12-PART1">SOAP 1.2 Part 1: Messaging
Framework</a></cite>] and HTTP 1.1 [<cite><a href="#RFC2616">IETF
RFC 2616</a></cite>] as predefined extensions, so that SOAP 1.2 or
HTTP 1.1 bindings can be easily defined in WSDL documents. However,
! other specifications could define new binding constructs that could
also be used to define bindings. (As with any extension, other WSDL
processors would have to know about the new constructs in order to
--- 1214,1223 ----
href="#adv-extensibility"><b>8.1 Extensibility</b></a> for more on
extensibility.) WSDL 2.0 Part 2 [<cite><a href="#WSDL-PART2">WSDL
! 2.0 Adjuncts</a></cite>] defines binding extensions for SOAP 1.2
[<cite><a href="#SOAP12-PART1">SOAP 1.2 Part 1: Messaging
Framework</a></cite>] and HTTP 1.1 [<cite><a href="#RFC2616">IETF
RFC 2616</a></cite>] as predefined extensions, so that SOAP 1.2 or
HTTP 1.1 bindings can be easily defined in WSDL documents. However,
! other specifications could define new binding extensions that could
also be used to define bindings. (As with any extension, other WSDL
processors would have to know about the new constructs in order to
***************
*** 1287,1291 ****
<dd>
<p>We've added two more namespace declarations. This one is the
! namespace for the SOAP 1.2 binding construct that is defined in
WSDL 2.0 Part 3 [<cite><a href="#SOAP12-PART1">SOAP 1.2 Part 1:
Messaging Framework</a></cite>]. Elements and attributes prefixed
--- 1292,1296 ----
<dd>
<p>We've added two more namespace declarations. This one is the
! namespace for the SOAP 1.2 binding extension that is defined in
WSDL 2.0 Part 3 [<cite><a href="#SOAP12-PART1">SOAP 1.2 Part 1:
Messaging Framework</a></cite>]. Elements and attributes prefixed
***************
*** 1348,1354 ****
<dd>
! <p>This attribute is specific to WSDL 2.0's SOAP binding (thus it
! uses the <code>wsoap:</code> prefix). It specifies the underlying
! transmission protocol that should be used, in this case HTTP.</p>
</dd>
--- 1353,1360 ----
<dd>
! <p>This attribute is specific to WSDL 2.0's SOAP binding extension
! (thus it uses the <code>wsoap:</code> prefix). It specifies the
! underlying transmission protocol that should be used, in this case
! HTTP.</p>
</dd>
***************
*** 1361,1367 ****
order to specify binding details for it. This element can be
omitted if defaulting rules are instead used to supply the
! necessary information. (See the SOAP binding in <em>WSDL 2.0
! Bindings</em> [<cite><a href="#WSDL-PART2">WSDL 2.0
! Adjuncts</a></cite>] section 4.3 <a
href="http://www.w3.org/TR/2004/WD-wsdl20-adjuncts/#soap-defaults">Default
Binding Rules</a> .)</p>
--- 1367,1373 ----
order to specify binding details for it. This element can be
omitted if defaulting rules are instead used to supply the
! necessary information. (See the SOAP binding extension in WSDL 2.0
! Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]
! section 4.3 <a
href="http://www.w3.org/TR/2004/WD-wsdl20-adjuncts/#soap-defaults">Default
Binding Rules</a> .)</p>
***************
*** 1372,1378 ****
<dd>
! <p>This attribute is also specific to WSDL 2.0's SOAP binding. It
! specifies the SOAP message exchange pattern that will be used to
! implement the abstract WSDL 2.0 message exchange pattern (<a
href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">
in-out</a>) that was specified when the
--- 1378,1385 ----
<dd>
! <p>This attribute is also specific to WSDL 2.0's SOAP binding
! extension. It specifies the SOAP message exchange pattern that will
! be used to implement the abstract WSDL 2.0 message exchange pattern
! (<a
href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out">
in-out</a>) that was specified when the
***************
*** 1393,1400 ****
<dd>
! <p>This attribute is also specific to WSDL 2.0's SOAP binding. This
! specifies the SOAP 1.2 fault code that will cause this fault
! message to be sent. If desired, a list of subcodes can also be
! specified using the optional <code>wsoap:subcodes</code>
attribute.</p>
</dd>
--- 1400,1407 ----
<dd>
! <p>This attribute is also specific to WSDL 2.0's SOAP binding
! extension. This specifies the SOAP 1.2 fault code that will cause
! this fault message to be sent. If desired, a list of subcodes can
! also be specified using the optional <code>wsoap:subcodes</code>
attribute.</p>
</dd>
***************
*** 1610,1619 ****
Component Model</h2>
! <p>In conventional computer science theory, a language consists of
! a (possibly infinite) set of sentences, and each sentence is a
! string of literal symbols or characters. The language specification
! must therefore define two things: the set of permissible sentences,
! and the meaning of each sentence. Indeed, this is the purpose of
! the WSDL 2.0 specification.</p>
<p>However, instead of defining WSDL 2.0 in terms of literal
--- 1617,1626 ----
Component Model</h2>
! <p>In computer science theory, a language consists of a (possibly
! infinite) set of sentences, and each sentence is a finite string of
! literal symbols or characters. A language specification must
! therefore define the set sentences in that language, and, to be
! useful, it should also indicate the meaning of each sentence.
! Indeed, this is the purpose of the WSDL 2.0 specification.</p>
<p>However, instead of defining WSDL 2.0 in terms of literal
***************
*** 1631,1647 ****
<p>Since an XML Infoset can be created from more than one physical
document, a WSDL 2.0 document does not necessarily correspond to a
! single physical document: the word "document" is used figuratively,
! for convenience. Furthermore, since WSDL 2.0 provides
<code>import</code> and <code>include</code> mechanisms, a WSDL 2.0
document may reference other WSDL 2.0 documents to facilitate
! convenient organization or reuse.</p>
! <p>Unfortunately, the terms "element information item" and
! "attribute information item" are rather lengthy. Thus, for
! convenience, this primer often uses the terms "element" and
! "attribute" instead, as a shorthand. It should be understood,
! however, that since WSDL 2.0 is based on the XML Infoset, we really
! mean "element information item" and "attribute information item",
! respectively.</p>
<div class="div2">
--- 1638,1656 ----
<p>Since an XML Infoset can be created from more than one physical
document, a WSDL 2.0 document does not necessarily correspond to a
! single <em>physical</em> document: the word "document" is used
! figuratively, for convenience. Furthermore, since WSDL 2.0 provides
<code>import</code> and <code>include</code> mechanisms, a WSDL 2.0
document may reference other WSDL 2.0 documents to facilitate
! convenient organization or reuse. In such cases, the meaning of the
! including or importing document as a whole will depend (in part) on
! the meaning of the included or imported document.</p>
! <p>The XML Infoset uses terms like "element information item" and
! "attribute information item". Unfortunately, those terms are rather
! lengthy to repeat often. Thus, for convenience, this primer often
! uses the terms "element" and "attribute" instead, as a shorthand.
! It should be understood, however, that since WSDL 2.0 is based on
! the XML Infoset, we really mean "element information item" and
! "attribute information item", respectively.</p>
<div class="div2">
***************
*** 1783,1788 ****
correspond to the <code>description</code>, <code>interface</code>,
<code>binding</code>, <code>service</code>, and
! <code>endpoint</code> element information items, respectively. The
! Description component represents the meaning of the
<code>description</code> element information item, and hence, it
represents the meaning of the WSDL 2.0 document as a whole.</p>
--- 1792,1799 ----
correspond to the <code>description</code>, <code>interface</code>,
<code>binding</code>, <code>service</code>, and
! <code>endpoint</code> element information items, respectively.
! Since WSDL 2.0 relies heavily on the component model to convey the
! meaning of the constructs in the WSDL 2.0 language, you can think
! of the Description component as representing the meaning of the
<code>description</code> element information item, and hence, it
represents the meaning of the WSDL 2.0 document as a whole.</p>
***************
*** 2214,2218 ****
<div class="div2">
<h3><a id="more-interfaces-faults"
! name="more-interfaces-faults"></a>5.3 Reusable Faults</h3>
<p>The <code>fault</code> element is used to declare faults that
--- 2225,2229 ----
<div class="div2">
<h3><a id="more-interfaces-faults"
! name="more-interfaces-faults"></a>5.3 Interface Faults</h3>
<p>The <code>fault</code> element is used to declare faults that
***************
*** 2222,2225 ****
--- 2233,2255 ----
multiple operations.</p>
+ <p>Faults are very similar to messages and can be viewed as a
+ special kind of message. Both faults and messages may carry a
+ payload that is normally described by an element declaration.
+ However, WSDL treats faults and messages slighly differently. The
+ messages of an operation directly refer to their element
+ declaration, however the faults of an operation indirectly refer to
+ their element declaration via a fault element that is defined on
+ the interface.</p>
+
+ <p>The reason for defining faults at the interface level is to
+ allow their reuse across multiple operations. This design is
+ especially beneficial when bindings are defined, since in binding
+ extensions like SOAP there is additional information that is
+ associated with faults. In the case of SOAP, faults have codes and
+ subcodes in addition to a payload. By defining faults at the
+ interface level, common codes and subcodes can be associated with
+ them, thereby ensuring consistency across all operations that use
+ the faults</p>
+
<p>The <code>fault</code> element has a required <code>name</code>
attribute that must be unique within the WSDL document's target
***************
*** 2331,2335 ****
<code>operation</code>. MEPs are further explained in <a
href="#more-interfaces-meps"><b>5.4.3 Understanding Message
! Exchange Patterns</b></a>.</p>
</li>
--- 2361,2365 ----
<code>operation</code>. MEPs are further explained in <a
href="#more-interfaces-meps"><b>5.4.3 Understanding Message
! Exchange Patterns (MEPs)</b></a>.</p>
</li>
***************
*** 2472,2476 ****
<h4><a id="more-interfaces-meps"
name="more-interfaces-meps"></a>5.4.3 Understanding Message
! Exchange Patterns</h4>
<p>WSDL 2.0 message exchange patterns (MEPs) are used to define the
--- 2502,2506 ----
<h4><a id="more-interfaces-meps"
name="more-interfaces-meps"></a>5.4.3 Understanding Message
! Exchange Patterns (MEPs)</h4>
<p>WSDL 2.0 message exchange patterns (MEPs) are used to define the
***************
*** 2743,2829 ****
Bindings</h2>
! <p>A <code>binding</code> can be defined for different levels of
! reusability. It can be used to describe binding information in a
! re-usable manner for any interface or specifically for a given
! interface. Furthermore, binding information MAY be specified on a
! per-operation basis if needed. If a <code>binding</code> specifies
! any operation-specific binding details or any fault binding
! details, then it MUST specify an interface the binding information
! applies to, so as to indicate which interface the operations come
! from.</p>
!
! <p>To define a reusable binding, a <code>binding</code> should omit
! any operation-specific binding details and any fault binding
! details MAY omit specifying an interface. <code>bindings</code>
! that do not specify an interface MAY be used to specify
! operation-independent binding details for Service components with
! different interfaces. That is, such <code>bindings</code> are
! reusable across one or more interfaces.</p>
! <p>A <code>binding</code> tied to a particular interface MUST
! define bindings for all the operations of that interface. The
! bindings may occur via defaulting rules which allow one to specify
! default bindings for all operations (for example, see the SOAP
! binding in <em>WSDL 2.0 Bindings</em> [<cite><a
href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section 4.3 <a
href="http://www.w3.org/TR/2004/WD-wsdl20-adjuncts/#soap-defaults">Default
! Binding Rules</a>) or by directly listing each operation of the
! interface and defining bindings for them. Thus, it is an error for
! a binding to not define bindings for all the operations of the
! corresponding interface.</p>
!
! <p>The binding constructs can be grouped into two categories: those
! in the WSDL namespace of "http://www.w3.org/2004/08/wsdl" and those
! not in WSDL namespace. WSDL 2.0 Part 1 [<cite><a
! href="#WSDL-PART1">WSDL 2.0 Core Language</a></cite>]defines a set
! of binding constructs within the WSDL namespace that can be used to
! host binding detail definitions. Constructs for defining binding
! details are defined within their own namespaces which must be
! different from the WSDL namespace. ll these binding detail
! constructs are defined outside WSDL namespace, and are typically
! used as extensions of the hosting WSDL binding constructs. In the
! following sections, we will introduce the hosting WSDL binding
! constructs first, and then move on the the binding extensions.</p>
<div class="div2">
<h3><a id="more-bindings-wsdl" name="more-bindings-wsdl"></a>6.1
! Binding Constructs in WSDL Namespace</h3>
! <p>Let's have a look at the constructs defined within the WSDL
! namespace first. The XML syntax of these constructs is summarized
! below:</p>
<div class="exampleInner">
<pre>
<description targetNamespace="<em>xs:anyURI</em>" >
!
<<b>binding</b> name="<em>xs:NCName</em>" interface="<em>xs:QName</em>"? >
- <documentation />?
! <fault ref="<em>xs:QName</em>" >
! <documentation />?
! </fault>*
<operation ref="<em>xs:QName</em>" >
! <documentation />?
!
! <input messageLabel="<em>xs:NCName</em>"? >
! <documentation />?
! </input>*
!
! <output messageLabel="<em>xs:NCName</em>"? >
! <documentation />?
! </output>*
!
! <feature ... />*
!
! <property ... />*
</operation>*
- <feature ... />*
-
- <property ... />*
</<b>binding</b>>*
!
</description>
</pre>
--- 2773,2832 ----
Bindings</h2>
! <p>Bindings are used to supply protocol and encoding details that
! specify <em>how</em> messages are to be sent or received. Each
! <code>binding</code> element uses a particular <em>binding
! extension</em> to specify such information. WSDL 2.0 Part 2
! [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] defines
! several binding extensions that are typically used. However,
! binding extensions that are not defined in WSDL 2.0 Part 2 can also
! be used, provided that client and service toolkits support
! them.</p>
! <p>Binding information must be supplied for every operation in an
! interface that is used in an endpoint. However, if the desired
! binding extension provides suitable defaulting rules, then the
! information will only need to be explicitly supplied at the
! interface level, and the defaulting rules will implicitly propagate
! the information to the operations of the interface. For example,
! see the SOAP binding extension in WSDL 2.0 Part 2 [<cite><a
href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section 4.3 <a
href="http://www.w3.org/TR/2004/WD-wsdl20-adjuncts/#soap-defaults">Default
! Binding Rules</a>.</p>
<div class="div2">
<h3><a id="more-bindings-wsdl" name="more-bindings-wsdl"></a>6.1
! Syntax Summary for Bindings</h3>
! <p>Since bindings are specified using extensions to the WSDL 2.0
! language (i.e., binding extensions are not in the WSDL 2.0
! namespace), the XML for expressing a binding will consist of a
! mixture of elements and attributes from WSDL 2.0 namespace and from
! the binding extension's namespace, using WSDL 2.0's open content
! model.</p>
!
! <p>Here is a syntax summary for <code>binding</code>, simplified by
! omitting optional <code>documentation</code>, <code>feature</code>
! and <code>property</code> elements. Bear in mind that this syntax
! summary only shows the elements and attributes defined within the
! WSDL 2.0 namespace. When an actual binding is defined, elements and
! attributes from the namespace of the desired binding extension will
! also be intermingled as required by that particular binding
! extension.</p>
<div class="exampleInner">
<pre>
<description targetNamespace="<em>xs:anyURI</em>" >
! . . .
<<b>binding</b> name="<em>xs:NCName</em>" interface="<em>xs:QName</em>"? >
! <fault ref="<em>xs:QName</em>" > </fault>*
<operation ref="<em>xs:QName</em>" >
! <input messageLabel="<em>xs:NCName</em>"? > </input>*
! <output messageLabel="<em>xs:NCName</em>"? > </output>*
</operation>*
</<b>binding</b>>*
! . . .
</description>
</pre>
***************
*** 2844,2929 ****
</table>
! <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%"> </td>
! </tr>
!
! <tr>
! <td colspan="2" align="left" valign="top">Trim some of this?
! Redundant?</td>
! </tr>
! </table>
!
! <p>One WSDL <code>description</code> element may contain zero or
! more <code>binding</code> elements as its direct children.</p>
!
! <p>The <code>binding</code> element has a required
! <code>name</code> attribute. Within the same WSDL target namespace
! , each binding must have a unique name. The optional
! <code>interface</code> attribute refers, by QName, to an
! <code>interface</code>. See the previous section for how the
! <code>interface</code> attribute can be used to achieve different
! levels of reusability of the <code>binding</code>.</p>
!
! <p>Careful readers may have already noticed that the
! <code>binding</code> syntax is to some extent symmetric with the
! syntax of <code>interface</code>, in other words, each interface
! construct has a binding counterpart. Simliar to
! <code>interface</code>,a <code>binding</code> element can contain
! zero or more <code>fault</code>, zero or more
! <code>operation</code>, zero or more <code>feature</code>, and zero
! or more <code>property</code>. Be aware that despite of the syntax
! similarity, they are indeed different constructs since they are in
! different symbol spaces and are designed for different purpose. The
! <code>feature</code> and <code>property</code> element will be
! examined in section @@@@. We will explain the binding
! <code>fault</code> and <code>operation</code> constructs in the
! following sections.</p>
!
! <div class="div3">
! <h4><a id="more-bindings-faults"
! name="more-bindings-faults"></a>6.1.1 Binding Faults</h4>
! <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%">20050310</td>
! </tr>
! <tr>
! <td colspan="2" align="left" valign="top">Incoporated contribution
! from Arthur. Need to check back this section for integration with
! rest of document.</td>
! </tr>
! </table>
! <p>Faults are very similar to messages and can be viewed as a
! special kind of message. Both faults and messages may carry a
! payload that is normally described by an element declaration.
! However, WSDL treats faults and messages slighly differently. The
! messages of an operation directly refer to their element
! declaration, however the faults of an operation indirectly refer to
! their element declaration via a fault element that is defined on
! the interface.</p>
! <p>The reason for defining faults at the interface level is to
! allow their reuse accross multiple operations. This design is
! especially beneficial when bindings are defined since in bindings
! like SOAP there is additional information that is associated with
! faults. In the case of SOAP, faults have codes and subcodes in
! addition to a payload. By defining faults at the interface level,
! common codes and subcodes can be associated with them, thereby
! ensuring consistency accross all operations that use the faults</p>
! <p>A binding <code>fault</code> describes a concrete binding of an
! abstract fault within an interface to a particular concrete message
! format. More precisely, it describes how faults that occur within a
! message exchange of an operation will be formatted since the fault
! does not occur by itself - it occurs as part of a message exchange
! as defined by an interface <code>operation</code> and its binding
! counterpart the binding <code>operation</code>.</p>
<p>A binding <code>fault</code> has one required <code>ref</code>
--- 2847,2896 ----
</table>
! <p>The <code>binding</code> syntax parallels the syntax of
! <code>interface</code>: each interface construct has a binding
! counterpart. Despite this syntactic similarity, they are indeed
! different constructs, since they are in different symbol spaces and
! are designed for different purposes.</p>
! </div>
! <div class="div2">
! <h3><a id="more-bindings-reusable"
! name="more-bindings-reusable"></a>6.2 Reusable Bindings</h3>
! <p>A binding can either be reusable (applicable to any interface)
! or non-reusable (specified for a particular interface).
! Non-reusable bindings may be specified at the granularity of the
! interface (assuming the binding extension provides suitable
! defaulting rules), or on a per-operation basis if needed. A
! non-reusable binding was demonstrated in <a
! href="#basics-binding"><b>2.5 Defining a Binding</b></a>.</p>
! <p>To define a reusable binding, the <code>binding</code> element
! simply omits the <code>interface</code> attribute and omits
! specifying any operation-specific and fault-specific binding
! details. Endpoints can later refer to a resuable binding in the
! same manner as for a non-reusable binding. Thus, a reusable binding
! becomes associated with a particular interface when it is
! referenced from an endpoint, because an endpoint is part of a
! service, and the service specifies a particular interface that it
! implements. Since a reusable binding does not specify an interface,
! reusable bindings cannot specify operation-specific details.
! Therefore, reusable bindings can only be defined using binding
! extensions that have suitable defaulting rules, such that the
! binding information only needs to be explicitly supplied at the
! interface level.</p>
! </div>
! <div class="div2">
! <h3><a id="more-bindings-faults"
! name="more-bindings-faults"></a>6.3 Binding Faults</h3>
! <p>A binding <code>fault</code> associates a concrete message
! format with an abstract fault of an interface. It describes how
! faults that occur within a message exchange of an operation will be
! formatted, since the fault does not occur by itself. Rather, a
! fault occurs as part of a message exchange specified by an
! interface <code>operation</code> and its binding counterpart, the
! binding <code>operation</code>.</p>
<p>A binding <code>fault</code> has one required <code>ref</code>
***************
*** 2938,2955 ****
</div>
! <div class="div3">
! <h4><a id="bindingOperations" name="bindingOperations"></a>6.1.2
! Binding Operations</h4>
<p>A binding <code>operation</code> describes a concrete binding of
a particular operation of an interface to a particular concrete
! message format.A particular operation of an interface is uniquely
identified by the WSDL target namespace of the interface and the
name of the operation within that interface, via the required
! <code>ref</code> attribute of binding <code>operation</code>. For
! each <code>operation</code> within a <code>binding</code>, the
! value of <code>ref</code> attribute MUST be unique. That is, one
! cannot define multiple bindings for the same interface operation
! within a given <code>binding</code>.</p>
<table border="1" summary="Editorial note: KevinL">
--- 2905,2921 ----
</div>
! <div class="div2">
! <h3><a id="bindingOperations" name="bindingOperations"></a>6.4
! Binding Operations</h3>
<p>A binding <code>operation</code> describes a concrete binding of
a particular operation of an interface to a particular concrete
! message format. A particular operation of an interface is uniquely
identified by the WSDL target namespace of the interface and the
name of the operation within that interface, via the required
! <code>ref</code> attribute of binding <code>operation</code>. As
! with faults, for each <code>operation</code> within a
! <code>binding</code>, the value of the <code>ref</code> attribute
! MUST be unique.</p>
<table border="1" summary="Editorial note: KevinL">
***************
*** 2961,2986 ****
<tr>
! <td colspan="2" align="left" valign="top">Need clarification -
! wording about QName uniqueness in part 1 section 2.10.1 and 2.11.1
! need to change. it's not correct to say "A particular operation of
! an interface is uniquely identified by the WSDL target namespace of
! the interface and the name of the operation within that
! interface"</td>
</tr>
</table>
-
- <p>Corresponding to its interface <code>operation</code>
- counterpart, binding <code>operation</code> may also have zero or
- more <code>input</code>,<code>output</code>, <code>infault</code>,
- and/or <code>outfault</code>. The presence or absence of these
- message and/or fault reference constructs within a particular
- binding <code>operation</code> is governed by the interface
- <code>operation</code> counterpart.</p>
- </div>
</div>
<div class="div2">
! <h3><a id="more-bindings-soap" name="more-bindings-soap"></a>6.2
! Extensions for SOAP Binding</h3>
<table border="1" summary="Editorial note: KevinL">
--- 2927,2943 ----
<tr>
! <td colspan="2" align="left" valign="top">ToDo: Need clarification
! - wording about QName uniqueness in part 1 section 2.10.1 and
! 2.11.1 need to change. it's not correct to say "A particular
! operation of an interface is uniquely identified by the WSDL target
! namespace of the interface and the name of the operation within
! that interface"</td>
</tr>
</table>
</div>
<div class="div2">
! <h3><a id="more-bindings-soap" name="more-bindings-soap"></a>6.5
! The SOAP Binding Extension</h3>
<table border="1" summary="Editorial note: KevinL">
***************
*** 2998,3006 ****
</table>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a
id="example-binding-soap"
name="example-binding-soap"></a><i><span>Example 6-1.</span> SOAP
! 1.1 and SOAP 1.2 bindings for the reservation interface</i></p>
<div class="exampleInner">
--- 2955,3000 ----
</table>
+ <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:</p>
+
+ <ul>
+ <li>
+ <p>Because the same binding extension is used for both SOAP 1.2 and
+ SOAP 1.1, a <code>wsoap:version</code> attribute is provided to
+ allow you to indicate which version of SOAP you want. If this
+ attribute is not specified, it defaults to SOAP 1.2.</p>
+ </li>
+
+ <li>
+ <p>The WSDL 2.0 SOAP binding extension defines a set of default
+ rules, so that bindings can be specified at the interface level or
+ at the operation level (or both), with the operation level taking
+ precedence. However, it does not define default binding rules for
+ faults. Thus, if a given interface defines any faults, then
+ corresponding binding infomation must be explicitly provided for
+ each such fault.</p>
+ </li>
+ </ul>
+
+ <br />
+ <br />
+ <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
id="example-binding-soap"
name="example-binding-soap"></a><i><span>Example 6-1.</span> SOAP
! 1.2 and SOAP 1.1 Bindings</i></p>
<div class="exampleInner">
***************
*** 3067,3099 ****
</div>
! <p>In this example, I like to highlight the following two
! constructs (using xpath):</p>
! <ul>
! <li>
! <p>/description/binding[@name="reservationSOAP11Binding"]</p>
! </li>
! <li>
! <p>/description/service/endpoint[@name="reservationEndpoint2"]</p>
! </li>
! </ul>
! <p>In the above example WSDL, reservation service has two
! endpoints. Of them, one supports SOAP 1.1 message protocol,
! reservationEndpoint2. This endpoint offers reservationInterface via
! reservationSOAP11Binding, a SOAP 1.1 binding.</p>
! <p>reservationSOAP11Binding uses the version independent SOAP
! binding extensions, specifies the version of SOAP by assigning 1.1
! to wsoap:version attribute and indicates SOAP 1.1 HTTP Binding by
! assigning http://www.w3.org/@@@@/@@/soap11/bindings/HTTP to
! wsoap:protocol attribute. This binding also specifies the SOAP 1.1
! fault code for transmitting invalidDataFault, an Interface Fault
! Compontent, by assigning soap11:Client to wsoap:code attribute.</p>
</div>
<div class="div2">
! <h3><a id="more-bindings-http" name="more-bindings-http"></a>6.3
Extensions for HTTP Binding</h3>
--- 3061,3123 ----
</div>
! <div class="div3">
! <h4><a id="more-bindings-soap-example-explanation"
! name="more-bindings-soap-example-explanation"></a>6.5.1 Explanation
! of Example</h4>
! <dl>
! <dt class="label"><code>xmlns:wsoap=
! "http://www.w3.org/2004/08/wsdl/soap12"</code></dt>
! <dd>
! <p>This is the namespace for the WSDL 2.0 SOAP binding extension
! defined in WSDL 2.0 Part 3 [<cite><a href="#SOAP12-PART1">SOAP 1.2
! Part 1: Messaging Framework</a></cite>].</p>
! </dd>
! <dt class="label">
! <code>xmlns:soap="http://www.w3.org/2003/05/soap-envelope"</code></dt>
! <dd>
! <p>This is the namespace for terms defined within the SOAP 1.2
! specification [<cite><a href="#SOAP12-PART1">SOAP 1.2 Part 1:
! Messaging Framework</a></cite>].</p>
! </dd>
!
! <dt class="label">
! <code>xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"></code></dt>
!
! <dd>
! <p>This is the namespace for terms defined within the SOAP 1.1
! specification [<cite><a href="#SOAP11">SOAP 1.1</a></cite>].</p>
! </dd>
!
! <dt class="label"><code>wsoap:version="1.1"</code></dt>
!
! <dd>
! <p>This line indicates that this binding uses SOAP 1.1, rather than
! SOAP 1.2.</p>
! </dd>
!
! <dt class="label">
! <code>wsoap:protocol="http://www.w3.org/@@@@/@@/soap11/bindings/HTTP"></code></dt>
!
! <dd>
! <p>This line specifies that HTTP should be used as the underlying
! transmission protocol.</p>
! </dd>
!
! <dt class="label"><code>wsoap:code="soap11:Client"/></code></dt>
!
! <dd>
! <p>This line specifies the SOAP 1.1 fault code that will be used in
! transmitting invalidDataFault.</p>
! </dd>
! </dl>
! </div>
</div>
<div class="div2">
! <h3><a id="more-bindings-http" name="more-bindings-http"></a>6.6
Extensions for HTTP Binding</h3>
***************
*** 3595,3599 ****
<p>This section shows how the [<cite><a href="#SOAP-MTOM">SOAP
MTOM</a></cite>] SOAP Message Transmission Optimization Mechanism
! may be engaged in the WSDL 2.0 SOAP binding.</p>
<p>Let’s modify the CheckAvailability operation of the GreatH Hotel
--- 3619,3623 ----
<p>This section shows how the [<cite><a href="#SOAP-MTOM">SOAP
MTOM</a></cite>] SOAP Message Transmission Optimization Mechanism
! (MTOM) may be engaged in the WSDL 2.0 SOAP binding extension.</p>
<p>Let’s modify the CheckAvailability operation of the GreatH Hotel
***************
*** 3692,3696 ****
binary data be sent in an optimized format using the Message
Transmission and Optimization feature. The use of this feature by
! the SOAP binding is indicated as follows:</p>
<div class="exampleOuter">
--- 3716,3720 ----
binary data be sent in an optimized format using the Message
Transmission and Optimization feature. The use of this feature by
! the SOAP binding extension is indicated as follows:</p>
<div class="exampleOuter">
Received on Saturday, 16 April 2005 17:23:47 UTC