- From: David Booth <dbooth@dev.w3.org>
- Date: Tue, 14 Sep 2004 03:39:09 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/wsdl20
In directory hutz:/tmp/cvs-serv23033
Modified Files:
wsdl20-primer.xml wsdl20-primer.html
Log Message:
Extensive structure and presentation edits from sections 1 through 3.1.
Index: wsdl20-primer.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** wsdl20-primer.xml 10 Sep 2004 07:36:40 -0000 1.11
--- wsdl20-primer.xml 14 Sep 2004 03:39:05 -0000 1.12
***************
*** 39,44 ****
</authlist>
<abstract id="Abstract">
! <p>This document introduces the Web Services Description Language, version 2.0 (WSDL 2.0). It is intended as a non-normative companion to the official WSDL 2.0 specification, for readers who wish to have an easier, less technical introduction to the main features of the language than the official specification provides. </p>
! <p>This primer is non-normative. Any specific questions of what WSDL 2.0 requires or forbids should be referred to the WSDL 2.0 specification (@@reference@@).</p>
</abstract>
&status;
--- 39,44 ----
</authlist>
<abstract id="Abstract">
! <p>This document introduces the Web Services Description Language, version 2.0 (WSDL 2.0). It is intended as a companion to the official WSDL 2.0 specification, for readers who wish to have an easier, less technical introduction to the main features of the language than the official specification provides. </p>
! <p>This primer is <emph>non-normative</emph>. Any specific questions of what WSDL 2.0 requires or forbids should be referred to the WSDL 2.0 specification (@@reference@@).</p>
</abstract>
&status;
***************
*** 61,74 ****
</item>
</ulist>
! </p>
! <p>No previous experience with Web service descriptions is assumed.</p></div2>
<div2 id="PrimerStructure">
<head>Structure of the Primer</head>
! <p>In the following sections, We will cover various aspects of the WSDL language.</p>
! <p>Section 2 provides an introduction about defining abstract interface. Start with explaining how messages are defined using XML Schema and get used by WSDL, it moves on to examine the details of the interface construct. </p>
! <p>Section 3 explains how to bind an abstract interface to concrete transport protocols. It first introduce the WSDL binding constructs, and then explains the binding extensions defined by WSDL2.0 part 3, including bindings for SOAP1.2, SOAP1.1 and HTTP.</p>
<p>Section 4 covers service endpoint definitions.</p>
! <p>Section 5 covers advanced topics, including features and properties,flexible authoring styles, service references, use of URIs, etc. </p>
! <p>Through out this primer, We employ a hypothetical hotel reservation service to help explain WSDL2.0 constructs. We start with a simple scenario, and add more requirments gradually to illustrate how more advanced WSDL2.0 features may be used. Hotel GreatH is located in a remote island. It has been relying on old fasion communication mechanisms such as fax and phone to provide room reservations. Recently, the island has become a popular tourism destination. Though over years it has built up a small customer base, GreatH notices that its competitors are getting more customers though their facilities and prices are not as attractive as what GreatH provides. After some research, it finds out the secret is that its competitors provide some Web services which allow making reservations via Internet! GreatH hires Mr. Joe Somebody as their Web services architect to build a reservation Web service, and provide him with a list of requirements to start with. The service must be accessible by travel agents via heir booking systems and directly by customers via GreatH's website site or emails. To check availability, a user must provide a check-in date, a check-out date, and specifies the type of room, and the Web service will provide the room rate if any desired room is available. To make a reservation, a user must provide a name, address, and credit card information, and the service will return a confirmation number if the reservation is sucessful. The service will return an error message if the credit card number is wrong or any data field is invalid. Joe knows that to provide the service, he needs to build the complete system which supports transaction and secured transmission, but as the first step, he decides to design the Web service and describe it using WSDL2.0. To start, Joe decides that he wants to use "http://www.greath.com/2004/05/wsdl/reservationService.wsdl" as the <att> target namespace</att> of his WSDL definitioin. It's an absolute URI and allows him to make the WSDL file available from GreatH's wbsite.</p>
</div2><div2 id="notation">
<head>Notational Conventions</head>
--- 61,73 ----
</item>
</ulist>
! No previous experience with Web service descriptions is assumed.</p></div2>
<div2 id="PrimerStructure">
<head>Structure of the Primer</head>
! <p>In the following sections, We will cover various aspects of the WSDL 2.0 language.</p>
! <p>Section 2 explains how an abstract interface is described in WSDL 2.0. It first explains how messages are defined using XML Schema and get used by WSDL 2.0; it then moves on to examine the details of the interface construct. </p>
! <p>Section 3 explains how to bind an abstract interface to concrete transport protocols. It first introduces the WSDL 2.0 binding constructs, and then explains the binding extensions defined by @WSDL2.0 part 3@, including bindings for SOAP 1.2, SOAP 1.1 and HTTP.</p>
<p>Section 4 covers service endpoint definitions.</p>
! <p>Section 5 covers advanced topics, including features and properties, flexible authoring styles, service references, use of URIs, etc. </p>
!
</div2><div2 id="notation">
<head>Notational Conventions</head>
***************
*** 80,84 ****
any namespace prefix is arbitrary and not semantically significant
(see <bibref ref="XMLInfoSet"/>).</p>
! <table border="1" summary="Mapping of prefixes used in this document to their
associated namespace name" id="tabnsprefixes">
<caption>Prefixes and Namespaces used in this primer</caption>
--- 79,83 ----
any namespace prefix is arbitrary and not semantically significant
(see <bibref ref="XMLInfoSet"/>).</p>
! <ednote><edtext>dbooth asks: Should we keep this table here? It duplicates what is in the spec. Maybe it would be better to introduce these as we go.</edtext></ednote><table border="1" summary="Mapping of prefixes used in this document to their
associated namespace name" id="tabnsprefixes">
<caption>Prefixes and Namespaces used in this primer</caption>
***************
*** 160,189 ****
<!-- ******************************************************* -->
<div1 id="IntroductionWS">
! <head>Introduction to Web Service Descriptions</head>
! <p>This section provides a conceptual introduction to WSDL 2.0. Its purpose is twofold:
! <ulist>
! <item><p>to introduce concepts and define terms that are used elsewhere; and</p></item>
! <item><p>to provide the "big picture" context for WSDL 2.0, so that the reader has a
! clearer understanding of what WSDL 2.0 is and isn't.</p></item>
! </ulist>
</p>
<div2 id="Web_Service_Descriptions">
! <head>Web Service Descriptions</head>
! <p>WSDL 2.0 is a language for writing <emph>Web service descriptions</emph> (WSDs). A WSD is an XML document that describes the mechanics of interacting with a particular Web service. It represents a take-it-or-leave-it "contract" that governs the interaction between a <xspecref href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#reqpro">requester agent</xspecref> and <xspecref href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#reqpro">provider agent</xspecref>. Of course, this "contract" is only partial because in general it only describes the <emph>mechanics</emph> of the interaction -- not the intended semantics. Description of the application semantics is outside the scope of WSDL 2.0.</p><p>In some cases, the WSD is created before the provider agent is realized; in other cases the WSD is created at the same time or after the provider agent is realized. Although the provider agent must faithfully implement the WSD, WSDL 2.0 makes no requirement about which is created first, and bot approaches are useful.</p>
! <p>Although a WSD is written solely from the point of view of the Web service (or provider agent), it is inherently intended to constrain <emph>both</emph> the provider agent that offers the service <emph>and</emph> the requester agent that makes use of that service. It is concerned only with information that <emph>both</emph> parties must agree upon -- not information that is relevant only to one party or the other, such as internal implementation details.</p>
<graphic source="images/requester-provider.gif" alt="WSD governing interaction between a requester agent and provider agent"/>
! </div2>
<div2 id="overview">
! <head>Overview of WSDL 2.0</head>
! <p>WSDL 2.0 enables one to separate the description of a service's abstract functionality from concrete details of how and where that functionality is offered.</p>
! <p>An interface describes what a Web service is. The abstract functionality of a service is described in terms of the messages it sends and receives. Messages are described independent of any specific wire format using a type system, typically XML schema. A message exchange pattern defines the sequence and cardinality of the abstract messages a service exchanges with its clients. A binding describes how to access a Web service. It specifies transport and wire format details for one or more interfaces. A service endpoint describes where to access a service. It associates a concrete network address with a binding of an interface.</p>
! <p>This layering of interface, binding and service endpoint facilitates different levels of reusability and distribution of work in different stages of the lifecycle of a service. As one typical use case, an interface describes the functionality and supported features of a service, and is used at design time. It has the highest level of reusability, and should be abstract and reusable for different bindings; A binding is used at configuration time. It provides transport protocol specific information about how to access a service, and should be reusable by different endpoints. An endpoint provides concrete location of a service, and is used at run time. It's most concrete, specific to a particular instance of a service, and not reusable. </p>
! <div3 id="syntax">
! <head>XML Syntax Summary</head>
! <p>In the core language specification, WSDL constructs are defined as a set of abstract components, along with a mapping to an XML infoset representation for these components. For easier consumption, the primer uses the XML representation of WSDL components and the XML syntax as summarized below to illustrate the language. The following conventions are followed for the syntax: </p>
<ulist>
<item>
--- 159,188 ----
<!-- ******************************************************* -->
<div1 id="IntroductionWS">
! <head>WSDL 2.0: The Big Picture</head>
! <p>This section provides a big picture overview of WSDL 2.0 and its main concepts. Its purpose is to introduce concepts and terms that are used throughout the rest of this primer and in the @WSDL 2.0 specification@.
</p>
<div2 id="Web_Service_Descriptions">
! <head>What Is a WSDL 2.0 Web Service Description (WSD)?</head>
! <p>A WSDL 2.0 <emph>Web service description</emph> (WSD) is an XML document that describes the mechanics of interacting with a particular Web service. Although a WSD is written solely from the point of view of the Web service (or the <xspecref href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#reqpro">provider agent</xspecref> that realizes that service), it is inherently intended to constrain <emph>both</emph> the provider agent <emph>and</emph> the <xspecref href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#reqpro">requester agent</xspecref> that makes use of that service. The WSD is therefore concerned only with information that <emph>both</emph> parties must agree upon -- not information that is relevant only to one party or the other, such as internal implementation details. It represents a take-it-or-leave-it "contract" that governs the interaction between requester agent and provider agent. Of course, this "contract" is only partial because in general it only describes the <eph>mechanics</emph> of the interaction -- not the intended semantics. Description of the application semantics is outside the scope of WSDL 2.0.</p><p>In some cases, the WSD is created before the provider agent is realized, and the provider agent is then created to conform to the WSD. In other cases the WSD is created at the same time or after the provider agent has been created. Although the provider agent must faithfully implement the WSD, WSDL 2.0 makes no requirement about which is created first. Both approaches are useful in different situations.</p>
! <p></p>
<graphic source="images/requester-provider.gif" alt="WSD governing interaction between a requester agent and provider agent"/>
! <div3 id="scope">
! <head>WSDL 2.0 Scope: Individual Web Services</head>
! <p>WSDL 2.0 is limited to the description of individual Web services from a service provider's viewpoint -- not combinations of Web services. WSDL 2.0's extensibility and composability with other Web services specifications makes it an essential building block for a complete solution, but WSDL itself does not provide the complete solution for building real world Web services. For example, several individual Web services can be composed to provide more complex functionalities which may involve process definition, transaction management, state mangement, and reliable messaging. Though WSDL does not preclude the description of such composition of individual services, the way two or more services could be composed is considered out of scope of WSDL.</p>
! </div3></div2><div2><head>Major Elements of a Web Service Description (WSD)</head><p>WSDL 2.0 enables you to separate the description of a Web service's abstract functionality from the concrete details of how and where that functionality is offered. WSDL 2.0 divides a WSD into the following major elements:<ulist><item><p>Message <emph>types</emph> describe the kinds of messages that a Web service may send or receive. Message types are defined using a schema language -- typically XML Schema -- independent of any specific wire format. </p></item><item><p>An <emph>interface</emph> describes the abstract functionality of the Web service in terms of the types of messages it sends and receives. An interface consists of a set of operations. </p></item><item><p>An <emph>operation</emph> describes a sequence of messages that may be exchanged with the Web service. It associates a message exchange pattern (MEP) with the message types that will be exchanged in that operation. (For example, the in-out ME specifies that if a provider agent sends a message <emph>in</emph> to the Web service, the Web services will either send a reply message back <emph>out</emph> to the provider agent, or it will send a fault message back to the provider agent.) </p></item><item><p>A <emph>binding</emph> describes how to access a Web service. It specifies transport and wire format details for one or more interfaces. </p></item><item><p>A WSDL 2.0 <emph>service</emph> lists the locations where the described Web service can be accessed. A service consists of a list of endpoints.</p></item><item><p>A service <emph>endpoint</emph> describes where to access a service via a particular transport protocol and wire format. It associates a concrete network address with a binding of an interface.</p></item></ulist></p>
!
! <p>This layering of message type, interface, operation, binding, service and endpoint facilitates different levels of reusability and distribution of work in different stages of the lifecycle of a Web service. For example, an interface describes the functionality and supported features of a service, and is used at design time. It has the highest level of reusability, and should be abstract and reusable for different bindings. A binding is used at configuration time. It provides transport protocol specific information about how to access a service, and should be reusable by different endpoints. An endpoint provides concrete location of a service, and is used at run time. The endpoint is the most concrete element, specific to a particular instance of a service, and is therefore not reusable. </p></div2>
<div2 id="overview">
! <head>WSDL 2.0 Extensibility</head>
!
! <p>WSDL 2.0 offers two mechanisms for extensibility: an open content model; and Features and Properties.<ulist><item><p>@@ TODO: Reduce the amount of detail in the next paragraph. It is too much detail for this overview section.@@</p><p>WSDL 2.0's <emph>open content model</emph> allows XML elements from non-WSDL namespaces to be intermingled with WSDL constructs in a WSD. As specified in section 6 of Part1, WSDL allows extensions to be defined in terms of both elements and attributes. Namespace-qualified elements
! whose namespace is NOT "http://www.w3.org/2004/03/wsdl" (i.e., non-WSDL elements) may appear among the children of specific elements whose [namespace name] is "http://www.w3.org/2004/03/wsdl" (i.e., WSDL elements). Also, WSDL allows qualified attributes whose namespace is NOT "http://www.w3.org/2004/03/wsdl" (i.e., non-WSDL attributes) to appear on any elements whose namespace is "http://www.w3.org/2004/03/wsdl" (i.e., WSDL elements). See more about extensibility in section@@@@. Since extensions can appear anywhere, they are not explicitly indicated in the above syntax and will not be mentioned again in later sections where a particular construct is explained. </p></item><item><p>WSDL 2.0's <emph>Features and Properties</emph> (F&P) mechanism provides another way to specify extensions in a WSD, and offers slightly more structure for extensions than the open content model offers. A WSDL 2.0 Feature allows a particular extension to be unambiguously identified by a URI. WSDL 2.0 Properties complement te notion of Features. Properties permit data values to be associated with Features. For example, a particular extension may require a parameter, and a Property may be used to indicate a value for that parameter.</p></item></ulist></p><p>@@ TODO: Explain optional and required extensions @@</p>
!
!
! </div2><div2><head>XML Syntax Summary</head><p>In the core language specification, WSDL 2.0 constructs are defined as a set of abstract components, along with a mapping to an XML infoset representation for these components. For easier consumption, the primer uses the XML representation of WSDL components and the XML syntax as summarized below to illustrate the language. The following conventions are followed for the syntax: </p>
<ulist>
<item>
***************
*** 198,202 ****
</ulist>
! <eg xml:space="preserve">
<definitions targetNamespace="<emph>xs:anyURI</emph>" >
<documentation />?
--- 197,201 ----
</ulist>
! <p>@@ TODO: Add an abridged version of this syntax overview, listing only the most important elements described above. @@</p><p>@@ TODO: Delete the <documentation> elements, because they're mentioned below. @@</p><eg xml:space="preserve">
<definitions targetNamespace="<emph>xs:anyURI</emph>" >
<documentation />?
***************
*** 336,351 ****
</eg>
! <p>As specified in section 6 of Part1, WSDL allows extensions to be defined in terms of both elements and attributes. Firstly, WSDL allows namespace-qualified elements
! whose namespace is NOT "http://www.w3.org/2004/03/wsdl" to appear among the children of specific elements whose [namespace name] is "http://www.w3.org/2004/03/wsdl". Secondly, WSDL allows qualified attributes whose namespace is NOT "http://www.w3.org/2004/03/wsdl" to appear on any elements whose namespace is "http://www.w3.org/2004/03/wsdl". See more about extensibility in section@@@@. Since extensions can appear in all the places, they are not explicitly indicated in the above syntax and will not be mentioned again in later sections where a particular construct is explained. </p>
! <p>An optional <el>documentation</el> element is allowed inside any WSDL elements as a container for human readable and/or machine processable documentation. The content of <el>documentation</el> is arbitrary characters and elements
! ("mixed" content in XML Schema ). </p>
! </div3>
! <div3 id="scope">
! <head>Scope</head>
! <p>It's important to note that the scope of WSDL2.0 is limited to the description of a single stateless Web service from a service provider's viewpoint. Its extensibility and composeability with other Web services specifications makes it an essential building block for a complete solution, but WSDL itself does not provide the complete solution for building real world application using Web services. For example, several individual Web services can be composed to provide more complex functionalities which may involve process definition, transaction management, state mangement, and reliable messaging. Though WSDL does not preclude the description of such composition of individual services, the way two or more services could be composed is considered out of scope of WSDL.</p>
! </div3>
! <div3 id="targetNS">
! <head>Target Namespace and Symbol Spaces</head>
! <p>All WSDL documents start with a <el>definitions</el> element. The <el>definitions</el> element has a required <att>targetNamespace</att> attribute and zero or more namespace declarations.The vaule of the <att>targetNamespace</att> must be an absolute URI which unambiguously identifies the set of related WSDL and data type constructs logically grouped by the <el>definitions</el> element. </p>
<p>We will talk about later the flexible authoring style enabled by the importing/including mechanism of WSDL, but it's worth pointing out now that at the component model level, there is no distinction between directly defined components vs. imported/included
components. The <att>targetNamespace</att> groups a set of related component definitions and represents an unambiguous name for the intended semantics of the components. The components directly defined within or included into a single Definitions component are
--- 335,341 ----
</eg>
!
! <p>An optional <el>documentation</el> element is also allowed inside any WSDL element as a container for human readable and/or machine processable documentation. The content of <el>documentation</el> is arbitrary characters and elements
! ("mixed" content in XML Schema ). </p><!-- ******* dbooth stopped here ***** --><!-- ************************ targetNamespace *************************** --><div3><head>Target Namespace and Symbol Spaces</head><p>All WSDL documents start with a <el>definitions</el> element. The <el>definitions</el> element has a required <att>targetNamespace</att> attribute and zero or more namespace declarations.The vaule of the <att>targetNamespace</att> must be an absolute URI which unambiguously identifies the set of related WSDL and data type constructs logically grouped by the <el>definitions</el> element. </p>
<p>We will talk about later the flexible authoring style enabled by the importing/including mechanism of WSDL, but it's worth pointing out now that at the component model level, there is no distinction between directly defined components vs. imported/included
components. The <att>targetNamespace</att> groups a set of related component definitions and represents an unambiguous name for the intended semantics of the components. The components directly defined within or included into a single Definitions component are
***************
*** 356,367 ****
element declarations, global attribute declarations, named model groups, named
attribute groups, type definitions and key constraints, as defined by XML Schema: Structures. Other type systems may
! define additional symbol spaces.</p>
! </div3>
! </div2></div1>
<!-- ******************Interface********************************** -->
<!-- ******************Interface********************************** -->
<div1 id="interface">
! <head>Defining Abstract Interface for a Web Service</head>
! <!-- ************************messages*************************** -->
<div2 id="messages">
<head>Defining Messages Using XML Schema</head>
--- 346,355 ----
element declarations, global attribute declarations, named model groups, named
attribute groups, type definitions and key constraints, as defined by XML Schema: Structures. Other type systems may
! define additional symbol spaces.</p></div3></div2></div1>
<!-- ******************Interface********************************** -->
<!-- ******************Interface********************************** -->
<div1 id="interface">
! <head>Defining an Abstract Interface for a Web Service</head>
! <!-- ************************ GreatH *************************** --><div2><head>Example: The GreatH Hotel Reservation Service</head><p>Throughout this primer, we employ a hypothetical hotel reservation service to help explain WSDL2.0 constructs. We start with a simple scenario, and add more requirements gradually to illustrate how more advanced WSDL2.0 features may be used. </p><p>Hotel GreatH is located in a remote island. It has been relying on fax and phone to provide room reservations, both to travel agents and to customers directly. Even though the facilities and prices at GreatH are better than what its competitor offers, GreatH notices that its competitor is getting more customers than GreatH. After research, GreatH realizes that this is because the competitor offers a Web service that permits travel agent reservation systems to reserve rooms directly over the Internet. GreatH then hires a Web services architect, Joe Somebody, to build a reservation Web service, and provides him with a list f requirements: <ulist><item><p>The service must be accessible by travel agents via their booking systems and directly by customers via GreatH's website site or email. </p></item><item><p>To check availability, a user must specify a check-in date, a check-out date, and room type room, and the Web service will provide the room rate if such a room is available. </p></item><item><p>To make a reservation, a user must provide a name, address, and credit card information, and the service will return a confirmation number if the reservation is sucessful. </p></item><item><p>The service will return an error message if the credit card number or any other data field is invalid.</p></item></ulist> Joe knows that he will later need to build the complete system which supports transactions and secured transmission. But as the first step, he decides to focus on the basic functionality so that he can begin testing and gain feedback from his customer, GreatH. He designs the Web service and describes it using WSDL 2.0. <p><p>To start, Joe decides that he wants to use "http:/greath.example.com/2004/05/wsdl/reservationService.wsdl" as the <att> target namespace</att> of his WSDL definition. It's an absolute URI and allows him to make the WSDL file available from GreatH's website.</p></div2><!-- ************************messages*************************** -->
<div2 id="messages">
<head>Defining Messages Using XML Schema</head>
***************
*** 474,480 ****
<date>20040517</date>
<edtext>
! <p>Add Example - illustrate use of xs:import and xs:include for embedded schema</p>
! <p>Clarification - what should be the "appropriate value" for schemalocation, especially when its's xs:include? </p>
</edtext>
</ednote>
--- 462,468 ----
<date>20040517</date>
<edtext>
! Add Example - illustrate use of xs:import and xs:include for embedded schema
! Clarification - what should be the "appropriate value" for schemalocation, especially when its's xs:include?
</edtext>
</ednote>
***************
*** 595,599 ****
<date>20040910</date>
<edtext>
! <p>Add more use cases and example - illustrate use of outbound meps</p>
</edtext>
--- 583,587 ----
<date>20040910</date>
<edtext>
! Add more use cases and example - illustrate use of outbound meps
</edtext>
***************
*** 688,692 ****
<date>20040910</date>
<edtext>
! <p>Add Example - illustrate use extends attribute</p>
</edtext>
</ednote>
--- 676,680 ----
<date>20040910</date>
<edtext>
! Add Example - illustrate use extends attribute
</edtext>
</ednote>
***************
*** 774,780 ****
<date>20040910</date>
<edtext>
! <p>Add Example and more text - illustrate use of RPC style</p>
! <p> </p>
</edtext>
</ednote>
--- 762,768 ----
<date>20040910</date>
<edtext>
! Add Example and more text - illustrate use of RPC style
!
</edtext>
</ednote>
Index: wsdl20-primer.html
===================================================================
RCS file: /sources/public/2002/ws/desc/wsdl20/wsdl20-primer.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** wsdl20-primer.html 13 Sep 2004 23:46:29 -0000 1.6
--- wsdl20-primer.html 14 Sep 2004 03:39:05 -0000 1.7
***************
*** 111,122 ****
<p>This document introduces the Web Services Description Language,
! version 2.0 (WSDL 2.0). It is intended as a non-normative companion
! to the official WSDL 2.0 specification, for readers who wish to
! have an easier, less technical introduction to the main features of
! the language than the official specification provides.</p>
! <p>This primer is non-normative. Any specific questions of what
! WSDL 2.0 requires or forbids should be referred to the WSDL 2.0
! specification (@@reference@@).</p>
</div>
--- 111,122 ----
<p>This document introduces the Web Services Description Language,
! version 2.0 (WSDL 2.0). It is intended as a companion to the
! official WSDL 2.0 specification, for readers who wish to have an
! easier, less technical introduction to the main features of the
! language than the official specification provides.</p>
! <p>This primer is <em>non-normative</em>. Any specific questions of
! what WSDL 2.0 requires or forbids should be referred to the WSDL
! 2.0 specification (@@reference@@).</p>
</div>
***************
*** 134,140 ****
<p class="toc">1. <a href="#Introduction">Introduction</a><br />
! 2. <a href="#IntroductionWS">Introduction to Web Service
! Descriptions</a><br />
! 3. <a href="#interface">Defining Abstract Interface for a Web
Service</a><br />
4. <a href="#binding">Binding Abstract Interface to Concrete
--- 134,139 ----
<p class="toc">1. <a href="#Introduction">Introduction</a><br />
! 2. <a href="#IntroductionWS">WSDL 2.0: The Big Picture</a><br />
! 3. <a href="#interface">Defining an Abstract Interface for a Web
Service</a><br />
4. <a href="#binding">Binding Abstract Interface to Concrete
***************
*** 158,190 ****
    1.3 <a href="#notation">Notational
Conventions</a><br />
! 2. <a href="#IntroductionWS">Introduction to Web Service
! Descriptions</a><br />
!     2.1 <a href="#Web_Service_Descriptions">Web
! Service Descriptions</a><br />
!     2.2 <a href="#overview">Overview of WSDL
! 2.0</a><br />
!         2.2.1 <a
! href="#syntax">XML Syntax Summary</a><br />
!         2.2.2 <a
! href="#scope">Scope</a><br />
!         2.2.3 <a
! href="#targetNS">Target Namespace and Symbol Spaces</a><br />
! 3. <a href="#interface">Defining Abstract Interface for a Web
Service</a><br />
!     3.1 <a href="#messages">Defining Messages
Using XML Schema</a><br />
!         3.1.1 <a
href="#import-xsd">Importing XML Schema</a><br />
!         3.1.2 <a
href="#embed-xsd">Embedding XML Schema</a><br />
!     3.2 <a href="#meps">Understanding Message
Exchange Patterns</a><br />
!     3.3 <a href="#interfaceEL">Defining
Interface</a><br />
!         3.3.1 <a
href="#extends">Interface Inheritance</a><br />
!         3.3.2 <a
href="#fault">Reusable Faults</a><br />
!         3.3.3 <a
href="#operations">Interface Operations</a><br />
4. <a href="#binding">Binding Abstract Interface to Concrete
--- 157,193 ----
    1.3 <a href="#notation">Notational
Conventions</a><br />
! 2. <a href="#IntroductionWS">WSDL 2.0: The Big Picture</a><br />
!     2.1 <a
! href="#Web_Service_Descriptions">What Is a WSDL 2.0 Web Service
! Description (WSD)?</a><br />
!         2.1.1 <a
! href="#scope">WSDL 2.0 Scope: Individual Web Services</a><br />
!     2.2 <a href="#id5185216">Major Elements of
! a Web Service Description (WSD)</a><br />
!     2.3 <a href="#overview">WSDL 2.0
! Extensibility</a><br />
!     2.4 <a href="#id5185502">XML Syntax
! Summary</a><br />
!         2.4.1 <a
! href="#id5194598">Target Namespace and Symbol Spaces</a><br />
! 3. <a href="#interface">Defining an Abstract Interface for a Web
Service</a><br />
!     3.1 <a href="#id5194735">Example: The
! GreatH Hotel Reservation Service</a><br />
!     3.2 <a href="#messages">Defining Messages
Using XML Schema</a><br />
!         3.2.1 <a
href="#import-xsd">Importing XML Schema</a><br />
!         3.2.2 <a
href="#embed-xsd">Embedding XML Schema</a><br />
!     3.3 <a href="#meps">Understanding Message
Exchange Patterns</a><br />
!     3.4 <a href="#interfaceEL">Defining
Interface</a><br />
!         3.4.1 <a
href="#extends">Interface Inheritance</a><br />
!         3.4.2 <a
href="#fault">Reusable Faults</a><br />
!         3.4.3 <a
href="#operations">Interface Operations</a><br />
4. <a href="#binding">Binding Abstract Interface to Concrete
***************
*** 203,246 ****
5. <a href="#Service">Defining Service Endpoints</a><br />
6. <a href="#advanced">Advanced Topics - TBD</a><br />
!     6.1 <a href="#id5197887">Import mechanism
and authoring style</a><br />
    6.2 <a
! href="#id5197902">Extensibility</a><br />
        6.2.1 <a
! href="#id5198005">Optional Versus Required Extensions</a><br />
        6.2.2 <a
! href="#id5198056">Scoping of the wsdl:required Attribute</a><br />
    6.3 <a href="#FP">Features and
Properties</a><br />
!     6.4 <a href="#id5198119">MTOM
Support</a><br />
!     6.5 <a href="#id5198133">Security
Considerations</a><br />
!     6.6 <a href="#id5198142">Versioning and
services equivalency</a><br />
    6.7 <a href="#RPCstyle">Operation Style and
RPC</a><br />
!     6.8 <a href="#id5198192">GET Versus POST:
Which to Use?</a><br />
!     6.9 <a href="#id5198206">Service
References</a><br />
!     6.10 <a href="#id5198223">XML Schema
Examples</a><br />
!     6.11 <a href="#id5198236">Multiple In-Line
Schemas</a><br />
    6.12 <a
! href="#id5198255">schemaLocation</a><br />
!     6.13 <a href="#id5198285">Multiple Logical
WSDL Documents Describing the Same Service</a><br />
!     6.14 <a href="#id5198305">Mapping to RDF
and semantic web</a><br />
!     6.15 <a href="#id5198314">Enabling Easy
Message Dispatch</a><br />
7. <a href="#uri">Notes on URIs</a><br />
!     7.1 <a href="#id5198408">XML namespaces and
schema locations</a><br />
!     7.2 <a href="#id5198448">Relative
URIs</a><br />
!     7.3 <a href="#id5198494">Generating
URIs</a><br />
8. <a href="#References">References</a><br />
--- 206,249 ----
5. <a href="#Service">Defining Service Endpoints</a><br />
6. <a href="#advanced">Advanced Topics - TBD</a><br />
!     6.1 <a href="#id5197936">Import mechanism
and authoring style</a><br />
    6.2 <a
! href="#id5197951">Extensibility</a><br />
        6.2.1 <a
! href="#id5198048">Optional Versus Required Extensions</a><br />
        6.2.2 <a
! href="#id5198099">Scoping of the wsdl:required Attribute</a><br />
    6.3 <a href="#FP">Features and
Properties</a><br />
!     6.4 <a href="#id5198162">MTOM
Support</a><br />
!     6.5 <a href="#id5198176">Security
Considerations</a><br />
!     6.6 <a href="#id5198185">Versioning and
services equivalency</a><br />
    6.7 <a href="#RPCstyle">Operation Style and
RPC</a><br />
!     6.8 <a href="#id5198234">GET Versus POST:
Which to Use?</a><br />
!     6.9 <a href="#id5198249">Service
References</a><br />
!     6.10 <a href="#id5198266">XML Schema
Examples</a><br />
!     6.11 <a href="#id5198279">Multiple In-Line
Schemas</a><br />
    6.12 <a
! href="#id5198298">schemaLocation</a><br />
!     6.13 <a href="#id5198328">Multiple Logical
WSDL Documents Describing the Same Service</a><br />
!     6.14 <a href="#id5198348">Mapping to RDF
and semantic web</a><br />
!     6.15 <a href="#id5198357">Enabling Easy
Message Dispatch</a><br />
7. <a href="#uri">Notes on URIs</a><br />
!     7.1 <a href="#id5198451">XML namespaces and
schema locations</a><br />
!     7.2 <a href="#id5198491">Relative
URIs</a><br />
!     7.3 <a href="#id5198532">Generating
URIs</a><br />
8. <a href="#References">References</a><br />
***************
*** 278,287 ****
</ul>
<br />
- <br />
-
-
- <p>No previous experience with Web service descriptions is
- assumed.</p>
</div>
--- 281,287 ----
</ul>
+ No previous experience with Web service descriptions is
+ assumed.<br />
<br />
</div>
***************
*** 291,305 ****
<p>In the following sections, We will cover various aspects of the
! WSDL language.</p>
! <p>Section 2 provides an introduction about defining abstract
! interface. Start with explaining how messages are defined using XML
! Schema and get used by WSDL, it moves on to examine the details of
! the interface construct.</p>
<p>Section 3 explains how to bind an abstract interface to concrete
! transport protocols. It first introduce the WSDL binding
constructs, and then explains the binding extensions defined by
! WSDL2.0 part 3, including bindings for SOAP1.2, SOAP1.1 and
HTTP.</p>
--- 291,305 ----
<p>In the following sections, We will cover various aspects of the
! WSDL 2.0 language.</p>
! <p>Section 2 explains how an abstract interface is described in
! WSDL 2.0. It first explains how messages are defined using XML
! Schema and get used by WSDL 2.0; it then moves on to examine the
! details of the interface construct.</p>
<p>Section 3 explains how to bind an abstract interface to concrete
! transport protocols. It first introduces the WSDL 2.0 binding
constructs, and then explains the binding extensions defined by
! @WSDL2.0 part 3@, including bindings for SOAP 1.2, SOAP 1.1 and
HTTP.</p>
***************
*** 307,346 ****
<p>Section 5 covers advanced topics, including features and
! properties,flexible authoring styles, service references, use of
URIs, etc.</p>
-
- <p>Through out this primer, We employ a hypothetical hotel
- reservation service to help explain WSDL2.0 constructs. We start
- with a simple scenario, and add more requirments gradually to
- illustrate how more advanced WSDL2.0 features may be used. Hotel
- GreatH is located in a remote island. It has been relying on old
- fasion communication mechanisms such as fax and phone to provide
- room reservations. Recently, the island has become a popular
- tourism destination. Though over years it has built up a small
- customer base, GreatH notices that its competitors are getting more
- customers though their facilities and prices are not as attractive
- as what GreatH provides. After some research, it finds out the
- secret is that its competitors provide some Web services which
- allow making reservations via Internet! GreatH hires Mr. Joe
- Somebody as their Web services architect to build a reservation Web
- service, and provide him with a list of requirements to start with.
- The service must be accessible by travel agents via their booking
- systems and directly by customers via GreatH's website site or
- emails. To check availability, a user must provide a check-in date,
- a check-out date, and specifies the type of room, and the Web
- service will provide the room rate if any desired room is
- available. To make a reservation, a user must provide a name,
- address, and credit card information, and the service will return a
- confirmation number if the reservation is sucessful. The service
- will return an error message if the credit card number is wrong or
- any data field is invalid. Joe knows that to provide the service,
- he needs to build the complete system which supports transaction
- and secured transmission, but as the first step, he decides to
- design the Web service and describe it using WSDL2.0. To start, Joe
- decides that he wants to use
- "http://www.greath.com/2004/05/wsdl/reservationService.wsdl" as the
- <code>target namespace</code> of his WSDL definitioin. It's an
- absolute URI and allows him to make the WSDL file available from
- GreatH's website.</p>
</div>
--- 307,312 ----
<p>Section 5 covers advanced topics, including features and
! properties, flexible authoring styles, service references, use of
URIs, etc.</p>
</div>
***************
*** 360,363 ****
--- 326,343 ----
Set</a></cite>]).</p>
+ <table border="1" summary="Editorial note">
+ <tr>
+ <td align="left" valign="top" width="50%"><b>Editorial
+ note</b></td>
+ <td align="right" valign="top" width="50%"> </td>
+ </tr>
+
+ <tr>
+ <td colspan="2" align="left" valign="top">dbooth asks: Should we
+ keep this table here? It duplicates what is in the spec. Maybe it
+ would be better to introduce these as we go.</td>
+ </tr>
+ </table>
+
<a id="tabnsprefixes" name="tabnsprefixes"></a><br />
<table border="1"
***************
*** 456,513 ****
<div class="div1">
! <h2><a id="IntroductionWS" name="IntroductionWS"></a>2.
! Introduction to Web Service Descriptions</h2>
!
! <p>This section provides a conceptual introduction to WSDL 2.0. Its
! purpose is twofold:</p>
!
! <ul>
! <li>
! <p>to introduce concepts and define terms that are used elsewhere;
! and</p>
! </li>
!
! <li>
! <p>to provide the "big picture" context for WSDL 2.0, so that the
! reader has a clearer understanding of what WSDL 2.0 is and
! isn't.</p>
! </li>
! </ul>
! <br />
! <br />
!
<div class="div2">
<h3><a id="Web_Service_Descriptions"
! name="Web_Service_Descriptions"></a>2.1 Web Service
! Descriptions</h3>
! <p>WSDL 2.0 is a language for writing <em>Web service
! descriptions</em> (WSDs). A WSD is an XML document that describes
! the mechanics of interacting with a particular Web service. It
! represents a take-it-or-leave-it "contract" that governs the
! interaction between a <a
! href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#reqpro">requester
! agent</a> and <a
href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#reqpro">provider
! agent</a>. Of course, this "contract" is only partial because in
! general it only describes the <em>mechanics</em> of the interaction
! -- not the intended semantics. Description of the application
! semantics is outside the scope of WSDL 2.0.</p>
<p>In some cases, the WSD is created before the provider agent is
! realized; in other cases the WSD is created at the same time or
! after the provider agent is realized. Although the provider agent
must faithfully implement the WSD, WSDL 2.0 makes no requirement
! about which is created first, and both approaches are useful.</p>
! <p>Although a WSD is written solely from the point of view of the
! Web service (or provider agent), it is inherently intended to
! constrain <em>both</em> the provider agent that offers the service
! <em>and</em> the requester agent that makes use of that service. It
! is concerned only with information that <em>both</em> parties must
! agree upon -- not information that is relevant only to one party or
! the other, such as internal implementation details.</p>
<div class="figure" style="text-align: center"><br />
--- 436,480 ----
<div class="div1">
! <h2><a id="IntroductionWS" name="IntroductionWS"></a>2. WSDL 2.0:
! The Big Picture</h2>
! <p>This section provides a big picture overview of WSDL 2.0 and its
! main concepts. Its purpose is to introduce concepts and terms that
! are used throughout the rest of this primer and in the @WSDL 2.0
! specification@.</p>
<div class="div2">
<h3><a id="Web_Service_Descriptions"
! name="Web_Service_Descriptions"></a>2.1 What Is a WSDL 2.0 Web
! Service Description (WSD)?</h3>
! <p>A WSDL 2.0 <em>Web service description</em> (WSD) is an XML
! document that describes the mechanics of interacting with a
! particular Web service. Although a WSD is written solely from the
! point of view of the Web service (or the <a
href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#reqpro">provider
! agent</a> that realizes that service), it is inherently intended to
! constrain <em>both</em> the provider agent <em>and</em> the <a
! href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#reqpro">requester
! agent</a> that makes use of that service. The WSD is therefore
! concerned only with information that <em>both</em> parties must
! agree upon -- not information that is relevant only to one party or
! the other, such as internal implementation details. It represents a
! take-it-or-leave-it "contract" that governs the interaction between
! requester agent and provider agent. Of course, this "contract" is
! only partial because in general it only describes the
! <em>mechanics</em> of the interaction -- not the intended
! semantics. Description of the application semantics is outside the
! scope of WSDL 2.0.</p>
<p>In some cases, the WSD is created before the provider agent is
! realized, and the provider agent is then created to conform to the
! WSD. In other cases the WSD is created at the same time or after
! the provider agent has been created. Although the provider agent
must faithfully implement the WSD, WSDL 2.0 makes no requirement
! about which is created first. Both approaches are useful in
! different situations.</p>
! <p></p>
<div class="figure" style="text-align: center"><br />
***************
*** 520,563 ****
<br />
</div>
</div>
<div class="div2">
! <h3><a id="overview" name="overview"></a>2.2 Overview of WSDL
! 2.0</h3>
! <p>WSDL 2.0 enables one to separate the description of a service's
! abstract functionality from concrete details of how and where that
! functionality is offered.</p>
! <p>An interface describes what a Web service is. The abstract
! functionality of a service is described in terms of the messages it
! sends and receives. Messages are described independent of any
! specific wire format using a type system, typically XML schema. A
! message exchange pattern defines the sequence and cardinality of
! the abstract messages a service exchanges with its clients. A
! binding describes how to access a Web service. It specifies
! transport and wire format details for one or more interfaces. A
! service endpoint describes where to access a service. It associates
a concrete network address with a binding of an interface.</p>
! <p>This layering of interface, binding and service endpoint
! facilitates different levels of reusability and distribution of
! work in different stages of the lifecycle of a service. As one
! typical use case, an interface describes the functionality and
! supported features of a service, and is used at design time. It has
! the highest level of reusability, and should be abstract and
! reusable for different bindings; A binding is used at configuration
time. It provides transport protocol specific information about how
to access a service, and should be reusable by different endpoints.
An endpoint provides concrete location of a service, and is used at
! run time. It's most concrete, specific to a particular instance of
! a service, and not reusable.</p>
! <div class="div3">
! <h4><a id="syntax" name="syntax"></a>2.2.1 XML Syntax Summary</h4>
! <p>In the core language specification, WSDL constructs are defined
! as a set of abstract components, along with a mapping to an XML
! infoset representation for these components. For easier
consumption, the primer uses the XML representation of WSDL
components and the XML syntax as summarized below to illustrate the
--- 487,635 ----
<br />
</div>
+
+ <div class="div3">
+ <h4><a id="scope" name="scope"></a>2.1.1 WSDL 2.0 Scope: Individual
+ Web Services</h4>
+
+ <p>WSDL 2.0 is limited to the description of individual Web
+ services from a service provider's viewpoint -- not combinations of
+ Web services. WSDL 2.0's extensibility and composability with other
+ Web services specifications makes it an essential building block
+ for a complete solution, but WSDL itself does not provide the
+ complete solution for building real world Web services. For
+ example, several individual Web services can be composed to provide
+ more complex functionalities which may involve process definition,
+ transaction management, state mangement, and reliable messaging.
+ Though WSDL does not preclude the description of such composition
+ of individual services, the way two or more services could be
+ composed is considered out of scope of WSDL.</p>
+ </div>
</div>
<div class="div2">
! <h3>2.2 Major Elements of a Web Service Description (WSD)</h3>
! <p>WSDL 2.0 enables you to separate the description of a Web
! service's abstract functionality from the concrete details of how
! and where that functionality is offered. WSDL 2.0 divides a WSD
! into the following major elements:</p>
! <ul>
! <li>
! <p>Message <em>types</em> describe the kinds of messages that a Web
! service may send or receive. Message types are defined using a
! schema language -- typically XML Schema -- independent of any
! specific wire format.</p>
! </li>
!
! <li>
! <p>An <em>interface</em> describes the abstract functionality of
! the Web service in terms of the types of messages it sends and
! receives. An interface consists of a set of operations.</p>
! </li>
!
! <li>
! <p>An <em>operation</em> describes a sequence of messages that may
! be exchanged with the Web service. It associates a message exchange
! pattern (MEP) with the message types that will be exchanged in that
! operation. (For example, the in-out MEP specifies that if a
! provider agent sends a message <em>in</em> to the Web service, the
! Web services will either send a reply message back <em>out</em> to
! the provider agent, or it will send a fault message back to the
! provider agent.)</p>
! </li>
!
! <li>
! <p>A <em>binding</em> describes how to access a Web service. It
! specifies transport and wire format details for one or more
! interfaces.</p>
! </li>
!
! <li>
! <p>A WSDL 2.0 <em>service</em> lists the locations where the
! described Web service can be accessed. A service consists of a list
! of endpoints.</p>
! </li>
!
! <li>
! <p>A service <em>endpoint</em> describes where to access a service
! via a particular transport protocol and wire format. It associates
a concrete network address with a binding of an interface.</p>
+ </li>
+ </ul>
! <br />
! <br />
!
!
! <p>This layering of message type, interface, operation, binding,
! service and endpoint facilitates different levels of reusability
! and distribution of work in different stages of the lifecycle of a
! Web service. For example, an interface describes the functionality
! and supported features of a service, and is used at design time. It
! has the highest level of reusability, and should be abstract and
! reusable for different bindings. A binding is used at configuration
time. It provides transport protocol specific information about how
to access a service, and should be reusable by different endpoints.
An endpoint provides concrete location of a service, and is used at
! run time. The endpoint is the most concrete element, specific to a
! particular instance of a service, and is therefore not
! reusable.</p>
! </div>
! <div class="div2">
! <h3><a id="overview" name="overview"></a>2.3 WSDL 2.0
! Extensibility</h3>
! <p>WSDL 2.0 offers two mechanisms for extensibility: an open
! content model; and Features and Properties.</p>
!
! <ul>
! <li>
! <p>@@ TODO: Reduce the amount of detail in the next paragraph. It
! is too much detail for this overview section.@@</p>
!
! <p>WSDL 2.0's <em>open content model</em> allows XML elements from
! non-WSDL namespaces to be intermingled with WSDL constructs in a
! WSD. As specified in section 6 of Part1, WSDL allows extensions to
! be defined in terms of both elements and attributes.
! Namespace-qualified elements whose namespace is NOT
! "http://www.w3.org/2004/03/wsdl" (i.e., non-WSDL elements) may
! appear among the children of specific elements whose [namespace
! name] is "http://www.w3.org/2004/03/wsdl" (i.e., WSDL elements).
! Also, WSDL allows qualified attributes whose namespace is NOT
! "http://www.w3.org/2004/03/wsdl" (i.e., non-WSDL attributes) to
! appear on any elements whose namespace is
! "http://www.w3.org/2004/03/wsdl" (i.e., WSDL elements). See more
! about extensibility in section@@@@. Since extensions can appear
! anywhere, they are not explicitly indicated in the above syntax and
! will not be mentioned again in later sections where a particular
! construct is explained.</p>
! </li>
!
! <li>
! <p>WSDL 2.0's <em>Features and Properties</em> (F&P) mechanism
! provides another way to specify extensions in a WSD, and offers
! slightly more structure for extensions than the open content model
! offers. A WSDL 2.0 Feature allows a particular extension to be
! unambiguously identified by a URI. WSDL 2.0 Properties complement
! the notion of Features. Properties permit data values to be
! associated with Features. For example, a particular extension may
! require a parameter, and a Property may be used to indicate a value
! for that parameter.</p>
! </li>
! </ul>
!
! <br />
! <br />
! <p>@@ TODO: Explain optional and required extensions @@</p>
! </div>
!
! <div class="div2">
! <h3>2.4 XML Syntax Summary</h3>
!
! <p>In the core language specification, WSDL 2.0 constructs are
! defined as a set of abstract components, along with a mapping to an
! XML infoset representation for these components. For easier
consumption, the primer uses the XML representation of WSDL
components and the XML syntax as summarized below to illustrate the
***************
*** 583,586 ****
--- 655,664 ----
</ul>
+ <p>@@ TODO: Add an abridged version of this syntax overview,
+ listing only the most important elements described above. @@</p>
+
+ <p>@@ TODO: Delete the <documentation> elements, because
+ they're mentioned below. @@</p>
+
<div class="exampleInner">
<pre>
***************
*** 723,767 ****
</div>
! <p>As specified in section 6 of Part1, WSDL allows extensions to be
! defined in terms of both elements and attributes. Firstly, WSDL
! allows namespace-qualified elements whose namespace is NOT
! "http://www.w3.org/2004/03/wsdl" to appear among the children of
! specific elements whose [namespace name] is
! "http://www.w3.org/2004/03/wsdl". Secondly, WSDL allows qualified
! attributes whose namespace is NOT "http://www.w3.org/2004/03/wsdl"
! to appear on any elements whose namespace is
! "http://www.w3.org/2004/03/wsdl". See more about extensibility in
! section@@@@. Since extensions can appear in all the places, they
! are not explicitly indicated in the above syntax and will not be
! mentioned again in later sections where a particular construct is
! explained.</p>
!
! <p>An optional <code>documentation</code> element is allowed inside
! any WSDL elements as a container for human readable and/or machine
! processable documentation. The content of
<code>documentation</code> is arbitrary characters and elements
("mixed" content in XML Schema ).</p>
- </div>
<div class="div3">
! <h4><a id="scope" name="scope"></a>2.2.2 Scope</h4>
!
! <p>It's important to note that the scope of WSDL2.0 is limited to
! the description of a single stateless Web service from a service
! provider's viewpoint. Its extensibility and composeability with
! other Web services specifications makes it an essential building
! block for a complete solution, but WSDL itself does not provide the
! complete solution for building real world application using Web
! services. For example, several individual Web services can be
! composed to provide more complex functionalities which may involve
! process definition, transaction management, state mangement, and
! reliable messaging. Though WSDL does not preclude the description
! of such composition of individual services, the way two or more
! services could be composed is considered out of scope of WSDL.</p>
! </div>
!
! <div class="div3">
! <h4><a id="targetNS" name="targetNS"></a>2.2.3 Target Namespace and
! Symbol Spaces</h4>
<p>All WSDL documents start with a <code>definitions</code>
--- 801,812 ----
</div>
! <p>An optional <code>documentation</code> element is also allowed
! inside any WSDL element as a container for human readable and/or
! machine processable documentation. The content of
<code>documentation</code> is arbitrary characters and elements
("mixed" content in XML Schema ).</p>
<div class="div3">
! <h4>2.4.1 Target Namespace and Symbol Spaces</h4>
<p>All WSDL documents start with a <code>definitions</code>
***************
*** 813,821 ****
<div class="div1">
! <h2><a id="interface" name="interface"></a>3. Defining Abstract
Interface for a Web Service</h2>
<div class="div2">
! <h3><a id="messages" name="messages"></a>3.1 Defining Messages
Using XML Schema</h3>
--- 858,923 ----
<div class="div1">
! <h2><a id="interface" name="interface"></a>3. Defining an Abstract
Interface for a Web Service</h2>
<div class="div2">
! <h3>3.1 Example: The GreatH Hotel Reservation Service</h3>
!
! <p>Throughout this primer, we employ a hypothetical hotel
! reservation service to help explain WSDL2.0 constructs. We start
! with a simple scenario, and add more requirements gradually to
! illustrate how more advanced WSDL2.0 features may be used.</p>
!
! <p>Hotel GreatH is located in a remote island. It has been relying
! on fax and phone to provide room reservations, both to travel
! agents and to customers directly. Even though the facilities and
! prices at GreatH are better than what its competitor offers, GreatH
! notices that its competitor is getting more customers than GreatH.
! After research, GreatH realizes that this is because the competitor
! offers a Web service that permits travel agent reservation systems
! to reserve rooms directly over the Internet. GreatH then hires a
! Web services architect, Joe Somebody, to build a reservation Web
! service, and provides him with a list of requirements:</p>
!
! <ul>
! <li>
! <p>The service must be accessible by travel agents via their
! booking systems and directly by customers via GreatH's website site
! or email.</p>
! </li>
!
! <li>
! <p>To check availability, a user must specify a check-in date, a
! check-out date, and room type room, and the Web service will
! provide the room rate if such a room is available.</p>
! </li>
!
! <li>
! <p>To make a reservation, a user must provide a name, address, and
! credit card information, and the service will return a confirmation
! number if the reservation is sucessful.</p>
! </li>
!
! <li>
! <p>The service will return an error message if the credit card
! number or any other data field is invalid.</p>
! </li>
! </ul>
!
! Joe knows that he will later need to build the complete system
! which supports transactions and secured transmission. But as the
! first step, he decides to focus on the basic functionality so that
! he can begin testing and gain feedback from his customer, GreatH.
! He designs the Web service and describes it using WSDL 2.0. <br />
! <br />
! <p>To start, Joe decides that he wants to use
! "http:/greath.example.com/2004/05/wsdl/reservationService.wsdl" as
! the <code>target namespace</code> of his WSDL definition. It's an
! absolute URI and allows him to make the WSDL file available from
! GreatH's website.</p>
! </div>
!
! <div class="div2">
! <h3><a id="messages" name="messages"></a>3.2 Defining Messages
Using XML Schema</h3>
***************
*** 937,941 ****
<div class="div3">
! <h4><a id="import-xsd" name="import-xsd"></a>3.1.1 Importing XML
Schema</h4>
--- 1039,1043 ----
<div class="div3">
! <h4><a id="import-xsd" name="import-xsd"></a>3.2.1 Importing XML
Schema</h4>
***************
*** 987,991 ****
<div class="div3">
! <h4><a id="embed-xsd" name="embed-xsd"></a>3.1.2 Embedding XML
Schema</h4>
--- 1089,1093 ----
<div class="div3">
! <h4><a id="embed-xsd" name="embed-xsd"></a>3.2.2 Embedding XML
Schema</h4>
***************
*** 1107,1111 ****
<div class="div2">
! <h3><a id="meps" name="meps"></a>3.2 Understanding Message Exchange
Patterns</h3>
--- 1209,1213 ----
<div class="div2">
! <h3><a id="meps" name="meps"></a>3.3 Understanding Message Exchange
Patterns</h3>
***************
*** 1294,1298 ****
<div class="div2">
! <h3><a id="interfaceEL" name="interfaceEL"></a>3.3 Defining
Interface</h3>
--- 1396,1400 ----
<div class="div2">
! <h3><a id="interfaceEL" name="interfaceEL"></a>3.4 Defining
Interface</h3>
***************
*** 1402,1406 ****
<div class="div3">
! <h4><a id="extends" name="extends"></a>3.3.1 Interface
Inheritance</h4>
--- 1504,1508 ----
<div class="div3">
! <h4><a id="extends" name="extends"></a>3.4.1 Interface
Inheritance</h4>
***************
*** 1459,1463 ****
<div class="div3">
! <h4><a id="fault" name="fault"></a>3.3.2 Reusable Faults</h4>
<p>The <code>fault</code> element can be used to declare faults
--- 1561,1565 ----
<div class="div3">
! <h4><a id="fault" name="fault"></a>3.4.2 Reusable Faults</h4>
<p>The <code>fault</code> element can be used to declare faults
***************
*** 1550,1554 ****
<div class="div3">
! <h4><a id="operations" name="operations"></a>3.3.3 Interface
Operations</h4>
--- 1652,1656 ----
<div class="div3">
! <h4><a id="operations" name="operations"></a>3.4.3 Interface
Operations</h4>
Received on Thursday, 16 September 2004 18:14:57 UTC