Re: Introduction section

Steve Ross-Talbot wrote:

> Monica,
>
> I wanted to run this past you to see if the rewrite (clarification of 
> contract) was acceptable? If not what do I need to do to make it so.
>
> The Transaction thing I am still mulling over and hope to do something 
> later today with a view to sending it this evening (mytime).

mm1: See attached some comments (in pdf notes).

>
> Cheers
>
> Steve T
>
>------------------------------------------------------------------------
>
>Contracts - DONE
>Transactions - TDB
>
>2 Introduction
>
>The description of interactions among Web Services _ especially with regard to the exchange of messages, their composition, and the sequences in which they are transmitted and received - is an especially important problem. These interactions may take place among groups of services which, in turn, make up a larger, composite service, or which interact across organizational boundaries in order to obtain and process information. The problems of Web Services choreography are largely focused around message exchange and sequencing these messages in time to the appropriate destinations. In order to fulfill the needs of the Web Services community, these aspects of Web Services must be developed and standardized in an interoperable manner, taking into account the needs of each individual service as well as those of its collaborators and users.          
>
>This document describes a set of requirements for Web Services choreography based around a set of representative use cases, as well as general requirements for interaction among Web Services. This document is intended to be consistent with other efforts within the W3C Web Services Activity.          
>
>2.1 What is Web Services Choreography?          
>
>Web Services Choreography concerns the observable interactions of services with their users. Any user of a Web Service, automated or otherwise, is a client of that service. These users may, in turn, be other Web Services, applications or human beings. Transactions among Web Services and their clients must clearly be well defined at the time of their execution, and may consist of multiple separate interactions whose composition constitutes a complete transaction. This composition, its message protocols, interfaces, sequencing, and associated logic, is considered to be a choreography. 
>
>A choreography description is a multi-party contract that describes the external observable behavior across multiple clients (which are generally Web Services but not exclusively so) in which external observable behavior is defined as the presence or absence of messages that are exchanged between a Web Service and it's clients.
>
>We use the term contract in specific way which is defined as a document that described the acceptable external behaviour between multiple clients where a contract in this sense has no legal standing. A contract in our sense is simply a technical contract that describes external observable behaviour. A client that conforms to a contract is guaranteed to interoperate correctly (where correctness is defined by the contract). A client that does not conform to the contract has no such guarantee but equally there is no legal consequence for such failure to comply. Thus a contract, in this sense, provides a clear unambiguous, description of expected external observable behaviour for a client within a population of interacting clients.
>
>A choreography language is a language in which such a contracts are described.
>
>2.2 How is a Choreography used?
>
>A choreography description may be used to generate the necessary executable code skeleton that can be said to implement the required external observable behavior for that Web Service. Thus a choreography description that is used to describe the multi-party contract between a travel agent and a number of hotel companies might be used by any potential participant  to generate a code skeleton for a web service that can be guaranteed to be interoperable with that particular travel agent.
>
>A choreography description may also be used to aid the testing of Web Services through the generation of test messages that could be sent to a Web Service by means of an appropriate vendor specific tool that reads the choreography description and manages the test interaction according to the choreography description.
>
>A choreography description may also be used to police the multi-party contractual behavior amongst a collection of Web Services. In such a scenario each hotel may load a choreography description into a vendor specific tool which informs them of any breaches of the behavioral contract so that they and the Web Services that are participating can be informed of such breaches and the necessary modification made to the offending Web Services.
>
>A choreography description may also be used to show the absence of deadlocks and livelocks in the behavioral contract. In this sense a choreography description acts as a model of the behavior across a number of Web Services which in turn can be subject to static analysis to show that if and only if the underlying Web Services behave according to the contract that the interaction between the Web Services will be free from deadlock and livelock.
>
>Finally a choreography description may be used by vendor specific tools to show that an abstract protocol for a single Web Service conforms to some participant Web Service defined in a choreography description, either in full or in part. 
>
>2.3 What are the benefits of a choreography language?
>
>The Web Services Choreography working group believes that all five uses of a choreography description necessitate the existence of a standardised language for the description of choreographies. The benefits of such an approach;
>    * will enable more robust Web Services to be constructed;
>    * will enable more effective interoperability of Web Services through behavioral multi-party contracts, which are choreography descriptions;
>    * will reduce the cost of implementing Web Services by ensuring conformance to expected behaviour;
>    * will increase the utility of Web Services as they will be able to be shown to meet contractual behavior;
>
>  
>
>------------------------------------------------------------------------
>
>This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.
>

Received on Tuesday, 2 December 2003 10:44:23 UTC