WD-ws-desc-usecases-20020604 61.1 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en"><head><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><title>Web Service Description Usage Scenarios</title><style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

dt.label       { display: run-in; }

li p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

      .Accepted {}
      .Rejected {background-color: #DDDDDD; display: none}
      .Draft {background-color: #DDFFFF}
    </style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css"></head><body>
	<div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home"></a></p>
<h1 id="id-required-by-pubrules-1">Web Service Description Usage Scenarios</h1>
<h2 id="id-required-by-pubrules-3">W3C Working Draft 4 June 2002</h2><dl><dt>This version:</dt><dd>
			<a href="http://www.w3.org/TR/2002/WD-ws-desc-usecases-20020604">http://www.w3.org/TR/2002/WD-ws-desc-usecases-20020604</a>

		</dd><dt>Latest version:</dt><dd>
			<a href="http://www.w3.org/TR/ws-desc-usecases">http://www.w3.org/TR/ws-desc-usecases</a>
		</dd><dt>Previous versions:</dt><dd>
			(none)
		</dd><dt>Editors:</dt>
			<dd>Waqar Sadiq, EDS <a href="mailto:waqar.sadiq@eds.com">&lt;waqar.sadiq@eds.com&gt;</a></dd>
			<dd>Sandeep Kumar, Cisco Systems <a href="mailto:sandkuma@cisco.com">&lt;sandkuma@cisco.com&gt;</a></dd>
		</dl>
			<p class="copyright">
				<a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a> &nbsp; &copy; 2002 <a href="http://www.w3.org/">
					<abbr title="World Wide Web Consortium">W3C</abbr>
				</a>
				<sup>&reg;</sup>(<a href="http://www.lcs.mit.edu/">
					<abbr title="Massachusetts Institute of Technology">MIT</abbr>
				</a>, <a href="http://www.inria.fr/">
					<abbr title="Institut National de Recherche en Informatique et Automatique" lang="fr">INRIA</abbr>
				</a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software licensing</a> rules apply.</p>
		</div><hr><div>
<h2><a name="abstract">Abstract</a></h2>
			<p>This document describes the Usage Scenarios guiding the development of the Web Service Description specification.</p>
		</div><div>
<h2><a name="status">Status of this Document</a></h2>
      <p>This is the first <a href="http://www.w3.org/Consortium/Process-20010719/tr.html#RecsWD">W3C Working Draft</a> of the Web Services Description Usage Scenarios document. It is a <a href="http://www.w3.org/2002/01/ws-desc-charter">chartered</a> deliverable of the <a href="http://www.w3.org/2002/ws/desc/">Web Services Description Working Group (WG)</a>, which is part of the <a href="http://www.w3.org/2002/ws/Activity">Web Services Activity</a>. The Working Group has agreed to publish this document, although this document does not necessarily represent consensus within the Working Group.  This document may change substantially due to coordination and consolidation efforts with Web Services Usage Scenarios work undertaken in the
<a href="http://www.w3.org/2002/ws/arch/">Web Services Architecture Working Group</a>.</p>
      <p>Comments on this document should be sent to <a href="mailto:public-ws-desc-comments@w3.org">public-ws-desc-comments@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/">public archive</a>). It is inappropriate to send discussion emails to this address.</p>
      <p>Discussion of this document takes place on
	the public <a href="mailto:www-ws-desc@w3.org">www-ws-desc@w3.org</a> mailing list (<a href="http://lists.w3.org/Archives/Public/www-ws-desc/">public archive</a>) per the email communication rules in the <a href="http://www.w3.org/2002/01/ws-desc-charter">Web Services Description Working Group Charter</a>.</p>
<p>
 Patent disclosures relevant to this specification may be found on the
 Working Group's <a href="http://www.w3.org/2002/ws/desc/2/04/24-IPR-statements.html">patent
 disclosure page</a>.
</p>
      <p>This is a public W3C Working Draft. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of all <a href="http://www.w3.org/TR/">W3C technical reports</a> can be found at <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>
    </div>
	<div class="toc">
<h2><a name="contents">Table of Contents</a></h2><p class="toc">1 <a href="#introduction">Introduction</a><br>2 <a href="#requirements">Documentation of Usage Scenarios</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#N1016E">Messaging</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.1 <a href="#N10173">UC0001 Fire-and-forget[WS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.1.1 <a href="#N10178">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.1.2 <a href="#N10181">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.1.3 <a href="#N1018A">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.2 <a href="#oneway-guaranteed-message">UC0002 Oneway Message With Guaranteed Delivery[WS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.2.1 <a href="#N1019E">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.2.2 <a href="#N101A7">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.2.3 <a href="#N101B0">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.3 <a href="#document-centric-computing">UC0006 Document Centric Computing[WS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.3.1 <a href="#N101C4">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.3.2 <a href="#N101CD">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.3.3 <a href="#N101D6">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.4 <a href="#N101E7">UC0015 Request-Response [JJM]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.4.1 <a href="#N101EC">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.4.2 <a href="#N101F5">Editors' Comments</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.4.3 <a href="#N10201">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.4.4 <a href="#N1020A">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.5 <a href="#N1021A">UC0025 Event notification [JJM]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.5.1 <a href="#N1021F">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.5.2 <a href="#N10228">Editors' Comments</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.5.3 <a href="#N10231">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.5.4 <a href="#N1023A">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.6 <a href="#N10244">UC0028 Sync/Async Operations [IS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.6.1 <a href="#N10249">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.6.2 <a href="#N10252">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.6.3 <a href="#N1025B">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.7 <a href="#N10279">UC0030 Events [IS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.7.1 <a href="#N1027E">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.7.2 <a href="#N10289">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.7.3 <a href="#N10292">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#N102B5">Specification</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.1 <a href="#multiple-faults">UC0003 Multiple Faults[WS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.1.1 <a href="#N102C0">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.1.2 <a href="#N102C9">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.1.3 <a href="#N102D2">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.2 <a href="#service-level-attributes">UC0004 Service Level Attributes[WS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.2.1 <a href="#N102E6">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.2.2 <a href="#N102EF">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.2.3 <a href="#N102F8">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.3 <a href="#operational-level-attributes">UC0005 Operation Level Attributes[WS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.3.1 <a href="#N1030F">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.3.2 <a href="#N10318">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.3.3 <a href="#N10321">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.4 <a href="#N1032F">UC0029 Namespaces with data and interfaces [IS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.4.1 <a href="#N10334">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.4.2 <a href="#N1033D">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.4.3 <a href="#N10346">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.5 <a href="#N10361">UC0031 Versioning [IS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.5.1 <a href="#N10366">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.5.2 <a href="#N1036F">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.5.3 <a href="#N10378">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.6 <a href="#N1038C">UC0032 Classification system for operations [JR]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.6.1 <a href="#N10391">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.6.2 <a href="#N1039A">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.6.3 <a href="#N103A3">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.7 <a href="#N103AD">UC0033 Header Specification [WV]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.7.1 <a href="#N103B2">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.7.2 <a href="#N103BB">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.7.3 <a href="#N103C4">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.8 <a href="#N103D8">UC0034B Specifying streaming [YF]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.8.1 <a href="#N103DD">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.8.2 <a href="#N103E6">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.8.3 <a href="#N103EF">Editor's Comment</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.8.4 <a href="#N103F8">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.9 <a href="#N10406">UC0035 Extending PortType [JS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.9.1 <a href="#N1040B">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.9.2 <a href="#N10414">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.9.3 <a href="#N1041D">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#N1043D">Service Reference</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.1 <a href="#N10444">UC0027 References [IS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.1.1 <a href="#N10449">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.1.2 <a href="#N10452">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.1.3 <a href="#N1045B">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#N10486">Meta data</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.4.1 <a href="#N1048B">UC0026 Service Metadata [IS]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.4.1.1 <a href="#N10490">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.4.1.2 <a href="#N10499">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.4.1.3 <a href="#N104A2">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.5 <a href="#N104BE">Miscellaneous</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.5.1 <a href="#N104C5">UC0034A Obtaining WSDL from the web service itself [YF]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.5.1.1 <a href="#N104CA">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.5.1.2 <a href="#N104D3">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.5.1.3 <a href="#N104DC">Scenario Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.5.2 <a href="#N104E6">UC0036 Storage and Retrieval of WSDL in Registries and Repositories [AR]</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.5.2.1 <a href="#N104EB">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.5.2.2 <a href="#N104F4">Relates To</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.5.2.3 <a href="#N104FD">Scenario Description</a><br></p>
<h3 id="id-required-by-pubrules">Appendices</h3><p class="toc">A <a href="#references">References</a><br>B <a href="#N105C7">Change Log</a> (Non-Normative)<br></p></div><hr><div class="body">
		<div class="div1">

<h2><a name="introduction"></a>1 Introduction</h2>
			<p>This document describes the use cases of the web services description language.  The use cases are meant to capture what is important for a web service to describe itself. There may be several other important aspects of a web service but irrelevant to its operational and interaction descriptions.</p>
			<p>We believe that following viewpoints would prove useful in describing the use-cases for the web service description language.</p>
			<ul>
				<li>
					<p>View Point 1 [VP1]: The web service description defines a contract that the web service implements.  The web service client exchanges messages based on this contract.</p>
				</li>
				<li>
					<p>View Point 2 [VP2]: The description language is used by tools to generate proper stubs.  These stubs ensure that the stubs implement the expected behavior for the client.</p>
				</li>
				<li>
					<p>View Point 3 [VP3]: The web service description captures information that allows one to reason about them semantically.</p>
				</li>
			</ul>
			<p>All the use cases in this document pertain to one or more view-points as described above. Every use case as described in this document has a scenario definition, scenario description, and how it relates to one of the view-points as outlined above.  Sample code is based upon the Web Services Description Language 1.1 <a href="#WSDL11">[WSDL 1.1]</a>.</p>
		</div>
		<div class="div1">

<h2><a name="requirements"></a>2 Documentation of Usage Scenarios</h2>
			<div class="div2">

<h3><a name="N1016E"></a>2.1 Messaging</h3>
				<div class="div3">

<h4><a name="N10173"></a>2.1.1 UC0001 Fire-and-forget[WS]</h4>
					<div class="div4">

<h5><a name="N10178"></a>2.1.1.1 Scenario Definition</h5>
						<p>Ability to describe a one way operation of a web service that has no guaranteed delivery semantics. The input message received as part of such an operation MAY be lost.</p>
					</div>
					<div class="div4">

<h5><a name="N10181"></a>2.1.1.2 Relates To</h5>
						<p>VP2</p>
					</div>
					<div class="div4">

<h5><a name="N1018A"></a>2.1.1.3 Scenario Description</h5>
						<p>A metrics collection service exposes an operation to client applications to report their application usage metrics. These applications opt to update their individual reporting  metrics to such a web service, instead of  	reporting individual metric.  Consequently, a loss of a message is not critical as the next update would provide an updated 	summary.  The target web service exposes an interface to report those metrics.  For the sake of efficiency and simplicity, the client applications are not interested in receiving any faults; they simply want to send a message and forget about it until the next time.</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;binding ...&gt;
	...
	&lt;operation name="UpdateStatus"&gt;
		&lt;soap:operation delivery="fire-and-forget"&gt;
			&lt;input message="UpdateStatusInput"/&gt;
		&lt;/soap:operation&gt;
	&lt;/operation&gt;
&lt;/binding&gt;
						</pre></td></tr></table>
					</div>
				</div>
				<div class="div3">

<h4><a name="oneway-guaranteed-message"></a>2.1.2 UC0002 Oneway Message With Guaranteed Delivery[WS]</h4>
					<div class="div4">

<h5><a name="N1019E"></a>2.1.2.1 Scenario Definition</h5>
						<p>Ability to describe a one way operation of a web service that has guaranteed delivery semantics. The input operation received as part of such an operation MUST NOT be lost. </p>
					</div>
					<div class="div4">

<h5><a name="N101A7"></a>2.1.2.2 Relates To</h5>
						<p>VP2, VP3</p>
					</div>
					<div class="div4">

<h5><a name="N101B0"></a>2.1.2.3 Scenario Description</h5>
						<p>A web service provides a messaging service.  This web service is a higher level interface over enterprise messaging capabilities such as JMS.  On the publisher side, it exposes an interface that allows applications to publish messages to a logical messaging channel.  The publishing clients do not expect to receive a response to their invocation however it is important for them to know that the message has been delivered.  So while they make a one-way request, they do want to receive faults if the message could not be successfully published, whether due to a system error on the server side or due to an application error on the server side.</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;binding ...&gt;
	...
	&lt;operation name="CreatePO"&gt;
		&lt;soap:operation delivery="guaranteed"&gt;
			&lt;input message="CreatePOInput"/&gt;
		&lt;/soap:operation&gt;
	&lt;/operation&gt;
&lt;/binding&gt;
						</pre></td></tr></table>
					</div>
				</div>
				<div class="div3">

<h4><a name="document-centric-computing"></a>2.1.3 UC0006 Document Centric Computing[WS]</h4>
					<div class="div4">

<h5><a name="N101C4"></a>2.1.3.1 Scenario Definition</h5>
						<p>Ability to describe an operation of a web service that MAY include message parts that are document attachments along with other regular messages.</p>
					</div>
					<div class="div4">

<h5><a name="N101CD"></a>2.1.3.2 Relates To</h5>
						<p>VP2</p>
					</div>
					<div class="div4">

<h5><a name="N101D6"></a>2.1.3.3 Scenario Description</h5>
						<p>A web service is an ebXML <a href="#ebXML">[ebXML]</a> web service that requires document-oriented computing.  The operations that its interface includes are all actually asynchronous messages with no parameters.  All the data to the messages is sent as document attachments.  Its description document will then describe the data expected by its operations in terms of the expected attachments and not in terms of its parameters.</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;types&gt;
	&lt;complexType name="ReimbursementRequest"/&gt;
		&lt;element name="amount" type="xsd:float"/&gt;
		&lt;element name="date=" type="xsd:string"/&gt;
	&lt;/complexType&gt;
	...
&lt;/types&gt;

&lt;message name="ReimbursementRequestInput"&gt;
	&lt;part name="employeeId" type="xsd:string"/&gt;
	&lt;part name="info" type="ReimbursementRequest"/&gt;
	&lt;attachment name="hotelReceipt"
		uri="uri to image of hotel receipt"/&gt;
	&lt;attachment name="carRentalReceipt"
		uri="uri to image of rental car receipt"/&gt;
&lt;/message&gt;

&lt;operation name="Reimburse"&gt;
	&lt;input message="ReimbursementRequestInput"/&gt;
&lt;/operation&gt;

						</pre></td></tr></table>
					</div>
				</div>
				<div class="div3">

<h4><a name="N101E7"></a>2.1.4 UC0015 Request-Response [JJM]</h4>
					<div class="div4">

<h5><a name="N101EC"></a>2.1.4.1 Scenario Definition</h5>
						<p>Ability to describe an operation of a web service that responds with an output message or a fault based on at least one or more input messages received.</p>
					</div>
					<div class="div4">

<h5><a name="N101F5"></a>2.1.4.2 Editors' Comments</h5>
						<p>If UC0001 and UC0002 are accepted, the implications must be well understood and described.</p>
						<p>Since the bindings would determine how the messages are actually sent, there may be a need to correlate the request with the response. </p>
					</div>
					<div class="div4">

<h5><a name="N10201"></a>2.1.4.3 Relates To</h5>
						<p>VP1, VP2</p>
					</div>
					<div class="div4">

<h5><a name="N1020A"></a>2.1.4.4 Scenario Description</h5>
						<p>Two parties wish to conduct electronic business by the exchange of business documents. The sending party packages one or more documents into a request message, which is then sent to the receiving party. The receiving party then processes the message contents and responds to the sending party. Examples of the sending party's documents may be purchase order requests, manufacturing information and patient healthcare information. Examples of the receiving party's responses may include order confirmations, change control information and contractual acknowledgements.</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;binding ...&gt;
	...
	&lt;operation name="handleRequest"&gt;
			&lt;input message="inputData"/&gt;
		&lt;output message="outputData"/&gt;
	&lt;/operation&gt;
&lt;/binding&gt;
						</pre></td></tr></table>
					</div>
				</div>

				<div class="div3">

<h4><a name="N1021A"></a>2.1.5 UC0025 Event notification [JJM]</h4>
					<div class="div4">

<h5><a name="N1021F"></a>2.1.5.1 Scenario Definition</h5>
						<p>Ability to describe an operation of a web service that returns output message. </p>
					</div>
					<div class="div4">

<h5><a name="N10228"></a>2.1.5.2 Editors' Comments</h5>
						<p>Are the events as described in the scenario of different types? Does it make sense to have an associated semantics of guaranteed delivery?</p>
					</div>
					<div class="div4">

<h5><a name="N10231"></a>2.1.5.3 Relates To</h5>
						<p>VP1</p>
					</div>
					<div class="div4">

<h5><a name="N1023A"></a>2.1.5.4 Scenario Description</h5>
						<p>An application subscribes to notifications of certain named events from an event source. When such events occur, notifications are sent back to the originating application (first party notification) or to another application (third party notification). For example, an application can subscribe to notification of various aspects of a printer's status (e.g., running out of paper, ink etc.). The notifications of such events could be delivered to a management application.</p>
					</div>
				</div>
				<div class="div3">

<h4><a name="N10244"></a>2.1.6 UC0028 Sync/Async Operations [IS]</h4>
					<div class="div4">

<h5><a name="N10249"></a>2.1.6.1 Scenario Definition</h5>
						<p>Capture  the synchronicity of the operations</p>
					</div>
					<div class="div4">

<h5><a name="N10252"></a>2.1.6.2 Relates To</h5>
						<p>VP2</p>
					</div>
					<div class="div4">

<h5><a name="N1025B"></a>2.1.6.3 Scenario Description</h5>
						<p>To negotiate proper communication sequence WS provider has to be able to describe if certain operations can be handled asynchronously, must be handled asynchronously or synchronously and what is the expected execution time. This would allow process orchestration system to properly adjust the flow and not run into unexpected blocking.</p>
						<p>Here is an example of operation definitions.</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;portType&gt;
	&lt;operation ... handling="sync async" replyTime="10000"/&gt; &lt;!-- up to the client --&gt;
	&lt;operation ... /&gt; &lt;!-- only sync --&gt;
	&lt;operation ... handling="async" replyTime="unknown"&gt; &lt;!-- long running, human dependent --&gt;
&lt;/portType&gt;
</pre></td></tr></table>
						<p>WS client would then get to use operations properly. Similar to this.</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>AsyncContext ctx = service.start_myAsyncOp(...);
MyResult result = service.waitFor_myAsyncOp(ctx);
</pre></td></tr></table>
						<p>The underlying WS framework would then initiate proper SOAP <a href="#SOAP12">[SOAP 1.2 Part 1]</a> messaging sequence with acknowledgement and notification phases. SOAP protocol must support asynchronous messaging.</p>
					</div>
				</div>
				<div class="div3">

<h4><a name="N10279"></a>2.1.7 UC0030 Events [IS]</h4>
					<div class="div4">

<h5><a name="N1027E"></a>2.1.7.1 Scenario Definition</h5>
						<p>Capture event management model for web services</p>
					</div>

					<div class="div4">

<h5><a name="N10289"></a>2.1.7.2 Relates To</h5>
						<p>VP1,VP2</p>
					</div>
					<div class="div4">

<h5><a name="N10292"></a>2.1.7.3 Scenario Description</h5>
						<p>A WS provider can describe events generated by a service as follows:</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;message name="hasDataIn"&gt;
	&lt;part name="container" type="data:Container"/&gt;
&lt;/message&gt;
&lt;message name="hasDataOut"&gt;
	&lt;part name="context" type="data:Context"/&gt;
&lt;/message&gt;
&lt;portType&gt;
	&lt;operation...
	&lt;event name="hasData1" mode="poll" interval="10"&gt;
		&lt;input message="interface:hasDataIn"/&gt;
		&lt;output message="interface:hasDataOut"/&gt;
	&lt;/event&gt;
	&lt;event name="hasData2" mode="push"&gt;
		&lt;input message="inerface:hasDataIn"/&gt;
		&lt;output message="interface:hasDataOut"/&gt;
	&lt;/event&gt;
&lt;/portType&gt;
</pre></td></tr></table>
						<p>And this way WS client may subscribe to events like this</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>service.subscribe_hasData1(new data.Container(...),new myServiceListener())
service.subscribe_hasData2(new data.Container(...),new myServiceListener())</pre></td></tr></table>
						<p>And implement a proper handler</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>class myServiceListener
{
	void hasData1(data.Context ctx) { ... }
	void hasData2(data.Context ctx) { ... }
}
</pre></td></tr></table>
						<p>The underlying WS framework would take care of the event by either polling (sending a SOAP request) with a specified interval or registering a SOAP listener (endpoint) with the target WS (according to the event definition in WSDL).</p>
						<p>We should also describe the SOAP protocol sequence (registration/acknowledgement/notification) for the events in accordance with asynchronous SOAP messaging.</p>
					</div>
				</div>
			</div>
			<div class="div2">

<h3><a name="N102B5"></a>2.2 Specification</h3>
				<div class="div3">

<h4><a name="multiple-faults"></a>2.2.1 UC0003 Multiple Faults[WS]</h4>
					<div class="div4">

<h5><a name="N102C0"></a>2.2.1.1 Scenario Definition</h5>
						<p>Declaration of a method that raises multiple faults</p>
					</div>
					<div class="div4">

<h5><a name="N102C9"></a>2.2.1.2 Relates To</h5>
						<p>VP1, VP2, VP3</p>
					</div>
					<div class="div4">

<h5><a name="N102D2"></a>2.2.1.3 Scenario Description</h5>
						<p>A web service interface method can fail due to several reasons.  The faults raised by the method may be semantically different from each other and further more, some of the faults may be standard faults defined for a group of web services.  For example, in an accounting system, there may be a general ?creation fault? defined for indicating the failure such as out of resources or PO already exists.  The creation of PO could also fail because the data provided to initialize the PO is invalid.  The web service method ?createPO? might then fail because of any of the reasons described above and may want to raise separate faults depending on the reason for failure.</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;message name="GenericCreationError"&gt;
	&lt;part name="reason" type="xsd:string"/&gt;
&lt;/message&gt;

&lt;message name="PODataValidationError"&gt;
	&lt;part name="inValidField" type="xsd:string"/&gt;
	&lt;part name="reason" type="xsd:string"/&gt;
&lt;/message&gt;

&lt;operation name="CreatePO"&gt;
	&lt;input message="CreatePOInput"/&gt;
	&lt;output message="CreatePOOutput"/&gt;
	&lt;fault name="CreationFault" message="GenericCreationError"/&gt;
	&lt;fault name="ValidationFault" message="DataValidationError"/&gt;
&lt;/operation&gt;
					</pre></td></tr></table>
					</div>
				</div>
				<div class="div3">

<h4><a name="service-level-attributes"></a>2.2.2 UC0004 Service Level Attributes[WS]</h4>
					<div class="div4">

<h5><a name="N102E6"></a>2.2.2.1 Scenario Definition</h5>
						<p>Declaration of service level attributes</p>
					</div>
					<div class="div4">

<h5><a name="N102EF"></a>2.2.2.2 Relates To</h5>
						<p>VP1, VP2, VP3</p>
					</div>
					<div class="div4">

<h5><a name="N102F8"></a>2.2.2.3 Scenario Description</h5>
						<p>Two web services, implementing the interface for ?looking up for insurance providers?, from different sources are offered in a registry.  One of the two services actually performs extensive data validation on the data provided, for example making sure that the zip codes in the address provided are valid?, while the other web service assumes that the data provided is valid and searches for insurance providers has already been validated and uses it to perform its search without any further validation.  The interface was developed by an industry consortium that agreed to reflect the data validation capability of the services as a service-level attribute.  Some intelligent registries may then actually allow search criteria that can be predicated on these service-level attributes or alternatively, the client application may check the value of the service level attribute itself at runtime to find out its value.  The service-level attribute may be mapped to accessor methods which can be invoked either by the intelligent registry as part of executing the search query or by the client application itself.</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;types&gt;
	&lt;complexType name="CompanyInfo"/&gt;
		&lt;element name="CompanyName" type="xsd:string"/&gt;
		&lt;element name="Address" type="xsd:string"/&gt;
	&lt;/complexType&gt;
	...
&lt;/types&gt;

&lt;portType name="InsuranceProviderPort"&gt;
	&lt;attribute name="version" type="xsd:string"/&gt;
	&lt;attribute name="validates" type="xsd:boolean"/&gt;
	&lt;attribute name="companyInfo" type="CompanyInfo"/&gt;

	&lt;operation name="ProvideQuote"&gt;
		&lt;input message="ProvideQuoteInput"/&gt;
		&lt;input message="ProvideQuoteOutput"/&gt;
		&lt;fault name="quoteFailed" message="ProvideQuoteError"/&gt;
	&lt;/operation&gt;
	...
&lt;/portType&gt;
						</pre></td></tr></table>
						<p>These attributes are part of the meta data of the service.  Although you could possibly model the meta data as operations, this meta data is modeled much more cleanly modeled as attributes.
						</p>
					</div>
				</div>
				<div class="div3">

<h4><a name="operational-level-attributes"></a>2.2.3 UC0005 Operation Level Attributes[WS]</h4>
					<div class="div4">

<h5><a name="N1030F"></a>2.2.3.1 Scenario Definition</h5>
						<p>Declaration of operational level attributes</p>
					</div>
					<div class="div4">

<h5><a name="N10318"></a>2.2.3.2 Relates To</h5>
						<p>VP1, VP2, VP3</p>
					</div>
					<div class="div4">

<h5><a name="N10321"></a>2.2.3.3 Scenario Description</h5>
						<p>In an advanced architecture where distributed transactions are supported, a web service may want to declare some of its operations as transactional as opposed to the entire interface being transactional.  A web service offering various financial related web services may be able to verify a buyer?s credit in a non-transactional manner but may require the client application to start a transaction before invoking the operation to prepare an invoice.  The target web service may have a declarator on the method specification that indicates that the operation for invoicing requires transaction.</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;operation name="ProvideQuote"&gt;

	&lt;attribute name="isTransactional" type="xsd:boolean"/&gt;

	&lt;input message="ProvideQuoteInput"/&gt;
	&lt;input message="ProvideQuoteOutput"/&gt;
	&lt;fault name="quoteFailed" message="ProvideQuoteError"/&gt;
&lt;/operation&gt;

						</pre></td></tr></table>
					</div>
				</div>
				<div class="div3">

<h4><a name="N1032F"></a>2.2.4 UC0029 Namespaces with data and interfaces [IS]</h4>
					<div class="div4">

<h5><a name="N10334"></a>2.2.4.1 Scenario Definition</h5>
						<p>To maintain namespaces through service providers and clients</p>
					</div>
					<div class="div4">

<h5><a name="N1033D"></a>2.2.4.2 Relates To</h5>
						<p>VP1, VP3</p>
					</div>
					<div class="div4">

<h5><a name="N10346"></a>2.2.4.3 Scenario Description</h5>
						<p>A service can have an OO model like this:</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>my.app.model.Address is a base class to represent
data my.app.impl.Address inherits my.app.model.Address my.app.model.AddressBook is an interface.  my.app.impl.AddressBook is an
implementation of my.app.model.AddressBook
</pre></td></tr></table>
						<p>It is possible to represent this model in WSDL and associated XML Schema <a href="#XMLSchema1">[XML Schema Part 1]</a> placing schema and interfaces in the proper XML namespaces. It has to be required that namespaces are not getting lost between service provider and the client. It should be part of WSDL compliance.</p>
						<p>Here is a brief example:</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;definitions xmlns:model="urn:my.app.model" xmlns:impl="urn:my.app.impl"&gt;
&lt;types&gt;
&lt;schema targetNamespace="urn:my.app.model"&gt;...
&lt;schema targetNamespace="urn:my.app.impl"&gt;...
&lt;/types&gt;
&lt;message targetNamespace="urn:my.app.model" ...
&lt;message targetNamespace="urn:my.app.impl" ...
&lt;portType targetNamespace="urn:my.app.model" ...
&lt;portType targetNamespace="urn:my.app.impl" ...
</pre></td></tr></table>
					</div>
				</div>
				<div class="div3">

<h4><a name="N10361"></a>2.2.5 UC0031 Versioning [IS]</h4>
					<div class="div4">

<h5><a name="N10366"></a>2.2.5.1 Scenario Definition</h5>
						<p>Specifying interface versioning</p>
					</div>
					<div class="div4">

<h5><a name="N1036F"></a>2.2.5.2 Relates To</h5>
						<p>VP1</p>
					</div>
					<div class="div4">

<h5><a name="N10378"></a>2.2.5.3 Scenario Description</h5>
						<p>A WS provider can describe versions of interfaces implemented by a service. Such as this</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;definitions xmlns:interface-latest="urn:myService-latest"
							xmlns:interface-ver1="urn:myService-ver1" ... &gt;
	&lt;binding targetNamespace="urn:myService-latest"
		version="2.0.0.0"&gt; ...
	&lt;binding targetNamespace="urn:myService-ver1"
		version="1.0.0.0"&gt; ...
	&lt;service name="myServiceService"&gt;
		&lt;port name="myService"
			binding="interface-latest:myServiceSoapBinding"&gt;
			...
		&lt;port name="myService"
			binding="interface-ver1:myServiceSoapBinding"&gt;
			...
	&lt;/service&gt;
</pre></td></tr></table>
						<p>WS client can bind to the necessary interface version. This way there is no ambiguity when WS provider changes service interfaces and client has created a static proxy that uses previous version of interfaces.</p>
						<p>WS provider can deprecate and remove interfaces as desired, and the client would know that. Client would send a SOAP request that would not be accepted (as namespaces do not match), as opposed to client trying to send a SOAP request that could be accepted, but improperly executed.</p>
					</div>
				</div>
				<div class="div3">

<h4><a name="N1038C"></a>2.2.6 UC0032 Classification system for operations [JR]</h4>
					<div class="div4">

<h5><a name="N10391"></a>2.2.6.1 Scenario Definition</h5>
						<p>Use case for DR053</p>
					</div>
					<div class="div4">

<h5><a name="N1039A"></a>2.2.6.2 Relates To</h5>
						<p>VP1 and VP3</p>
					</div>
					<div class="div4">

<h5><a name="N103A3"></a>2.2.6.3 Scenario Description</h5>
						<p>Imagine a component framework in which components and their operations
(building finally the component's functionality) should be described with WSDL.
In the framework the components are using operations from each other
dynamically: in the program code there is no "hard-wired" function call but
instead a "semantic description/reference" of what kind of operation to use,
which will be dissolved just in time before execution. With this "semantic
description" a search for suitable operations could be started in a (logical)
centralized registry (maybe with UDDI). The registry contains (WSDL)
information of all currently available components/operations within the
framework. Result of the search query are the concrete binding parameters
(protocol, URL, operation signature, etc.) of the matching operations.

Finding a suitable match _automatically_ (without manual/human interaction)
will be done by searching in the registered WSDL files for the specified
"semantic description". One half of this "semantic description" are the
parameters defined with complex XML schema types. The other one should be the
determination of the operation (i.e. its functionality). But only considering
the operation name has the same drawbacks as comparing parameters only by their
name (or even simple types like integer, string, etc.): only operations with
exactly the same name as chosen from the operation's programmer are returned.
So with introducing a kind of "type system" for operations (or maybe a
classification) would bring the benefit that the result set of the above
mentioned query could return operations with different names, but which are
implementing the same functionality/behavior. With this it would also be
possible to exchange one component (respectively their operation/s) with
another independently developed one, which has the same functionality but with
(maybe only slightly) different operation name(s) - and this without further
manual interaction.</p>
					</div>
				</div>
				<div class="div3">

<h4><a name="N103AD"></a>2.2.7 UC0033 Header Specification [WV]</h4>
					<div class="div4">

<h5><a name="N103B2"></a>2.2.7.1 Scenario Definition</h5>
						<p>Need to have a hint of how long it will take for the service to process the request.</p>
					</div>
					<div class="div4">

<h5><a name="N103BB"></a>2.2.7.2 Relates To</h5>
						<p>VP2</p>
					</div>
					<div class="div4">

<h5><a name="N103C4"></a>2.2.7.3 Scenario Description</h5>
						<p>My service invocation contains a routing header in which I specify the return path (the path I want the response to use to come back to me). I may want to provide a different routing path whether I expect the respond to come in one second or in two weeks. For example, for a very quick turnaround I might want to have the response sent directly to me via HTTP <a href="#RFC2616">[IETF RFC 2616]</a> post because I know I will have a listener available during the next 10 seconds, but if the processing is going to take days I'd rather have the reply go through another route, using always-on intermediary that can store the message for me until I am ready to receive it. In order to be able to choose the most appropriate return path, I need to find in the WSDL an indication of how long the service plans to take to fulfill my request.

Note: this use case is not about how to specify the use of a SOAP routing header. It is about how to provide in the WSDL information that allows someone to build the message in a smarter way (for example by optimizing the routing header) because s/he knows more about the expected completion time for the request.
</p>
						<p>Following is a sample of the routing header as specified according to SOAP binding of WSDL</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;binding...&gt;
	&lt;soap:binding ..../&gt;
	&lt;operation ... &gt;
		&lt;soap:operation .../&gt;
		&lt;input&gt;
			&lt;soap:body ... /&gt;
			&lt;soap:header message="some predefined message"
				part="a part of that message"/&gt;
		&lt;/input&gt;
	&lt;/operation&gt;
&lt;/binding&gt;
						</pre></td></tr></table>
					</div>
				</div>
				<div class="div3">

<h4><a name="N103D8"></a>2.2.8 UC0034B Specifying streaming [YF]</h4>
					<div class="div4">

<h5><a name="N103DD"></a>2.2.8.1 Scenario Definition</h5>
						<p>Specifying streaming with input or output</p>
					</div>
					<div class="div4">

<h5><a name="N103E6"></a>2.2.8.2 Relates To</h5>
						<p>VP1, VP2</p>
					</div>
					<div class="div4">

<h5><a name="N103EF"></a>2.2.8.3 Editor's Comment</h5>
						<p>It seems like this would require specifying header elements to indicate streaming</p>
					</div>
					<div class="div4">

<h5><a name="N103F8"></a>2.2.8.4 Scenario Description</h5>
						<p>A webcam is plugged in to a network. A user sends through the network an HTTP request to get the video. The webcam answers to this request by streaming the video to the user. The user sends another request to stop the streaming.

I think WSDL should provide a way to express that it will use streaming
at some point.
Streaming might be used at two levels:
   - at the protocol level : the service may  transmit the result by
streaming
   - at the data type level : the service may indicate that it will
receive/send streaming as input/output..</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;binding...&gt;
	&lt;soap:binding ..../&gt;
	&lt;operation ... &gt;
		&lt;soap:operation .../&gt;
		&lt;input&gt;
			&lt;soap:body ... /&gt;
			&lt;soap:header message="some predefined message" part="a part of that message"/&gt;
		&lt;/input&gt;
	&lt;/operation&gt;
&lt;/binding&gt;
						</pre></td></tr></table>
					</div>
				</div>
				<div class="div3">

<h4><a name="N10406"></a>2.2.9 UC0035 Extending PortType [JS]</h4>
					<div class="div4">

<h5><a name="N1040B"></a>2.2.9.1 Scenario Definition</h5>
						<p>Extend existing portTypes to make new ones by including and reusing features/behavior specified by the existing portTypes.</p>
					</div>
					<div class="div4">

<h5><a name="N10414"></a>2.2.9.2 Relates To</h5>
						<p>VP1, VP2</p>
					</div>
					<div class="div4">

<h5><a name="N1041D"></a>2.2.9.3 Scenario Description</h5>
						<p>Vertical standards organizations like the UPnP Forum <a href="#UPnP">[UPnP]</a> are defining
device-specific standards, ranging from home appliances, to
entertainment, to small office appliances. The UPnP Forum and others
would like to use WSDL as their machine-readable description language.</p>
						<p>A working committee within UPnP may wish to define a core set of
behaviors to be implemented by all devices of a particular type as well
as an extended set of behaviors to be implemented by advanced devices.
For example, imagine that an audio-visual working committee is defining
analog TV tuner functionality; to support standardized behavior in
inexpensive as well as expensive TV sets, they define two sets of
operations: a minimal set (like channel up / down) and an extended set
(like minimal plus jump to previous channel). Within WSDL, a natural way
for such a working committee to define these behaviors is to use port
types: a "basic tuner" port type with the core operations and an
"extended tuner" port type that has the superset.</p>
						<p>This has the mildly awkward disadvantage that the definition of the
"extended tuner" must re-list each of the operations previously defined
in "basic tuner".</p>
						<p>When building a UPnP TV device, a vendor may wish to include two analog
TV tuners to support a feature like picture-in-picture. Within WSDL, a
natural way to expose this is as two ports of the correct type. This
works as expected if the device includes two analog tuners with only
basic functionality: there are two ports, each of type "basic tuner".
Clients that wish to control the device can parse the WSDL for the
device and correctly recognize that the device supports two tuners with
the basic functionality.</p>
						<p>However, consider the case where the vendor wishes to include two analog
tuners with extended functionality. At a minimum, within the WSDL for
that device, they need to include two ports of type "extended tuner". In
order to support down-level clients (say written only to use "basic
tuner"), a vendor would be inclined to also include two ports of type
"basic tuner". However, such WSDL would likely be very confusing to a
client: how many tuners does the device actually contain? </p>
						<p>For the sake of completeness, note working committees in the UPnP Forum
also define standards for how many of each port type are in a type of
device. Thus, the vendor's dilemma is also encountered within the
standard WSDL descriptions a working committee would produce.
</p>
						<p>A possible solution to this would be to allow one port type to derive
from another by extending the set of operations supported. The
description of the "extended tuner" would not have to re-list the
operations defined by the "basic tuner", but more importantly, the
dual-tuner device could list just two ports of type "extended tuner",
and down-level clients could look at the derivation of the port type to
recognize the "basic tuner". </p>
					</div>
				</div>
			</div>
			<div class="div2">

<h3><a name="N1043D"></a>2.3 Service Reference</h3>

				<div class="div3">

<h4><a name="N10444"></a>2.3.1 UC0027 References [IS]</h4>
					<div class="div4">

<h5><a name="N10449"></a>2.3.1.1 Scenario Definition</h5>
						<p>To support passing references to web services as operation input or output.</p>
					</div>
					<div class="div4">

<h5><a name="N10452"></a>2.3.1.2 Relates To</h5>
						<p>VP1, VP2, VP3</p>
					</div>
					<div class="div4">

<h5><a name="N1045B"></a>2.3.1.3 Scenario Description</h5>
						<p>A WS provider can define operations that return and/or take as a parameter a reference to another WS interface.</p>
						<p>Here is an example of extended attribute definitions and inclusion. </p>
						<p>The definition would look as follows:</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;definitions ... xmlns:ref="http://schemas.xmlssoap.org/wsdl/ref&gt;
&lt;message name="..."&gt;
	&lt;part name="param" type="ref:ref"&gt;
&lt;message&gt;
</pre></td></tr></table>
						<p>A schema for http://schemas.xmlssoap.org/wsdl/ref is as follows :</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;schema targetNamespace="http://schemas.xmlssoap.org/wsdl/ref" xmlns:ref="http://schemas.xmlssoap.org/wsdl/ref"&gt;
	&lt;complexType name="ref"&gt;
	&lt;all&gt;
		&lt;element name="description" nillable="true" type="xsd:string"/&gt;
		&lt;element name="service" type="xsd:QName"/&gt;
		&lt;element name="port" nillable="true" type="xsd:string"/&gt;
	&lt;/all&gt;
	&lt;/complexType&gt;
	&lt;element name="ref" type="ref:ref"/&gt;
&lt;/schema&gt;
</pre></td></tr></table>
						<p>Then a WS client can use references to the interfaces as follows:</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>MyExtSvc esvc = new MyExtSvc(service.myMethodReturnungRef(...))</pre></td></tr></table>
						<p>The underlying WS framework would support instantiation of a service based on reference (like most already instantiate based on an endpoint URL).</p>
						<p>I believe systinet does something similar, but unless it's mandated by the WSDL standard it is as good as private app-specific extension.</p>
					</div>
				</div>
			</div>

			<div class="div2">

<h3><a name="N10486"></a>2.4 Meta data</h3>
				<div class="div3">

<h4><a name="N1048B"></a>2.4.1 UC0026 Service Metadata [IS]</h4>
					<div class="div4">

<h5><a name="N10490"></a>2.4.1.1 Scenario Definition</h5>
						<p>Capture service related meta data</p>
					</div>
					<div class="div4">

<h5><a name="N10499"></a>2.4.1.2 Relates To</h5>
						<p>VP1, VP2</p>
					</div>
					<div class="div4">

<h5><a name="N104A2"></a>2.4.1.3 Scenario Description</h5>
						<p>A WS provider can decorate various elements of the service description with custom attributes. These attributes may be application specific and would be described by the WS provider in an additional documentation. Such custom attributes may be defined in a specific schema. WS provider may include such extra information as owner e-mail, link to SLA, security and session requirements for a particular message, etc.</p>
						<p>Here is an example of extended attribute definitions and inclusion. </p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>&lt;descriptions ... &gt;
&lt;extend xmlns:myExt="..."&gt;
&lt;myExt:owner id="owner1" email="myadmin@mycorp.com/&gt;
&lt;myExt:sec id="sec1" signatureRequired="yes"/&gt; &lt;myExt:sess id="sess1" cookie="MYCTX"/&gt;
&lt;/extend&gt;
&lt;types&gt;...
&lt;message extend="sec1 sess1" ... &lt;portType... &lt;binding ... &lt;service extend="owner1" ...</pre></td></tr></table>
						<p>A WS client can interrogate the metadata attributes as follows:</p>
						<table summary="Example" width="100%" bgcolor="#99ffff" border="1" cellpadding="5" class="eg"><tr><td><pre>NodeList ext = service.getExtend();</pre></td></tr></table>
						<p>Similarly for message descriptions.</p>
					</div>
				</div>
			</div>
			<div class="div2">

<h3><a name="N104BE"></a>2.5 Miscellaneous</h3>

				<div class="div3">

<h4><a name="N104C5"></a>2.5.1 UC0034A Obtaining WSDL from the web service itself [YF]</h4>
					<div class="div4">

<h5><a name="N104CA"></a>2.5.1.1 Scenario Definition</h5>
						<p>This scenario provides requires web services to have predefined method for obtaining wsdl from the web service</p>
					</div>
					<div class="div4">

<h5><a name="N104D3"></a>2.5.1.2 Relates To</h5>
						<p>VP1</p>
					</div>
					<div class="div4">

<h5><a name="N104DC"></a>2.5.1.3 Scenario Description</h5>
						<p>A webcam is plugged in to a network. This webcam can describe its
services through a pre-loaded WSDL file.
I think it is important to keep in mind that WSDL files may be published
by such devices (where space is valuable and/or read-only) as well as by
big servers.
It should also be possible for a user to contact the webcam and get its
WSDL description. Should we make a standard way to retrieve from  a web
service its description (like making an HTTP get request to an HTTP web
service will trigger the web service to send its description)? Is it let
to a higher level ?
						</p>
					</div>
				</div>
				<div class="div3">

<h4><a name="N104E6"></a>2.5.2 UC0036 Storage and Retrieval of WSDL in Registries and Repositories [AR]</h4>
					<div class="div4">

<h5><a name="N104EB"></a>2.5.2.1 Scenario Definition</h5>
						<p>The WSDL specification should define a notion of equivalence of definitions
that would be used by registry and repository implementors.</p>
					</div>
					<div class="div4">

<h5><a name="N104F4"></a>2.5.2.2 Relates To</h5>
						<p>VP1</p>
					</div>
					<div class="div4">

<h5><a name="N104FD"></a>2.5.2.3 Scenario Description</h5>
						<p>WSDL documents will be registered in registries such as <a href="#UDDI">[UDDI]</a> and stored in
repositories. The operations of storage and retrieval must preserve the
meaning of the WSDL.</p>
						<p>The definitions in a WSDL document do not exactly match the entities stored in a UDDI registry. There is a Best Practices document <a href="#UDDIBP">[UDDI Best Practices]</a> that specifes a mapping between WSDL and UDDI. When a service described by a WSDL document is registered in UDDI, some of the WSDL definitions are converted to UDDI entities. When a user discovers a service in a UDDI registry, processors will extract some entities from UDDI and convert them to WSDL definitions. The result of storing and retrieving WSDL information must preserve its meaning.</p>
						<p>Similarly, WSDL documents may be stored in repositories that stored them in
a non-WSDL format, for example a relational database. When the documents
are retrieved as WSDL their meaning must be preserved.</p>
						<p>The WSDL specification should define a notion of equivalence of definitions
that would be used by registry and repository implementors.</p>
					</div>
				</div>
			</div>
		</div>
	</div>
	<div class="back">
    <div class="div1">

<h2><a name="references"></a>A References</h2>
      <dl>

			<dt class="label"><a name="WSDL11"></a>WSDL 1.1</dt><dd>
			  <a href="http://www.w3.org/TR/2001/NOTE-wsdl-20010315"><cite>Web Services Description Language (WSDL) 1.1</cite></a>, E. Christensen,
			  F. Curbera, G. Meredith, and S. Weerawarana, Authors. World
			      Wide Web Consortium, 15 March 2002.
			  This version of the Web Services Description Language Specification is
			  http://www.w3.org/TR/2001/NOTE-wsdl-20010315. The <a href="http://www.w3.org/TR/wsdl">latest version of Web
			    Services Description Language</a> is available at
			  http://www.w3.org/TR/wsdl.
			</dd>

			<dt class="label"><a name="UDDI"></a>UDDI</dt><dd>
			  <a href="http://uddi.org/specification.html"><cite>UDDI</cite></a>, Version 1 and 2 specifications can be found at http://uddi.org/specification.html.
			</dd>

			<dt class="label"><a name="UDDIBP"></a>UDDI Best Practices</dt><dd>
			  <a href="http://www.uddi.org/bestpractices.html"><cite>UDDI Best Practices</cite></a>
			</dd>

			<dt class="label"><a name="UPnP"></a>UPnP</dt><dd>
			  <a href="http://www.upnp.org/"><cite>UPnP Forum</cite></a>
			</dd>

      <dt class="label"><a name="RFC2616"></a>IETF RFC 2616</dt><dd>
        <a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext Transfer Protocol - HTTP/1.1</cite></a>,
        R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
        P. Leach, T. Berners-Lee, Authors. Internet Engineering Task
        Force, June 1999. Available at
        http://www.ietf.org/rfc/rfc2616.txt.
      </dd>

      <dt class="label"><a name="SOAP12"></a>SOAP 1.2 Part 1</dt><dd>
        <a href="http://www.w3.org/TR/2001/WD-soap12-part1-20011217/"><cite>SOAP Version 1.2 Part 1: Messaging
        Framework</cite></a>, M. Gudgin, M. Hadley, J-J. Moreau, and
        H. F. Nielsen, Editors. World Wide Web Consortium, 17 December
        2001. This version of the SOAP Version 1.2 Part 1 Specification
        is http://www.w3.org/TR/2001/WD-soap12-part1-20011217. The <a href="http://www.w3.org/TR/soap12-part1/">latest version of SOAP
        Version 1.2 Part 1</a> is available at
        http://www.w3.org/TR/soap12-part1.
      </dd>

      <dt class="label"><a name="XMLSchema1"></a>XML Schema Part 1</dt><dd>
        <a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502"><cite>XML Schema Part 1: Structures</cite></a>, H. Thompson,
        D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web
        Consortium, 2 May 2001. This version of the XML Part 1
        Recommendation is http://www.w3.org/TR/2001/REC-xmlschema-1-20010502. The <a href="http://www.w3.org/TR/xmlschema-1/">latest version of XML
        Schema Part 1</a> is available at
        http://www.w3.org/TR/xmlschema-1.
      </dd>

      <dt class="label"><a name="ebXML"></a>ebXML</dt><dd>
        <a href="http://www.ebxml.org/"><cite>ebXML</cite></a>
      </dd>


      </dl>
    </div>
		<div class="div1">

<h2><a name="N105C7"></a>B Change Log (Non-Normative)</h2>
			<table border="1" cellpadding="2" cellspacing="0">
				<tbody>
					<tr>
						<th rowspan="1" colspan="1">Date</th>
						<th rowspan="1" colspan="1">Editor</th>
						<th rowspan="1" colspan="1">Change</th>
					</tr>

					<tr>
						<td rowspan="1" colspan="1">21 Feb 2002</td>
						<td rowspan="1" colspan="1">WS</td>
						<td rowspan="1" colspan="1">Created</td>
					</tr>
					<tr>
						<td rowspan="1" colspan="1">13 March 2002</td>
						<td rowspan="1" colspan="1">WS</td>
						<td rowspan="1" colspan="1">Grouped scenarios in related topics</td>
					</tr>
					<tr>
						<td rowspan="1" colspan="1">19 March 2002</td>
						<td rowspan="1" colspan="1">WS</td>
						<td rowspan="1" colspan="1">Added Sandeep as an editor</td>
					</tr>
					<tr>
						<td rowspan="1" colspan="1">20 March 2002</td>
						<td rowspan="1" colspan="1">SK</td>
						<td rowspan="1" colspan="1">Added View Point 3 and minor spelling fixes</td>
					</tr>
					<tr>
						<td rowspan="1" colspan="1">27 March 2002</td>
						<td rowspan="1" colspan="1">WS</td>
						<td rowspan="1" colspan="1">Added WSDL samples to use cases</td>
					</tr>
					<tr>
						<td rowspan="1" colspan="1">3 April 2002</td>
						<td rowspan="1" colspan="1">WS</td>
						<td rowspan="1" colspan="1">Added more WSDL samples and reorganized use cases</td>
					</tr>
					<tr>
						<td rowspan="1" colspan="1">3 April 2002</td>
						<td rowspan="1" colspan="1">SK</td>
						<td rowspan="1" colspan="1">Revised Introduction and added some samples and comments to the messaging subsection.</td>
					</tr>
					<tr>
						<td rowspan="1" colspan="1">22 April 2002</td>
						<td rowspan="1" colspan="1">WS</td>
						<td rowspan="1" colspan="1">Removed use cases UC0016-17, UC0020-22, UC0024, UC0012, UC0018-19, UC0023, UC0007-11, UC0013-14</td>
					</tr>
					<tr>
						<td rowspan="1" colspan="1">23 April 2002</td>
						<td rowspan="1" colspan="1">WS</td>
						<td rowspan="1" colspan="1">Added more detail to UC0033</td>
					</tr>
					<tr>
						<td rowspan="1" colspan="1">23 April 2002</td>
						<td rowspan="1" colspan="1">JM</td>
						<td rowspan="1" colspan="1">Pubrules compliance: updated status, copyright, misc front matter</td>
					</tr>
					<tr>
						<td rowspan="1" colspan="1">16 May 2002</td>
						<td rowspan="1" colspan="1">WS</td>
						<td rowspan="1" colspan="1">Corrected spellings and grammer, added UC0035 and UC0036 and addressed other feedback</td>
					</tr>
				</tbody>
			</table>
		</div>
	</div>
</body></html>