- From: Kevin Liu via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 27 Apr 2005 23:27:49 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv17766/ws/desc/wsdl20
Modified Files:
wsdl20-primer.html wsdl20-primer.xml
Log Message:
Rewrote the MEP section. Added example for use of outboud meps.
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.67
retrieving revision 1.68
diff -C2 -d -r1.67 -r1.68
*** wsdl20-primer.xml 27 Apr 2005 20:29:49 -0000 1.67
--- wsdl20-primer.xml 27 Apr 2005 23:27:47 -0000 1.68
***************
*** 116,120 ****
</div1>
! <!-- ******************************************************* -->
<div1 id="basics">
<head>WSDL 2.0 Basics</head>
--- 116,122 ----
</div1>
!
! <!-- ****************WSL2.0 BASICS********************************* -->
! <!-- ****************WSL2.0 BASICS********************************* -->
<div1 id="basics">
<head>WSDL 2.0 Basics</head>
***************
*** 481,484 ****
--- 483,489 ----
<div3 id="example-initial-documentation-explanation"><head>Explanation of Example</head><glist><gitem><label><code><documentation></code></label><def><p> This element is optional, but a good idea to include. It can contain arbitrary mixed content. </p></def></gitem><gitem><label><code>at http://greath.example.com/2004/reservation-documentation.html</code></label><def><p>The most important thing to include is a pointer to any additional documentation that a client developer would need in order to use the service. </p></def></gitem></glist><p>This completes our presentation of the GreatH example. </p></div3></div2>
</div1>
+
+ <!-- ****************WSL2.0 Infoset, Schema and Component Model********************************* -->
+ <!-- ****************WSL2.0 Infoset, Schema and Component Model********************************* -->
<div1 id="wsdl-xml-representation"><head>WSDL 2.0 Infoset, Schema and Component Model</head>
***************
*** 591,597 ****
<div1 id="more-types"><head>More on Message Types</head>
- <!-- ******************MessageTypes********************************** -->
- <!-- ******************MessageTypes********************************** -->
<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
<bibref ref="XMLSchemaP1"/>, 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 <bibref ref="WSDL-PART1"/> Appendix E "<xspecref href="http://www.w3.org/TR/wsdl20-primer#other-schemalang">Examples of Specifications of Extension Elements for Alternative Schema Language Support. (Non-Normative)</xspecref>".
--- 596,603 ----
+ <!-- ******************MessageTypes********************************** -->
+ <!-- ******************MessageTypes********************************** -->
+
<div1 id="more-types"><head>More on Message Types</head>
<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
<bibref ref="XMLSchemaP1"/>, 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 <bibref ref="WSDL-PART1"/> Appendix E "<xspecref href="http://www.w3.org/TR/wsdl20-primer#other-schemalang">Examples of Specifications of Extension Elements for Alternative Schema Language Support. (Non-Normative)</xspecref>".
***************
*** 794,798 ****
<div2 id="more-interfaces-operations">
<head>Interface Operations</head>
! <p>As shown earlier, the <code>operation</code> element is used to indicate an operation supported by the containing interface. It associates message schemas with a message exchange pattern (MEP), in order abstractly describe a simple interaction with a Web service. </p>
--- 800,804 ----
<div2 id="more-interfaces-operations">
<head>Interface Operations</head>
! <p>As shown earlier, the <code>operation</code> element is used to indicate an operation supported by the containing interface. It associates message schemas with a message exchange pattern (MEP), in order to abstractly describe a simple interaction with a Web service. </p>
***************
*** 819,823 ****
</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><p>The <att>messageLabel</att> attribute of the <code>input</code> and <code>output</code> elements is optional: it is not necessary to explicitly set the <code>messageLabel</code> when the MEP in use is one of the eight MEPs predefined in WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/> and it has only one message with a given direction. </p></div4><div4><head>The element Attribute</head><p>The <att>element</att> attribute of the <code>input</code> and <code>output</code> elements is used to specify the message content schema (a/k/a payload schema) when the content model is defined using XML Schema. As we have seen already, it can specify the QName of an element schema that was defined in the <code>types</code> section. However, alternatively it can specify one of the following tokens: <glist><gitem><label><code>#any</code></label><def><p>The message content is any single element.</p></def></gitem><gitem><label><code>#none</code></label><def><p>There is no mesage content, i.e., the message payload is empty.</p></def></gitem></glist>The <code>element</code> attribute is also optional. If it is not specified, then @@@@. <ednote><edtext>ToDo: Say what happens if the element attribute is not specified, after issue LC99 is resolved. See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC99 </edtext></ednote></p></div4><div4><head>Multiple infault or outfault Elements</head><p>When <code>infault</code> and/or <code>outfault</code> occur multiple times within an <code>operation</code>, they define alternative fault messages. </p></div4></div3>
- <!-- ************************messages*************************** -->
<!-- ************************MEPs*************************** -->
--- 825,828 ----
***************
*** 825,893 ****
<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
! nodes. By some prior agreement, another node and/or the service may send other
! messages (to each other or to other nodes) that are not described by the
MEP. For instance, even though an MEP may define a single message sent
! from a service to one other node, the Web Service may multicast that message to
! other nodes. To maximize reuse, WSDL message exchange patterns identify a minimal contract between other parties and Web Services, and contain only information that is
! relevant to both the Web service and the client that engages that service.</p>
! <p>A total of 8 MEPs are defined in WSDL 2.0 Part 2 <bibref ref="WSDL-PART2"/>. Hopefully, these MEPs will cover the most common use cases, but they are not meant to be an exhaustive list of MEPs that can ever be used by operations. More MEPs can be defined for particular application needs by interested parties. (See <ednote><name>dbooth</name><edtext>Add info about how to define a new MEP?</edtext></ednote></p>
! <p>For the 8 MEPs defined by WSDL 2.0, some of them are variations of others based on how faults may be generated. Three common fault generation models are specified. <glist><gitem><label>Fault Replaces Message</label><def><p>Any message after the first in the pattern MAY be replaced with a fault message, which MUST have identical cardinality and direction. The fault message MUST be delivered to the same target node as the message it replaces. </p></def></gitem><gitem><label>Message Triggers Fault</label><def><p>Any message, including the first, MAY trigger a fault message in response. Each recipient MAY generate a fault message, and MUST generate no more than one fault for each triggering message. Each fault message has direction the reverse of its triggering message. The fault message MUST be delivered to the originator of the message which triggered it. If there is no path to this node, the fault MUST be discarded. In the third case, no fault may be generated in the MEP. </p></def></gitem><gitem><abel>No Faults</label><def><p>No faults will be delivered.</p></def></gitem></glist></p>
! <p>Now let's have a look of each of the 8 MEPs. Depends on how the first message in the MEP is initiated, we can probably group the MEPs into in-bound MEPs in which case the service receives the first message in the exchange, and out-bound MEPs in which case the service sends out the first message in the exchange. Such Grouping is only for the purpose of easy reference from discussions in later sections of this primer. WSDL 2.0 defines four in-bound MEPS:</p>
! <ednote><edtext>ToDo: Check/update the MEP URIs prior to final publication.</edtext></ednote><ulist>
! <item>
! <p>
! <b>In-Only</b> ("http://www.w3.org/2004/03/wsdl/in-only")</p>
! <p>This patten consists of exactly one message received by a service from some other node. No fault maybe generated. </p>
! </item>
! <item>
! <p>
! <b>Robust In-Only</b> ("http://www.w3.org/2004/03/wsdl/robust-in-only")</p>
! <p>This pattern can be considered as a variation of In-only. It also consists of exactly one message received by a service, but in this case faults can be triggered by the message as specified in the "Message Triggers Fault" model. </p>
! </item>
! <item>
! <p>
! <b>In-Out</b> ("http://www.w3.org/2004/03/wsdl/in-out")</p>
! <p>This patten consists of exactly two message: a message received by a service from some other node, followed by a message sent to the other node. The second message may be replaced by a fault as specified in the "Fault Replace Message" model. </p>
! </item>
! <item>
! <p>
! <b>In-Optional-Out</b> ("http://www.w3.org/2004/03/wsdl/in-opt-out")</p>
! <p>This patten consists of one or two messages: a message received by a service from some other node, optionally followed by a message sent to the other node from the service. Each message may trigger a fault in response as specified in the "Message Triggers Faults" model. </p>
! </item>
! </ulist>
! <p>WSDL 2.0 also defines four out-bound MEPs which sort of mirror the in-bound MEPs with reserved direction:</p>
! <ulist>
! <item>
! <p>
! <b>Out-Only</b> ("http://www.w3.org/2004/03/wsdl/out-only")</p>
! <p>This patten consists of exactly one message sent to some other node from a service. No fault maybe generated. </p>
! </item>
! <item>
! <p>
! <b>Robust Out-Only</b> ("http://www.w3.org/2004/03/wsdl/robust-out-only")</p>
! <p>This pattern can be considered as a variation of Out-only. It also consists of exactly one message sent to some other node from a service, but in this case faults can be triggered by the message as specified in the "Message Triggers Fault" model. </p>
! </item>
! <item>
! <p>
! <b>Out-in</b> ("http://www.w3.org/2004/03/wsdl/out-in")</p>
! <p>This patten consists of exactly two message: a message sent to some other node from a service, followed by a message received by the service from the other node. The second message may be replaced by a fault as specified in the "Fault Replace Message" model. </p>
! </item>
! <item>
! <p>
! <b>Out-Optional-In</b> ("http://www.w3.org/2004/03/wsdl/out-opt-in")</p>
! <p>This patten consists of one or two messages: a message sent to some other node from a service, optionally followed by a message received by the service from the other node. Each message may trigger a fault in response as specified in the "Message Triggers Faults" model. </p>
! </item>
! </ulist>
! <p>While the in-bound MEPs are easier to understand, there have been questions concerning the usefulness of out-bound MEPs, especially how a service can specify the endpoint information for the target node of the initial out-bound message. In their typical use cases, such as in large scale intergration projects where endpoint information is most likely specified at deployment or runtime by mapping and routing facilities, or/and in languages that facilitate services composition where only abstract interfaces are concerned, Out-bound MEPs are useful in the abstract level for fully specifying the functionality of a service, including its requirements for its potential customers, so application integrator can gain a better understanding of how multiple services may be used together, whereas binding and endpoint information may be provided by integration infrastructure in application deployment and runtime.</p>
! <ednote>
! <name>KevinL</name>
! <date>20040910</date>
! <edtext>
! Add more MEP use cases and example - illustrate use of outbound meps?
!
! </edtext>
! </ednote>
</div3>
--- 830,863 ----
<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 WSDL MEPs do not exhaustively describe the set of messages that may be exchanged between a service and other nodes. By some prior agreement, another node and/or the service may send other messages (to each other or to other nodes) that are not described by the
MEP. For instance, even though an MEP may define a single message sent
! from a service to one other node, a service defined by that MEP may multicast that message to
! other nodes. To maximize reuse, WSDL message exchange patterns identify a minimal contract between other parties and Web Services, and contain only information that is relevant to both the Web service and the client that engages that service.</p>
! <p>A total of 8 MEPs are defined in <bibref ref="WSDL-PART2"/>. Hopefully, these MEPs will cover the most common use cases, but they are not meant to be an exhaustive list of MEPs that can ever be used by operations. More MEPs can be defined for particular application needs by interested parties. (See <specref ref="more-interfaces-defining-meps"/> )</p>
! <p>For the 8 MEPs defined by WSDL 2.0, some of them are variations of others based on how faults may be generated. For example, the In-Only pattern ("http://www.w3.org/@@@@/@@/wsdl/in-only") consists of exactly one message received by a service from some other node. No fault maybe generated. As a variation of In-Only, Robust In-Only pattern ("http://www.w3.org/@@@@/@@/wsdl/robust-in-only") also consists of exactly one message received by a service, but in this case faults can be triggered by the message and MUST be delivered to the originator of the message. If there is no path to this node, the fault MUST be discarded. For details about the common fault generation models used by the 8 WSDL 2.0 MEPs, see <bibref ref="WSDL-PART2"/>. </p>
+ <p>Depends on how the first message in the MEP is initiated, the 8 WSDL MEPs may be grouped into two groups: in-bound MEPs in which case the service receives the first message in the exchange, and out-bound MEPs in which case the service sends out the first message in the exchange. (Such Grouping is only for the purpose of easy reference in this primer).</p>
+
+ <p> A frequently asked question about out-bound MEPs is how a service knows where to send the message. Services using out-bound MEPs are typically part of large scale intergration systems that rely on mapping and routing facilities. In such systems, out-bound MEPs are useful for abstractly specifing the functionality of a service, including its requirements for potential customers, while endpoint address information can be provided at deployment or runtime by integration infrastructure. For example, the GreatH hotel reservation system may require that everytime a customer interacts with the system to check availability, data about the customer must be logged by a CRM system. At design time, it's unknown which particular CRM system would be used together with the reservation system. To address this requirement, we may change the "reservationInterface" in <specref ref="example-initial"/> to include an out-bound logInquiry operation. This logInquiry operation advertises to potential service clients thatcustomer data will be made available by the reservation service at run time. When the reservation service is deployed to GreatH's IT landscape, appropriate configuration time and run time infrastructure will help determine which CRM system will get the customer data and log it appropriately. It's worth noting that in addition to being used by a CRM system for customer management purpose, the same data may also be used by a system performance analysis tool for different purpose. Providing an out-bound operation in the reservation service enables loose coupling and so improves the overall GreatH IT landscape's flexbility and scalability. </p>
+
+ <example id="example-outbound-operation">
+ <head>Use of outbound MEPs</head>
+ <eg xml:space="preserve">
+
+ <description ...>
+ ...
+ <interface name="reservationInterface">
+ ...
+ <operation name="opCheckAvailability" ... >
+
+ <operation name="opLogInquiry"
+ <b>pattern="http://www.w3.org/@@@@/@@/wsdl/out"</b>>
+ <<b>output messageLabel="Out" element="ghns:customerData"</b> />
+ </operation>
+
+ </interface>
+ ...
+ </description></eg>
+ </example>
</div3>
***************
*** 907,912 ****
provides a well-defined convention for naming and reusing them.</p></div3></div2>
</div1>
! <!-- **********************************Binding************************** -->
! <!-- **********************************Binding************************** -->
<div1 id="more-bindings">
<head>More on Bindings</head>
--- 877,883 ----
provides a well-defined convention for naming and reusing them.</p></div3></div2>
</div1>
!
! <!-- **********************************Binding************************** -->
! <!-- **********************************Binding************************** -->
<div1 id="more-bindings">
<head>More on Bindings</head>
***************
*** 1043,1052 ****
-
-
-
-
-
-
<div3 id="more-bindings-soap-example-explanation"><head>Explanation of Example</head><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: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></label><def><p>This line specifies that HTTP should be used as the underlying transmission protocol. See also <specref ref="adv-get-vs-post"/>.</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 ued in transmitting invalidDataFault.</p></def></gitem></glist></p>
--- 1014,1017 ----
***************
*** 1096,1108 ****
</gitem><gitem>
<label><code>xmlns:whttp="http://www.w3.org/@@@@/@@/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><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><example id="example-bindings-http-path-subsset">
<head>Serializing a Subset of Types in the Path</head>
<eg xml:space="preserve">
--- 1061,1068 ----
</gitem><gitem>
<label><code>xmlns:whttp="http://www.w3.org/@@@@/@@/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>
! <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><example id="example-bindings-http-path-subsset">
<head>Serializing a Subset of Types in the Path</head>
<eg xml:space="preserve">
***************
*** 1123,1128 ****
! <!-- **********************************AdvancedTopics***************** -->
! <!-- **********************************AdvancedTopics***************** -->
<div1 id="advanced-topic_ii">
<head>Advanced Topics</head>
--- 1083,1088 ----
! <!-- **********************************AdvancedTopics***************** -->
! <!-- **********************************AdvancedTopics***************** -->
<div1 id="advanced-topic_ii">
<head>Advanced Topics</head>
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.47
retrieving revision 1.48
diff -C2 -d -r1.47 -r1.48
*** wsdl20-primer.html 27 Apr 2005 20:29:49 -0000 1.47
--- wsdl20-primer.html 27 Apr 2005 23:27:47 -0000 1.48
***************
*** 94,99 ****
<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></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 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="#basics-nterface">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> 3. <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-embed">Embedding 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-op-att">Operation Attributes</a><br> 5.4.2 <a href="#N10894">Operation Message References</a><br> 5.4.2.1 <a href="#N108B1">The messageLabel Attribute</a><br> 5.4.2.2 <a href="#N108C5">The element Attribute</a><br> 5.4.2.3 <a href="#N108EC">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-bindins-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">The HTTP Binding Extension</a><br> 6.6.1 <a href="#N10B28">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.1.2 <a href="#adv-scope-of-wsdl-required">Scoping of the wsdl:required Attribute</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-import-and-authoring">Import mechanism and authoring stye</a><br> 7.4 <a href="#adv-multiple-docs-describing-same-service">Multiple Interfaces for the Same Service</a><br> 7.5 <a href="#adv-versioning">Web Service Versioning</a><br> 7.5.1 <a href="#adv-versioning-compatible-evolution">Compatible Evolution</a><br> 7.5.2 <a href="#adv-versioning-big-bang">Big Bang</a><br> 7.5.3 <a href="#adv-versioning-combined">Combined Approaches</a><br> 7.6 <a href="#adv-MTOM">MTOM Support</a><br> 7.7 <a href="#adv-RPCstyle">RPC Style</a><br> 7.8 <a href="#adv-message-dispatch">Enabling Easy Message Dispatch</a><br> 7.9 <a href="#adv-service-references">Service References</a><br> 7.9.1 <a href="#reservationDetails">The Reservation Details Web Service</a><br>nbsp; 7.9.2 <a href="#reservationList">The Reservation List Web Service</a><br> 7.9.3 <a href="#reservationDetails_HTTP">Reservation Details Web Service Using HTTP Transfer</a><br> 7.9.4 <a href="#reservationList_HTTP_GET">Reservation List Web Service Using HTTP GET</a><br> 7.10 <a href="#adv-multiple-inline-schemas">Importing Schemas</a><br> 7.10.1 <a href="#N11037">Schemas in Imported Documents</a><br> 7.10.2 <a href="#N110C2">Multiple Inline Schemas in One Document</a><br> 7.10.3 <a href="#adv-schema-location">The schemaLocation Attribute</a><br> 7.10.3.1 <a href="#N1111F">Using the id Attribute to Identify Inline
Schemas</a><br> 7.11 <a href="#adv-rdf-mapping">Mapping to RDF and Semantic Web</a><br> 7.11.1 <a href="#adv-rdf-rep-wsdl">RDF Representation of WSDL 2.0</a><br> 7.12 <a href="#adv-notes-on-uris">Notes on URIs</a><br> 7.12.1 <a href="#adv-namespaces-and-schema-locations">XML Namespaces and Schema Locations</a><br> 7.12.2 <a href="#adv-relative-uris">Relative URIs</a><br> 7.12.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></div><hr><div class="body">
--- 94,99 ----
<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></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 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="#basics-nterface">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> 3. <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-embed">Embedding 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-op-att">Operation Attributes</a><br> 5.4.2 <a href="#N1089A">Operation Message References</a><br> 5.4.2.1 <a href="#N108B7">The messageLabel Attribute</a><br> 5.4.2.2 <a href="#N108CB">The element Attribute</a><br> 5.4.2.3 <a href="#N108F2">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-bindins-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">The HTTP Binding Extension</a><br> 6.6.1 <a href="#N10AB6">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.1.2 <a href="#adv-scope-of-wsdl-required">Scoping of the wsdl:required Attribute</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-import-and-authoring">Import mechanism and authoring stye</a><br> 7.4 <a href="#adv-multiple-docs-describing-same-service">Multiple Interfaces for the Same Service</a><br> 7.5 <a href="#adv-versioning">Web Service Versioning</a><br> 7.5.1 <a href="#adv-versioning-compatible-evolution">Compatible Evolution</a><br> 7.5.2 <a href="#adv-versioning-big-bang">Big Bang</a><br> 7.5.3 <a href="#adv-versioning-combined">Combined Approaches</a><br> 7.6 <a href="#adv-MTOM">MTOM Support</a><br> 7.7 <a href="#adv-RPCstyle">RPC Style</a><br> 7.8 <a href="#adv-message-dispatch">Enabling Easy Message Dispatch</a><br> 7.9 <a href="#adv-service-references">Service References</a><br> 7.9.1 <a href="#reservationDetails">The Reservation Details Web Service</a><br>nbsp; 7.9.2 <a href="#reservationList">The Reservation List Web Service</a><br> 7.9.3 <a href="#reservationDetails_HTTP">Reservation Details Web Service Using HTTP Transfer</a><br> 7.9.4 <a href="#reservationList_HTTP_GET">Reservation List Web Service Using HTTP GET</a><br> 7.10 <a href="#adv-multiple-inline-schemas">Importing Schemas</a><br> 7.10.1 <a href="#N10FC6">Schemas in Imported Documents</a><br> 7.10.2 <a href="#N11051">Multiple Inline Schemas in One Document</a><br> 7.10.3 <a href="#adv-schema-location">The schemaLocation Attribute</a><br> 7.10.3.1 <a href="#N110AE">Using the id Attribute to Identify Inline
Schemas</a><br> 7.11 <a href="#adv-rdf-mapping">Mapping to RDF and Semantic Web</a><br> 7.11.1 <a href="#adv-rdf-rep-wsdl">RDF Representation of WSDL 2.0</a><br> 7.12 <a href="#adv-notes-on-uris">Notes on URIs</a><br> 7.12.1 <a href="#adv-namespaces-and-schema-locations">XML Namespaces and Schema Locations</a><br> 7.12.2 <a href="#adv-relative-uris">Relative URIs</a><br> 7.12.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></div><hr><div class="body">
***************
*** 136,139 ****
--- 136,141 ----
</div>
+
+
<div class="div1">
***************
*** 515,518 ****
--- 517,523 ----
<h4><a name="example-initial-documentation-explanation"></a>2.7.1 Explanation of Example</h4><dl><dt class="label"><code><documentation></code></dt><dd><p> This element is optional, but a good idea to include. It can contain arbitrary mixed content. </p></dd><dt class="label"><code>at http://greath.example.com/2004/reservation-documentation.html</code></dt><dd><p>The most important thing to include is a pointer to any additional documentation that a client developer would need in order to use the service. </p></dd></dl><p>This completes our presentation of the GreatH example. </p></div></div>
</div>
+
+
+
<div class="div1">
***************
*** 629,636 ****
<div class="div1">
<h2><a name="more-types"></a>4. More on Message Types</h2>
-
-
<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="http://www.w3.org/TR/wsdl20-primer#other-schemalang">Examples of Specifications of Extension Elements for Alternative Schema Language Support. (Non-Normative)</a>".
--- 634,642 ----
+
+
+
<div class="div1">
<h2><a name="more-types"></a>4. More on Message Types</h2>
<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="http://www.w3.org/TR/wsdl20-primer#other-schemalang">Examples of Specifications of Extension Elements for Alternative Schema Language Support. (Non-Normative)</a>".
***************
*** 841,845 ****
<h3><a name="more-interfaces-operations"></a>5.4 Interface Operations</h3>
! <p>As shown earlier, the <code>operation</code> element is used to indicate an operation supported by the containing interface. It associates message schemas with a message exchange pattern (MEP), in order abstractly describe a simple interaction with a Web service. </p>
--- 847,851 ----
<h3><a name="more-interfaces-operations"></a>5.4 Interface Operations</h3>
! <p>As shown earlier, the <code>operation</code> element is used to indicate an operation supported by the containing interface. It associates message schemas with a message exchange pattern (MEP), in order to abstractly describe a simple interaction with a Web service. </p>
***************
*** 866,875 ****
</li>
</ul></div><div class="div3">
! <h4><a name="N10894"></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="N108B1"></a>5.4.2.1 The messageLabel Attribute</h5><p>The <code>messageLabel</code> attribute of the <code>input</code> and <code>output</code> elements is optional: it is not necessary to explicitly set the <code>messageLabel</code> when the MEP in use is one of the eight MEPs predefined in WSDL 2.0 Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] and it has only one message with a given direction. </p></div><div class="div4">
! <h5><a name="N108C5"></a>5.4.2.2 The element Attribute</h5><p>The <code>element</code> attribute of the <code>input</code> and <code>output</code> elements is used to specify the message content schema (a/k/a payload schema) when the content model is defined using XML Schema. As we have seen already, it can specify the QName of an element schema that was defined in the <code>types</code> section. However, alternatively it can specify one of the following tokens: </p><dl><dt class="label"><code>#any</code></dt><dd><p>The message content is any single element.</p></dd><dt class="label"><code>#none</code></dt><dd><p>There is no message content, i.e., the message payload is empty.</p></dd></dl><p>The <code>element</code> attribute is also optional. If it is not specified, then @@@@. <table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">ToDo: ay what happens if the element attribute is not specified, after issue LC99 is resolved. See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC99 </td></tr></table></p></div><div class="div4">
! <h5><a name="N108EC"></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>
!
--- 872,880 ----
</li>
</ul></div><div class="div3">
! <h4><a name="N1089A"></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="N108B7"></a>5.4.2.1 The messageLabel Attribute</h5><p>The <code>messageLabel</code> attribute of the <code>input</code> and <code>output</code> elements is optional: it is not necessary to explicitly set the <code>messageLabel</code> when the MEP in use is one of the eight MEPs predefined in WSDL 2.0 Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] and it has only one message with a given direction. </p></div><div class="div4">
! <h5><a name="N108CB"></a>5.4.2.2 The element Attribute</h5><p>The <code>element</code> attribute of the <code>input</code> and <code>output</code> elements is used to specify the message content schema (a/k/a payload schema) when the content model is defined using XML Schema. As we have seen already, it can specify the QName of an element schema that was defined in the <code>types</code> section. However, alternatively it can specify one of the following tokens: </p><dl><dt class="label"><code>#any</code></dt><dd><p>The message content is any single element.</p></dd><dt class="label"><code>#none</code></dt><dd><p>There is no message content, i.e., the message payload is empty.</p></dd></dl><p>The <code>element</code> attribute is also optional. If it is not specified, then @@@@. <table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">ToDo: ay what happens if the element attribute is not specified, after issue LC99 is resolved. See http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC99 </td></tr></table></p></div><div class="div4">
! <h5><a name="N108F2"></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>
***************
*** 878,942 ****
<h4><a 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 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
! nodes. By some prior agreement, another node and/or the service may send other
! messages (to each other or to other nodes) that are not described by the
MEP. For instance, even though an MEP may define a single message sent
! from a service to one other node, the Web Service may multicast that message to
! other nodes. To maximize reuse, WSDL message exchange patterns identify a minimal contract between other parties and Web Services, and contain only information that is
! relevant to both the Web service and the client that engages that service.</p>
! <p>A total of 8 MEPs are defined in WSDL 2.0 Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]. Hopefully, these MEPs will cover the most common use cases, but they are not meant to be an exhaustive list of MEPs that can ever be used by operations. More MEPs can be defined for particular application needs by interested parties. (See <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"> </td></tr><tr><td valign="top" align="left" colspan="2">Add info about how to define a new MEP?</td></tr></table></p>
! <p>For the 8 MEPs defined by WSDL 2.0, some of them are variations of others based on how faults may be generated. Three common fault generation models are specified. </p><dl><dt class="label">Fault Replaces Message</dt><dd><p>Any message after the first in the pattern MAY be replaced with a fault message, which MUST have identical cardinality and direction. The fault message MUST be delivered to the same target node as the message it replaces. </p></dd><dt class="label">Message Triggers Fault</dt><dd><p>Any message, including the first, MAY trigger a fault message in response. Each recipient MAY generate a fault message, and MUST generate no more than one fault for each triggering message. Each fault message has direction the reverse of its triggering message. The fault message MUST be delivered to the originator of the message which triggered it. If there is no path to this node, the fault MUST be discarded. In the third case, no fault may be generated in the MEP. </p></dd><dt class="label">No Fauls</dt><dd><p>No faults will be delivered.</p></dd></dl><p></p>
! <p>Now let's have a look of each of the 8 MEPs. Depends on how the first message in the MEP is initiated, we can probably group the MEPs into in-bound MEPs in which case the service receives the first message in the exchange, and out-bound MEPs in which case the service sends out the first message in the exchange. Such Grouping is only for the purpose of easy reference from discussions in later sections of this primer. WSDL 2.0 defines four in-bound MEPS:</p>
! <table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">ToDo: Check/update the MEP URIs prior to final publication.</td></tr></table><ul>
! <li>
! <p>
! <b>In-Only</b> ("http://www.w3.org/2004/03/wsdl/in-only")</p>
! <p>This patten consists of exactly one message received by a service from some other node. No fault maybe generated. </p>
! </li>
! <li>
! <p>
! <b>Robust In-Only</b> ("http://www.w3.org/2004/03/wsdl/robust-in-only")</p>
! <p>This pattern can be considered as a variation of In-only. It also consists of exactly one message received by a service, but in this case faults can be triggered by the message as specified in the "Message Triggers Fault" model. </p>
! </li>
! <li>
! <p>
! <b>In-Out</b> ("http://www.w3.org/2004/03/wsdl/in-out")</p>
! <p>This patten consists of exactly two message: a message received by a service from some other node, followed by a message sent to the other node. The second message may be replaced by a fault as specified in the "Fault Replace Message" model. </p>
! </li>
! <li>
! <p>
! <b>In-Optional-Out</b> ("http://www.w3.org/2004/03/wsdl/in-opt-out")</p>
! <p>This patten consists of one or two messages: a message received by a service from some other node, optionally followed by a message sent to the other node from the service. Each message may trigger a fault in response as specified in the "Message Triggers Faults" model. </p>
! </li>
! </ul>
! <p>WSDL 2.0 also defines four out-bound MEPs which sort of mirror the in-bound MEPs with reserved direction:</p>
! <ul>
! <li>
! <p>
! <b>Out-Only</b> ("http://www.w3.org/2004/03/wsdl/out-only")</p>
! <p>This patten consists of exactly one message sent to some other node from a service. No fault maybe generated. </p>
! </li>
! <li>
! <p>
! <b>Robust Out-Only</b> ("http://www.w3.org/2004/03/wsdl/robust-out-only")</p>
! <p>This pattern can be considered as a variation of Out-only. It also consists of exactly one message sent to some other node from a service, but in this case faults can be triggered by the message as specified in the "Message Triggers Fault" model. </p>
! </li>
! <li>
! <p>
! <b>Out-in</b> ("http://www.w3.org/2004/03/wsdl/out-in")</p>
! <p>This patten consists of exactly two message: a message sent to some other node from a service, followed by a message received by the service from the other node. The second message may be replaced by a fault as specified in the "Fault Replace Message" model. </p>
! </li>
! <li>
! <p>
! <b>Out-Optional-In</b> ("http://www.w3.org/2004/03/wsdl/out-opt-in")</p>
! <p>This patten consists of one or two messages: a message sent to some other node from a service, optionally followed by a message received by the service from the other node. Each message may trigger a fault in response as specified in the "Message Triggers Faults" model. </p>
! </li>
! </ul>
! <p>While the in-bound MEPs are easier to understand, there have been questions concerning the usefulness of out-bound MEPs, especially how a service can specify the endpoint information for the target node of the initial out-bound message. In their typical use cases, such as in large scale intergration projects where endpoint information is most likely specified at deployment or runtime by mapping and routing facilities, or/and in languages that facilitate services composition where only abstract interfaces are concerned, Out-bound MEPs are useful in the abstract level for fully specifying the functionality of a service, including its requirements for its potential customers, so application integrator can gain a better understanding of how multiple services may be used together, whereas binding and endpoint information may be provided by integration infrastructure in application deployment and runtime.</p>
! <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">20040910</td></tr><tr><td valign="top" align="left" colspan="2">
! Add more MEP use cases and example - illustrate use of outbound meps?
!
! </td></tr></table>
</div>
--- 883,916 ----
<h4><a 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 sequence and cardinality of the abstract messages in an operation. By design, WSDL 2.0 MEPs are abstract. First of all, they abstract out specific message types. MEPs identify placeholders for messages, and placeholders are associated with specific message types when an operation is defined, which includes specifying which MEP to use for that operation. Secondly, unless explicitly stated otherwise, MEPs also abstract out binding-specific information like timing between messages, whether the pattern is synchronous or asynchronous, and whether the messages are sent over a single or multiple channels.</p>
! <p>It's worth pointing out that WSDL MEPs do not exhaustively describe the set of messages that may be exchanged between a service and other nodes. By some prior agreement, another node and/or the service may send other messages (to each other or to other nodes) that are not described by the
MEP. For instance, even though an MEP may define a single message sent
! from a service to one other node, a service defined by that MEP may multicast that message to
! other nodes. To maximize reuse, WSDL message exchange patterns identify a minimal contract between other parties and Web Services, and contain only information that is relevant to both the Web service and the client that engages that service.</p>
! <p>A total of 8 MEPs are defined in [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]. Hopefully, these MEPs will cover the most common use cases, but they are not meant to be an exhaustive list of MEPs that can ever be used by operations. More MEPs can be defined for particular application needs by interested parties. (See <a href="#more-interfaces-defining-meps"><b>5.4.4 Defining New Message Exchange Patterns (MEPs)</b></a> )</p>
! <p>For the 8 MEPs defined by WSDL 2.0, some of them are variations of others based on how faults may be generated. For example, the In-Only pattern ("http://www.w3.org/@@@@/@@/wsdl/in-only") consists of exactly one message received by a service from some other node. No fault maybe generated. As a variation of In-Only, Robust In-Only pattern ("http://www.w3.org/@@@@/@@/wsdl/robust-in-only") also consists of exactly one message received by a service, but in this case faults can be triggered by the message and MUST be delivered to the originator of the message. If there is no path to this node, the fault MUST be discarded. For details about the common fault generation models used by the 8 WSDL 2.0 MEPs, see [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]. </p>
+ <p>Depends on how the first message in the MEP is initiated, the 8 WSDL MEPs may be grouped into two groups: in-bound MEPs in which case the service receives the first message in the exchange, and out-bound MEPs in which case the service sends out the first message in the exchange. (Such Grouping is only for the purpose of easy reference in this primer).</p>
+
+ <p> A frequently asked question about out-bound MEPs is how a service knows where to send the message. Services using out-bound MEPs are typically part of large scale intergration systems that rely on mapping and routing facilities. In such systems, out-bound MEPs are useful for abstractly specifing the functionality of a service, including its requirements for potential customers, while endpoint address information can be provided at deployment or runtime by integration infrastructure. For example, the GreatH hotel reservation system may require that everytime a customer interacts with the system to check availability, data about the customer must be logged by a CRM system. At design time, it's unknown which particular CRM system would be used together with the reservation system. To address this requirement, we may change the "reservationInterface" in <a href="#example-initial">Example 2-1</a> to include an out-bound logInquiry operation. This logInquiry operation advertises to potential service clents that customer data will be made available by the reservation service at run time. When the reservation service is deployed to GreatH's IT landscape, appropriate configuration time and run time infrastructure will help determine which CRM system will get the customer data and log it appropriately. It's worth noting that in addition to being used by a CRM system for customer management purpose, the same data may also be used by a system performance analysis tool for different purpose. Providing an out-bound operation in the reservation service enables loose coupling and so improves the overall GreatH IT landscape's flexbility and scalability. </p>
+
+ <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>
+
+ <description ...>
+ ...
+ <interface name="reservationInterface">
+ ...
+ <operation name="opCheckAvailability" ... >
+
+ <operation name="opLogInquiry"
+ <b>pattern="http://www.w3.org/@@@@/@@/wsdl/out"</b>>
+ <<b>output messageLabel="Out" element="ghns:customerData"</b> />
+ </operation>
+
+ </interface>
+ ...
+ </description></pre></div>
+ </div>
</div>
***************
*** 957,962 ****
provides a well-defined convention for naming and reusing them.</p></div></div>
</div>
!
!
<div class="div1">
--- 931,937 ----
provides a well-defined convention for naming and reusing them.</p></div></div>
</div>
!
!
!
<div class="div1">
***************
*** 1099,1108 ****
-
-
-
-
-
-
<div class="div3">
--- 1074,1077 ----
***************
*** 1145,1149 ****
</div>
<div class="div3">
! <h4><a name="N10B28"></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/@@@@/@@/wsdl/http"</code></dt>
--- 1114,1118 ----
</div>
<div class="div3">
! <h4><a name="N10AB6"></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/@@@@/@@/wsdl/http"</code></dt>
***************
*** 1155,1167 ****
<dt class="label"><code>xmlns:whttp="http://www.w3.org/@@@@/@@/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>
--- 1124,1131 ----
<dt class="label"><code>xmlns:whttp="http://www.w3.org/@@@@/@@/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>
***************
*** 1183,1188 ****
!
!
<div class="div1">
--- 1147,1152 ----
!
!
<div class="div1">
***************
*** 2373,2377 ****
<div class="div3">
! <h4><a name="N11037"></a>7.10.1 Schemas in Imported Documents</h4>
<p>
In this example, we consider some GreatH Hotel
--- 2337,2341 ----
<div class="div3">
! <h4><a name="N10FC6"></a>7.10.1 Schemas in Imported Documents</h4>
<p>
In this example, we consider some GreatH Hotel
***************
*** 2580,2584 ****
<div class="div3">
! <h4><a name="N110C2"></a>7.10.2 Multiple Inline Schemas in One Document</h4>
<p>
A WSDL 2.0 document may define multiple inline
--- 2544,2548 ----
<div class="div3">
! <h4><a name="N11051"></a>7.10.2 Multiple Inline Schemas in One Document</h4>
<p>
A WSDL 2.0 document may define multiple inline
***************
*** 2714,2718 ****
the <code>schema</code> element. The simplest way to accomplish this is to use the <code>id</code> attribute, however XPointer can also be used.
</p><div class="div4">
! <h5><a name="N1111F"></a>7.10.3.1 Using the id Attribute to Identify Inline
Schemas</h5><p>
<a href="#schemaIds.wsdl">Example 7-26</a>
--- 2678,2682 ----
the <code>schema</code> element. The simplest way to accomplish this is to use the <code>id</code> attribute, however XPointer can also be used.
</p><div class="div4">
! <h5><a name="N110AE"></a>7.10.3.1 Using the id Attribute to Identify Inline
Schemas</h5><p>
<a href="#schemaIds.wsdl">Example 7-26</a>
Received on Wednesday, 27 April 2005 23:28:00 UTC