As the momentum around Web Services grows, the need for effective mechanisms to co-ordinate the interactions among Web Services and their users becomes more pressing. The Web Services Choreography Working Group has been tasked with the development of such a mechanism in an interoperable way.
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.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the second W3C Working Draft of the Web Services Choreography Requirements document.
It is a chartered deliverable of the Web Services Choreography Working Group, which is part of the Web Services Activity. Although the Working Group agreed to request publication of this document, this document does not represent consensus within the Working Group about Web Services choreography requirements.
This document is in a state of perpetual change. Feedback on this document is sought by the Working Group.
Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
1 Mission Statement
2.1 What is Web Services Choreography?
2.2 How is a Choreography used?
2.3 Benefits of Choreography Language
2.4 Conventions used in this document
3 Use Cases
3.1 Use Case Descriptions
3.1.1 C-UC-001 -Travel Agent
18.104.22.168 Primary Description
22.214.171.124 Variation on the use case
126.96.36.199.1 Variation 1
188.8.131.52.2 Variation 2
184.108.40.206.3 Variation 3
220.127.116.11.4 Variation 4
18.104.22.168.5 Variation 5
22.214.171.124.6 Variation 6
3.1.2 C-UC-002 - Quote Request
126.96.36.199 Primary description
188.8.131.52 Variations on the use case
184.108.40.206.1 Variation 1
220.127.116.11.2 Variation 2
4 Critical Success Factor Analysis
4.1 CSF Analysis Goals
4.2 Critical Success Factors
5 Choreography Requirements
6 Correlation of Use Cases and Requirements
6.1 Use Cases and Requirements Cross-Reference
6.2 Requirements and Use Cases Cross-Reference
6.3 Requirements Coverage
7 Appendix A - References
7.1 Normative References
7.2 Informative References
8 Appendix B - Acknowledgements
The mission of the W3C Web Services Choreography Working Group is to define a language based on WSDL 2.0, that can describe a peer-to-peer global model for cross-enterprise interactions and their semantics through the composition of web services that are independent of any specific programming language.
The description of interactions among Web Services in particular with regard to the exchange of messages, their composition, and the sequences in which they are transmitted and received - is an 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. In order to gather requirements for Web Services Choreography, the working group has currently chosen to follow two paths toward this end. The first means of gathering requirements consists of examination of member-submitted use cases, from which requirements may be inferred. The second methods involves the use of the Critical Success Factor analysis methodology.
This document is intended to be consistent with other efforts within the W3C Web Services Activity.
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. A specific set of interactions maybe related over time to some form of collaboration grouping that is initiated at some source and runs through a set of Web Services and their client. We use the term "collaboration group" as a generic term that may encompass the concept of a "business transaction", an "ACID transaction" or a "cohesion". Thus for the purpose of clarity we define a collaboration group among Web Services and their clients as a specific set of observable interactions to which further meaning maybe attached.
A choreography description is a multi-party contract that describes from global view point 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.
A choreography description language (CDL) is the means by which such a technical contract is described.
The main use of a choreography description is to precisely define the sequence of interactions between a set of cooperating web services in order to promote a common understanding between participants and to make it as easy as possible to:
promote a common understanding between WS participants;
automatically validate conformance;
increase robustness; and to
generate code skeletons.
A choreography description may be used to generate the necessary code skeletons that can be said to implement the required external observable behavior for that Web Service. For example, 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 participating Web Services through the generation of test messages that could be sent to participants 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 validate the multi-party observable interactions amongst a collection of Web Services. For example, a hotel may load a choreography description into a vendor specific tool which informs them of any breaches of the cherography.
A choreography description may also be used to show the presence of usefull properties such as lock freedom and leak freedom 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 exhibit these properties.
The Web Services Choreography working group believes that all uses of a choreography description necessitate the existence of a standardized 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 behavior;
will increase the utility of Web Services as they will be able to be shown to meet contractual behavior.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
A few words on the naming convention used here and throughout this document: all use cases and requirements are labeled according to the following convention:
[D-] indicates that the item is in a draft state
(C) indicates Candidate status.
(G|CSF|R|UC|) is one of Goal, Critical Success Factor, Requirement, Use Case.
mmnn where, mm indicates the section number and nn is sequence number of the item.
Please note that due to the changing nature of requirements analysis, numbering of requirements and use cases may not always reflect sequential order.
It is intended that the use cases presented here are to include the widest possible number of requirements using the fewest possible number of use cases.
The use cases included here are meant to be representative, meaning that the general concepts are common to many possible use cases across a broad array of organizations.
A travel agent wants to offer to customers the ability to book complete packages that may consist of services offered by various providers. The available services may include: air travel, train travel, bus tickets, hotels, car rental, excursions and other services such as insurance.
The goal of the consumer is to get the best combination of services and prices suiting their needs. The travel agent tries to maximize customer satisfaction and sell packages. Service providers aim to sell as many products as possible. Credit card companies guarantee and perform payments for purchased products.
In this scenario, service providers offer Web Services that could be used by the Travel agent to query their offerings and perform various tasks such as reservations. Credit card companies provide services to guarantee payments made by consumers. The client should be able to query, reserve and purchase any available service. The basic steps of the interaction are listed below:
The client interacts with the travel agent to request information about various services.
Prices and availability matching the client requests are returned to the client. The client can then perform one of the following actions:
The client can refine their request for information, possibly selecting more services from the provider (Repeat step 2). OR
The client may reserve services based on the response, OR
The client may quit the interaction with the travel agent.
When a customer makes a reservation, the travel agent then checks the availability of the requested services with each service provider.
All services are available, in which case they are reserved. OR
For those services that are not available, the client is informed.
Given alternative options for those services. OR
Client is advised to restart the search by going back to step 1.
Go back to step 3.
For every relevant reserved service the travel agent takes a deposit for the reservation. A credit card can be used as a form of deposit
The client is then issued a reservation number to confirm the transaction.
Between the reservation time and the final date for confirmation, the client may modify the reservation. Modifications may include cancellation of some services or the addition of extra services.
Client is expected to fully pay for those relevant services that require full payment prior to final confirmation.
The use case is illustrated in the figure below.
Need to facilitate cancellation of orders and exception handling.
Needs callbacks to be able to express asynchronous interactions such as credit checking in a credit card company or availability from an airline.
Needs hierarchical composition to be able to reuse established choreographies such as that used by a credit card company.
Needs reference passing to enable the car hire company to interact with the credit card company on behalf of the user.
Need to demarcate transactional boundaries in order to define the collaboration boundaries in order to provide guidance on the underlying infrastructure required to implement the collaboration.
Need variable timeouts to model different interactions that have a different time-to-live. For instance, each carrier may impose a different limitation on the lifetime of a pending reservation.
Need to be able to express concurrent paths in order to check availability of services at multiple service providers.
The travel agency might use a choreography definition internally as a documented model for its entire reservation booking process. The choreography definition language would need to present a multi-party global view of the reservation choreography, depicting the communication amongst the travel agent and all its various partners. Further, the definition language would need to support the addition of annotation or comments to the various elements of a choreography, in order to fully describe the behavior of the global choreography.
Requirements for variation 1
There MUST be a mechanism for adding free form annotation or comments to a choreography description.
A CDL must support the description of a multi-party global model.
The travel agent might assist new service providers to join its "network" by providing them with a choreography description outlining their communication responsibilities. The choreography definition language should support the construction of a global model (see above) and allow choreographies to reference one another, thus providing composition.
For instance, the travel agent would share a "credit check" choreography with a new credit bureau, and the travel agent's internal global choreography would simply include an instruction to "call credit check" choreography. The global choreography could be composed of calls to many such nested choreographies. This has the added benefit of making the travel agent's global choreography modular and easier to understand.
Optionally, the travel agent could share the entire global choreography with the new credit bureau, withholding nested choreographies that details its interaction with other parties, such as airlines and rental car companies. This takes advantage of hierarchical composition to provide information hiding in contexts where partial information loss is appropriate.
Requirements for variation 2
A CDL must facilitate decomposition to enable choreography descriptions to reference each other.
Some level of validation of a hierarchically composed choreography definition should be possible even when some or all nested choreographies are missing, in order to support information hiding by the use of hierarchical composition.
Choreographies must be uniquely named.
In order to protect against out-of-sequence messaging, a choreography participant might use a choreography definition to provide runtime validation of message typing and sequencing. When messages arrive they are checked for appropriate sequencing and, if the check fails, an exception is issued.
A car rental agency might wish to protect its backend systems from potential corruption by out-of-sequence messages; for instance, a reservation being cancelled before it's ever placed. The corresponding action might be to respond to the offending document with an error message.
This runtime validation and exception generation is the responsibility of each participant; however, the choreography definition language must not preclude the implementation of such a feature.
Requirements for variation 3
Failure to adhere exception MAY be generated by a choreography participant.
In some cases, there will be system or infrastructure errors. For example, when confirming the travel itinerary, it may happen that one or more of the parties fails and are not immediately re-contactable. Depending on the urgency and importance of the travel services offered by the crashed parties, some form of recovery or correction may be required. In some cases it may be necessary to wait for the crashed parties to become active again, and to replay the messages back to them from some pre-defined checkpoint. The ability to demarcate such checkpoints is required in order to support this sort of scenario.
Requirements for variation 4
Needs exception handling to be able to express observable actions to take on receipt of an exception message.
Needs timeouts to be able to express time to live on reservations.
A CDL shall facilitate the demarcation of observable actional behavior in order to define collaboration boundaries and provide guidance to the underlying infrastructure (for example, recovery, replay messages etc.).
Need to be able to model retries and timeouts and the ability to choose different paths based on which timeout expires first.
When interacting with the various parties, a number of application errors could occur. For example, between being offered services to a certain destination and confirming those services, it is entirely possible that the destination is withdrawn from sale for some travel advisory reason. When the client goes to book such services this should result in a set of error messages, that signify some erroneous state. Depending on how the actual web services are defined, these errors may simply be specific WSDL operations, or may be defined as WSDL faults; which is chosen is a web service design issue.
Requirements for variation 5
A CDL shall support the description of choreography specific errors.
A CDL shall support the description of WSDL faults.
In this variation of the Travel Agent use case most of the main carriers (airlines) have in place a robust messaging infrastructure that delivers high quality robust connections that ensure guaranteed delivery. However the rise of budget airlines means that a new class of carriers have become part of the overall offering from travel agents where the messing infrastructure is no where near as reliable.
Fortunately the same choreography description can be used for both classes of carrier and the only thing that needs to change on both sides of the connection is for the participants to bind to the underlying messaging protocol available.
Also in this variation each carrier has different correlation keys that are used to match messages that belong to a specific transaction. The choreography that is used across the various carrier types is left unchanged with only the binding to correlation different across them. For each instance of a choreography the choreography description, on instantiation with a participant, bind the appropriate correlation mechanism in to the choreography so that it may be followed. Binding on a per participant basis enables the choreography to use whatever correlation mechanism is required between any two participants.
Requirements for variation 6
There should be a means to describe the differing QoS as applied to messaging.
There should be a means to describe the differing correlation mechanisms as applied to messaging.
In this use case a buyer interacts with multiple suppliers who in turn interact with multiple manufacturers in order to get a quote for some goods or services. A concrete example might be for a company that wishes to purchase a fleet of cars from automobile suppliers which in turn request quotes for specific bill or material items from their component manufacturers. The basic steps of the interaction are listed below:
A buyer request a quote from a set of suppliers.
All suppliers receive the request for quote and send requests for bill of material items to their respective manufacturers.
The suppliers interact with their manufacturers to build their quotes for the buyer. The eventual quote is then sent back to the buyer.
The buyer agrees with one or more of the quotes and places the order or orders. OR
The buyer responds to one or more of the quotes by modifying the quotes and sending them back to the relevant suppliers.
The suppliers respond to a modified quote by agreeing to it and sending a confirmation message back to the buyer. OR
The supplier responds by modifying the quote and sending it back to the buyer and the buyer goes back to step 4. OR
The supplier responds to the buyer rejecting the modified quote. OR
The quotes from the manufacturers need to be renegotiated by the supplier. Go to step 3.
The use case is illustrated in the figure below.
The ability to repeat the same set of interactions is needed. The interactions between supplier and manufacturers need only be defined once and then repeated for each relevant supplier manufacturer pairing.
Needs participant sets that may be bounded at design time, at runtime, or not at all. For instance, the set of suppliers may be determined when the choreography is designed, when the choreography is instantiated, or may be completely dynamic as the choreography progresses.
Needs (observable) transactional boundaries to facilitate recovery in the event of a participant failure.
Needs to be able to reference a choreography from within a choreography to support recursive behavior such as a manufacturer placing an order with its supplier.
In this variation of the Quote Request use case a new manufacturer wishes to participate in the overall supply chain. They manufacture a component in a new way that makes them very competitive with their rivals and the suppliers certainly wish them to participate.
In order for them to participate they look for tools that can be used in conjunction with the existing CDL descriptions that the suppliers use in order to generate the web services required. In this case they use their preffered IDE with a new W3C CDL plug-in. The tool imports the CDL description and generates the necessary Java code skeletons for the relevant Web Services. This enables the new manufacturer to build the necessary web services to participate in the supply chain at a much lower entry cost that would have been possible otherwise.
Having created the necessary Web Services, the CDL IDE plug-in uses the CDL document to generate test messages that are then played into the newly created Web Services. This further cuts the cost of this work and ensures that the Web Services conform to the contractual definition laid down by the CDL document that is in use by the existing suppliers.
In some cases the initial document may need to be modified to add a new partner. However, the new document may introduce problems into the design. Using CDL IDE plug-in, the document desgin can be checked for various properties. Thus, the designers may be able to statictaly detect problematic areas such as livelocks, deedlocks and leaks.
Requirements for variation 1
A CDL description may be used in the generation of code skeletons (for example, may be WS-BPEL, Java, C# or others).
A CDL description may be used in the generation of test messages.
A CDL tool may need the capability to check for correctness properties in order to ensure the robustness of an implementation.
A variation of this is that modified quotes from a buyer are an agreement to order based on the modified quote. Or the supplier may, in response to the buyer require that there to be more than one manufacturer that can meet the quote.
Requirements for variation 2
Needs the support of conditional paths.
Needs the support of sequence.
From the CSF Analysis 8 goals were extracted, 16 critical success factors identified and 19 requirements. These are summarized next.
The next subsections list the CSF goals.
To be able to capture the interaction of a set of web services, from a global perspective.
To be able to work with existing standards (i.e. WS-BPEL and other standards) to avoid duplication where possible).
Those factors that define the success of a choreography description language are as follows:
To be successful a CDL MUST enable choreographies to be composed of other choreographies.
To be successful a CDL MUST enable a choreography to be segmented based on some facet.
To be successful a CDL MUST be able to describe a declarative global model of interaction.
To be successful a CDL description MUST enable static verification of correctness properties.
To be successful a CDL MUST facilitate the use of tools to manage and generate descriptions of choreographies.
To be successful a CDL MUST be able to capture interactions between participants with different policy requirements.
To be successful a CDL MUST NOT require changes to the WSDL definiton of a Web Service.
|All specified choreography descriptions MUST be compatible with WSDL 2.0.|
|A choreography MUST be independent of implementation technology.|
|A choreography MUST provide a global model for presenting its interactions from the point of view of all the parties and not from the point of view of just one party.|
|A choreography language MAY provide a mean by which a choreography description can be bound to technologies other than WSDL 2.0.|
|A choreography MUST provide error handeling capabilities.|
|A choreography language MUST be able to describe a timeout against any observable interaction.|
|A choreography language MUST be able to describe the handling of unexpected erros.|
|A choreography definition MUST enable a participant to point a deviation in a choreography.|
|A CDL MUST enable the definition of interactions between participants that are independent of message format.|
|It MUST be possible to pass participants identification data.|
|It MUST be possible to model message flows that repeat.|
|A CDL MUST provide the ability to add annotations.|
|A CDL MUST provide means of abstractions.|
|A CDL MUST be able to describe conditional behavior.|
|A CDL MUST enable the describtion of external observable behavior between participants.|
|A CDL MUST be able to describe multi-party interaction.|
|It MUST be possible to refere to a choreography from within its description.|
|A CDL MUST enable changes to bindings at run time to allow dynamic participation.|
|A CDL MUST enable the definitoin of synchronization points.|
|A CDL MUST provide mechanisms to support syntactic reuse.|
|A CDL MUST be able to describe sequences of dependent interactions and parallel interactions.|
|A CDL MUST enable validation of choreography definition for correctness properties, including: livelock, deadlock and leak freedom.|
|It MUST be possible to unambigously reference a choreography.|
|A CDL MUST enable the generation of implementation code and test cases.|
|A CDL MUST be independent of business semantics.|
|A CDL MUST enable the specification of QoS properties.|
|A CDL MUST enable the demarcation of collaboration groups.|
|A CDL MUST enable the expression of static and dynamic timeouts.|
|A CDL MUST enable the determination of which collaboration group a message belongs to.|
This section cross references the use case requirements with requirements.
|Use Case Reference||Variation||Requirement Reference|
|C-UC-001||Variation 1||C-CR-1003, C-CR-4514|
|C-UC-001||Variation 2||C-CR-4613, C-CR-4610, C-CR-5100|
|C-UC-001||Variation 2||C-CR-4613, C-CR-4610, C-CR-5100, C-CR-5001|
|C-UC-001||Variation 3||C-CR-4213, C-CR-4210|
|C-UC-001||Variation 4||C-CR-4212, C-CR-4213, C-CR-4210|
|C-UC-001||Variation 4||C-CR-5203, C-CR-5205|
|C-UC-001||Variation 4||C-CR-4211, C-CR-4223|
|C-UC-001||Variation 6||C-CR-4220, C-CR-5202|
|Use Case Reference||Variation||Requirement Reference|
This section cross references requirements with use cases requirements.
|Requirement Reference||Use Case Reference|
|Req Ref||Use Case Ref|
No requirements document can provide complete coverage for any particular technology. However, these user scenarios, use cases, the requirements derived from them are intended to provide coverage for the majority of the most common possible use of Web Service Choreography. It is hoped that any omissions or errors contained herein will be corrected as this document matures.
This document has been produced by the members of the Web Services Choreography Working Group. The chairs of this Working Group are Martin Chapman (Oracle Corporation) and Steve Ross-Talbot (Enigmatec Corporation).The editors would like to thank the Working Group members for their contributions. Members of the Working Group are (at the time of writing): Assaf Arkin (Intalio Inc.), Daniel Austin (Sun Microsystems, Inc.), Abbie Barbir (Nortel Networks), Alistair Barros (DSTC Pty Ltd (CITEC)), Carine Bournez (W3C), Gary Brown (Enigmatec Corporation), Mike Brumbelow (Apple), David Burdett (Commerce One), Ravi Byakod (Intalio Inc.), Michael Champion (Software AG), David Chapell (Sonic Software), Ugo Corda (SeeBeyond Technology Corporation), Fred Cummins (EDS), William Eidson (TIBCO Software), Keith Evans (Hewlett-Packard), Anthony Fletcher (Choreology Ltd), Peter Furniss (Choreology Ltd), Yaron Goland (BEA Systems), Leonard Greski (W. W. Grainger, Inc.), Jim Hendler (University of Maryland (Mind Lab)), Ricky Ho (Cisco Systems Inc.), Andre Huertas (Uniform Code Council), Duncan Johnston-Watt (Enigmatec Corporation), Nickolas Kavantzas (Oracle Corporation), Eunju Kim (National Computerization Agency), Mayilraj Krishnan (Cisco Systems Inc.), Melanie Kudela (Uniform Code Council), Yutaka Kudou (Hitachi, Ltd.), Yves Lafon (W3C), Paul Lipton (Computer Associates), Kevin Liu (SAP AG), Monica Martin (Sun Microsystems, Inc.), Francis McCabe (Fujitsu Ltd.), Jeff Mischkinsky (Oracle Corporation), Eric Newcomer (IONA), Ed Peters (webMethods, Inc.), Greg Ritzinger (Novell), Yoko Seki (Hitachi, Ltd.), Evren Sirin (University of Maryland (Mind Lab)), Ivana Trickovic (SAP AG), William Vambenepe (Hewlett-Packard), Jim Webber (Arjuna Technologies Ltd.), Stuart Wheater (Arjuna Technologies Ltd.), Prasad Yendluri (webMethods, Inc.), Hadrian Zbarcea (IONA).
Previous members of the Working Group were:Steven White (SeeBeyond Technology Corporation), Steve Pruitt (Novell), Richard Bonneau (IONA), Sanjay Patil (IONA), Colleen Evans (Sonic Software), Carol McDonald (Sun Microsystems, Inc.), Daniel Austin (W. W. Grainger, Inc.), Jon Dart (TIBCO Software), Allen Brown (Microsoft Corporation), Greg Meredith (Microsoft Corporation).