The XML...

Hi Takao,

Here's the XML for the two drawings now on the website. Insert in section 2.1 ("basic framework").

--
<div2>
<head>Basic Framework (description of process)</head>
<graphic source="./WSTF001.jpg" id="WSTF001" alt="WSTF001"/>
<p>There are three basic parts to a Web services interaction. The first part is discovery and configuration. The second part is the request. The third part is the optional response. In the diagram above, the purple arrows are the discovery, the blue arrows are the request, and the red arrows are the response.</p>
<p>An important aspect of Web services is distinguishing between the actual "service" (the function, method, or other logic that actually does something) and the Web service "provider" or "agent" (the process that receives and emits SOAP messages). In the diagram above, we show the "client process" and the "requester agent" as being in one machine, while the "provider agent" and the "actual service" are in separate machines or processes. Neither of these cases is necessarily the case: the provider agent may host the service inside its process, just as the client process and requester agent might be on separate machines.</p>
<p>Discovery</p>
<p>Discovery of Web services can be done in many ways. For example, the system administrators on either end of the transaction may just have a conversation or exchange WSDL files (Web service descriptions). </p>
<p>Or a UDDI registry or other automated mechanism might be used. </p>
<p>In any case, the Web service description contains the information about how to invoke the service and what, if any, response to expect. This includes the data structures passed to the service itself and the data structures returned (if any). It may also contain contextual information, generally contained in headers, such as the information required for quality-of-service, security, transactionality, and so forth.</p>
<p>Each service or set of services may provide a variety of ways to be invoked, with different URLs, ports, and other information distinguishing the various invocations. Each specific collection (single way of invoking a Web service), consisting of a URL, request and response  is called a "binding". This information is typically generated by the "provider agent" and is fed to the "requester agent" in order to configure the requester to invoke the service.</p>
<p>Request</p>
<p>The request goes, as shown, through several stages:</p>
<olist>
<item><p>The caller invokes the service in the requester agent somehow.</p></item>
<item><p>The requester agent formulates the SOAP message that will invoke the service. It uses the WSDL to create and populate the message body and any headers, attachments, and so forth as set out in the description.</p></item>
<item><p>The SOAP message is dispatched over the transport (typically HTTP, but not always so) to the URL in the WSDL. This generally represents the provider agent, but may also involve an intermediary server which forwards the request.</p></item>
<item><p>The provider agent receives and decodes the message. This may result in an error, in which case a SOAP Fault message may be generated as a response.</p></item>
<item><p>If the SOAP message was decoded successfully, recognized, and valid for a service supported by the provider agent (e.g. it was not in error), the provider agent will now attempt to invoke the service itself.</p>
<p>Note that invoking the service may result in an error (if, for example, the service isn't currently available) and also that the service itself might result in an error.</p></item>
</olist>
<p>Response</p>
<p>Not all services generate a response, either when an error is encountered or with a successful result. If the message exchange pattern calls for a response, then the following steps apply:</p>
<olist>
<item><p>The service returns its result(s) to the provider agent. This may, as noted above, be a successful result or an error.</p></item>
<item><p>The provider agent formulates the SOAP message that will be the response. The results of the service are used to build any message body and the provider agent fills in any additional header information.</p></item>
<item><p>The SOAP message is then returned over the transport to the requester agent. Note that from the perspective of the provider agent, this may be an intermediary.</p></item>
<item><p>The requester agent receives the response and decodes it.</p></item>
<item><p>The results are passed or made available to the client process.</p></item>
</olist>
</div2>
--

More drawings coming.

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

Received on Monday, 24 November 2003 18:56:08 UTC