As the momentum around Web Services grows, the need for effective
mechanisms to co-ordinate the interaction 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 first
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. The Working Group
seeks feedback on this document.
Comments on this document should be sent to public-ws-chor-comments@w3.org
(public
archive). It is inappropriate to send discussion emails to this
address.
Discussion of this document takes place on the public public-ws-chor@w3.org
mailing list (public
archive) per the email communication rules in the Web Services
Choreography Working Group charter.
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 Introduction
1.1 What is Web Services
Choreography?
1.2 Conventions
Used In This Document
2 Requirements Methodology
3 Use Cases
3.1 Structure of Use Cases
3.2 Use
Case Descriptions
3.2.1 D-UC-001 - Simple Client Server
3.2.1.1
Actors
3.2.1.2
Description
3.2.1.3
Preconditions
3.2.1.4
Triggering Event(s)
3.2.1.5
Postconditions
3.2.1.6
Flow of Events
3.2.1.6.1
Basic Flow (Primary Scenario)
3.2.1.6.2
Alternate Flow(s)
3.2.1.7
Related Use Cases
3.2.1.8
Notes / Issues
3.2.2 D-UC-002 - Service and Device Interoperability
3.2.2.1
Actors
3.2.2.2
Description
3.2.2.3
Preconditions
3.2.2.4
Triggering Event(s)
3.2.2.5
Postconditions
3.2.2.6
Flow of Events
3.2.2.6.1
Basic Flow (Primary Scenario)
3.2.2.6.2
Alternate Flow(s)
3.2.2.7
Related Use Cases
3.2.2.8
Notes / Issues
3.2.3 D-UC-003 - Travel agent (static discovery)
3.2.3.1
Actors
3.2.3.2
Description
3.2.3.3
Preconditions
3.2.3.4
Triggering Event(s)
3.2.3.4.1
Basic Flow (Primary Scenario)
3.2.3.4.2
Alternate Flow(s)
3.2.3.5
Postconditions
3.2.3.6
Flow of Events
3.2.3.7
Related Use Cases
3.2.3.8
Notes / Issues
3.2.4 D-UC-004- Alternative paths based on business
rules
3.2.4.1
Actors
3.2.4.2
Description
3.2.4.3
Preconditions
3.2.4.4
Triggering Event(s)
3.2.4.4.1
Basic Flow (Primary Scenario)
3.2.4.4.2
Alternate Flow(s)
3.2.4.5
Postconditions
3.2.4.6
Flow of Events
3.2.4.7
Related Use Cases
3.2.4.8
Notes / Issues
3.2.5 D-UC-005 - Exception Handling Across Domains of
Control
3.2.5.1
Actors
3.2.5.2
Description
3.2.5.3
Preconditions
3.2.5.4
Triggering Event(s)
3.2.5.4.1
Basic Flow (Primary Scenario)
3.2.5.4.2
Alternate Flow(s)
3.2.5.5
Postconditions
3.2.5.6
Flow of Events
3.2.5.7
Related Use Cases
3.2.5.8
Notes / Issues
3.2.6 D-UC-006 - Choreography Recovery
3.2.6.1
Actors
3.2.6.2
Description
3.2.6.3
Preconditions
3.2.6.4
Triggering Event(s)
3.2.6.4.1
Basic Flow (Primary Scenario)
3.2.6.4.2
Alternate Flow(s)
3.2.6.5
Postconditions
3.2.6.6
Related Use Cases
3.2.6.7
Notes / Issues
3.2.7 D- UC-007 - Choreography Dependency
3.2.7.1
Actors
3.2.7.2
Description
3.2.7.3
Preconditions
3.2.7.4
Triggering Event(s)
3.2.7.5
Flow of Events
3.2.7.5.1
Basic Flow (Primary Scenario)
3.2.7.5.2
Alternate Flow(s)
3.2.7.6
Postconditions
3.2.7.7
Related Use Cases
3.2.7.8
Notes / Issues
3.2.8 D- UC-008 - Quote Request
3.2.8.1
Actors
3.2.8.2
Description
3.2.8.3
Preconditions
3.2.8.4
Triggering Event(s)
3.2.8.5
Postconditions
3.2.8.6
Flow of Events
3.2.8.6.1
Basic Flow (Primary Scenario)
3.2.8.6.2
Alternate Flow(s)
3.2.8.7
Related Use Cases
3.2.8.8
Notes / Issues
3.2.9 D-UC-009 - Really Big Corporation
3.2.9.1
Actors
3.2.9.2
Description
3.2.9.3
Preconditions
3.2.9.4
Triggering Event(s)
3.2.9.5
Postconditions
3.2.9.6
Flow of Events
3.2.9.6.1
Basic Flow (Primary Scenario)
3.2.9.6.2
Alternate Flow(s)
3.2.9.7
Related Use Cases
3.2.9.8
Notes / Issues
3.2.10 D-UC-010 - Interconnection of Document Management
Systems
3.2.10.1
Actors
3.2.10.2
Description
3.2.10.3
Preconditions
3.2.10.4
Triggering Event(s)
3.2.10.5
Postconditions
3.2.10.6
Flow of Events
3.2.10.6.1
Basic Flow (Primary Scenario)
3.2.10.6.2
Alternate Flow(s)
3.2.10.7
Related Use Cases
3.2.10.8
Notes / Issues
3.2.11 D- UC-11 _ Supporting collaboration
3.2.11.1
Actors
3.2.11.2
Description
3.2.11.3
Preconditions
3.2.11.4
Triggering Event(s)
3.2.11.4.1
Basic Flow (Primary Scenario)
3.2.11.4.2
Alternate Flow(s)
3.2.11.5
Postconditions
3.2.11.6
Flow of Events
3.2.11.7
Related Use Cases
3.2.11.8
Notes / Issues
4 Choreography
Requirements
4.1 Charter
Constraints
4.2 Interoperability
4.3 Scalability
4.4 Security
4.5 Management and
Provisioning
4.6 Exception
Handling
4.7 Messaging and
Protocols
4.8 Interfaces
4.9 Reliability
4.10 Transaction
4.11 Composition
4.12 Testing and
Validation
4.13 Ease of
Use
4.14 Support for
Semantics
4.15 External
Dependencies
4.16 Systems
5 Correlation
of Use Cases and Requirements
5.1 Use Cases and
Requirements Cross-Reference
5.2 Requirements
Coverage
6 Appendix A - References
6.1 Normative
References
6.2 Informative
References
7 Appendix B - Acknowledgements
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.
Web Services Choreography concerns the 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.
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-](C)(R|UC)nnn
[D-] indicates that the item is in a draft state.
(C) indicates Candidate status.
(R|UC) is one of (Requirement|Use Case).
nnn indicates the sequence number of the item.
Please note that, owing to the changing nature of requirements
analysis, the numbering of requirements, use cases, and user
scenarios may not always reflect sequential order.
The Working Group has chosen two ways of gathering requirements for
Web Services Choreography. The first consists of the examination of
member-submitted use cases, from which requirements may be
inferred. The second method involves the use of the Critical
Success Factor analysis methodology, and will be addressed in
future versions of this document.
A use case may be considered to be a description of an
interaction, which takes place across one or more system
boundaries, involving one or more users and services. In order to
better organize and make use of the member-submitted use cases, we
have developed a specific template, which includes fields for the
requisite information.
It is intended that the uses cases presented here include the
widest possible number of requirements using as few use cases as
possible.
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.
Structurally, uses cases are submitted using a predefined template
that specifies the information required to generate requirements.
This template loosely follows the standard UML requirements
gathering activities, and is well aligned with common industry best
practices.
Submitted by: Enigmatec Corporation Ltd
Ref: [URL]
Client - Role that makes requests to a Server.
Server - Role that responds to requests from a Client.
A system is to be constructed from two Web Services that we call a
"Client" and a "Server". The Client starts a
session with a Server and then sends any number of requests
receiving, in each instance, a response, and then closes that
session with the Server. The Server has analogous behavior.
The client has declared its external observable behavior as
described above.
The server has declared its external observable behavior as
described above.
The triggering event for the choreography between the Client and
Server takes place when and only when an "open" request
is made to the "Server".
There are no explicit postconditions. Implicitly, the system must
return to Idle for both the Client and the Server; ensuring that
the Client sends a "close" and that the Server is ready to receive
a "close" can do this.
In its initial state the Server is said to be Idle; we call this an
"IdleServer". An IdleServer can only accept
"open" requests; no other request is accepted by an
IdleServer. When an IdleServer accepts an "open" request,
its behavior changes to that of a "BusyServer".
In its BusyServer state, a BusyServer can accept a
"request" and send a response. Alternately, it can accept
a "close", in which case it becomes an IdleServer once
more.
In pi-calculus we represent this as:
IdleServer(o,req,resp,c) = o-in.BusyServer(o,req,resp,c)
BusyServer(o,req,resp,c) = req-in.resp-out.BusyServer(o,req,resp,c)
+ c-in.IdleServer(o,req,resp,c)
A Client in its initial state is said to be an
"IdleClient", until it sends an "open" request;
it is then said to be a "BusyClient".
As a "BusyClient", it can send a request and then accept
a response. It can also send a close, in which case it becomes an
IdleClient.
IdleClient(o,req,resp,c) = o-out.BusyClient(o,req,resp,c)
BusyClient(o,req,resp,c) =
req-out.resp-in.BusyClientr(o,req,resp,c) +
c-out.IdleClient(o,req,resp,c)
The behaviour of the complete system, the client and the server
can be defined by means of parallel composition over the
behavioural contracts that exists between a Client and a Server.
Again in pi-calculus this would be defined as follows:
ComposedSystem = (!IdleClient | IdleServer)
In this composition we have any number of clients
(the ! operator) but only one server. Whenever a client wishes
to talk with a server it performs the appropriate open and
request/response pairs until it performs a close. At that point
any waiting client, having sent an open to the server, can
proceed. That is the waiting client blocks until the server is
able to service its request based on the observable behaviour
defined for the client and the server.
This use case shows a clear problem with potential live-lock
situations. In this example it is possible that any Client is
locked out from dealing with a server forever.
This use case generates the following requirements:
The ability to uniquely name a behavior (i.e. IdleServer,
BusyServer, IdleClient, BusyClient).
The ability to describe a behavior in terms of interactions. An
interaction is defined as the sending of a communication on a named
channel (o,req,resp,c).
The ability to describe a behavior recursively (i.e. the definition
of BusyServer refers to itself).
The ability to describe a behavior that has choice to enable
different behaviors to be referenced (i.e. the use of the +
operator).
The ability to describe a sequence of communications (i.e. the use
of the "." operator in req-out.resp-in as well as
o-in.BusyServer).
The Composed system enables Clients to communicate with a Server.
IdleClient communicates with the IdleServer until it sends a close.
When a close has been received the transitions from behaving like a
BusyServer to an IdleServer and so is able to accept open requests
from any IdleClient. This ability compose behaviors into higher
level processes such as our ComposeSystem above gives rise to
another requirement, namely:
The ability to describe parallel composition of services (i.e. the
"|" operator).
The use case demonstrates some of the basic interactions and
behaviors that may be required to enable us to describe a
choreography between two processes.
Submitted by: unknown
Ref: [URL]
Network Agent Actor: detects Devices or agents on devices and their
ontology.
A manufacturer of devices (sensors, cell phones, printers) builds a
device that interoperates with (sensor/actuator) devices built by
other manufacturers. Device properties are expressed in ontological
form. The ontology of device properties, or "device
ontology", is embedded in the device. If the device is
connected to a network, it can be recognized and installed into
that network by an agent that parses the device ontology and
determines how best to integrate its function. Once installed, the
device may be bound to other devices, forming a composite device.
This composite device, logically a unique device, may interact with
other devices or services on the network. Device manufacturers are
not expected to perform a priori testing of all possible device
configurations to achieve interoperability.
Device is connected to the network and aware of its capabilities.
Agent is online.
Device attaches to network and becomes online.
Agent detects device.
Successful installation of device to network.
In its initial state, the network agent can be idle. The agent
waits in a loop for a sign on request from the device. The agent
then accepts the request and reads the device ontology to determine
what is needed in order to install the device to the network.
Simple Client Server.
Submitted by: Web Services Architecture WG
Ref: [URL]
Client - Role that makes requests to a Server.
Server - Role that responds to requests from a Client.
The goal of the consumer is to get the best combination of services
and prices suiting his/her 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. Developers
use WSDL and platforms to create instances of Web Services.
Basic assumptions for the use case:
A company (travel agent) wants to offer to people the ability to
book complete vacation packages: plane/train/bus tickets, hotels,
car rental, excursions, etc.
Service providers (airlines, bus companies, hotel chains, etc)
provide Web Services to query their offerings and perform
reservations.
Credit card companies provide services to guarantee payments made
by consumers.
The discovery of specific service providers and metadata happens
prior to invocation, and a developer uses the description to create
the Web Service invocation. (This could be considered a
"static" use case.)
For this version of the usage scenario, we will limit ourselves to
booking of vacation packages. We will assume that cancellation is
not possible once a package has been purchased.
The travel agent provides a system to provide the user with options
for his/her vacation and earns money by charging fees for each
package bought.
Service providers (hotels, airlines) sell their services by making
them available widely using Web Services.
Credit card companies enable customers to use their credit cards in
a large number of cases by making payment Web Services available,
and make profit with each transaction.
The user (consumer) books a vacation easily by choosing among a
large variety of offers. The only human being in the scenario is
the user (the travel agent, service providers and credit card
companies are all agents).
User logs on the web site to perform a reservation.
User interacts with the main agent. User is capable of maneuvering
between reservations. User is capable of changing/modifying a
reservation.
User is capable of successfully completing the transaction.
Simple Client Server.
Service and Device Interoperability.
Submitted by: Monica J. Martin, Sun Microsystems.
Ref:
http://lists.w3.org/Archives/Member/member-ws-chor/2003Jun/0060.html
Buyer
Seller
This business process use case entails two different paths on an
ordering process from the view of two actors: Buyer and Seller. In
order to conduct trade, the two views are valid; however, business
rules dictate what process is used, and what other controls are
applied within an enterprise. Whether those paths are visible to
the observable process is guided by the agreement between the
participating roles.
Relevant points to consider:
Multiple paths can occur.
Is successful completion of any one path substantive or not (i.e.
does it affect the final outcome)? Here the seller sees the
'Handle questionnaire' as an obligation. This may not hold
true for the buyer.
Opens the question of optional behavior and what is allowed within
the context of a business process and choreography (this affects
interoperability).
Raises questions about pre- and postconditions as well as the
impact of other business processes or external events.
Variation on the Case listed below: Similar to case (1) except
raises issues related to exceptions:
Exception propagation up and down the stack
Business action based on exception.
Each actor in this use case has some level of business process
defined in order to collaborate with another actor or view.
A business agreement should be established between the parties _
whether it is technical, formal or what its expression is are not
defined by this use case.
An agreement provides business (and later technical) context as to
what business rules are applicable for this use case. Therefore,
the business event of establishing an agreement may trigger the
definition of the business rules, process steps, and acceptable
paths in this business process as it relates to the interactions
between the Buyer and Seller. A business need triggers an order
between the Buyer and the Seller.
Each actor _ the Buyer and the Seller - has a view of the ordering
business process.
The Buyer and Seller establish a business agreement. The business
agreement does not specify the execution syntax but establishes
business semantics and commitment responsibilities understood
between the parties. There could be multiple agreements for
commitments and transactions.
The Buyer has a business need for widgets that are integrated into
a packaged product.
The Buyer's view of the ordering process is:
Pick a product;
Pay for a product; and,
Ship a product.
When the ordering process is active:
A quality process is possible from a Quality Coordinator. The
quality process is not integrated with or dependent on the ordering
process.
The Seller fulfills business needs for the Buyer.
Note: This figure represents the Buyer and the Seller view prior to
any agreement.
The Seller's view of the ordering process is:
Pick a product;
Apply a quality check (see business rule);
Pay for a product;
Apply a quality check (see business rule); and,
Ship the product.
Both the Buyer and Seller wish to have a collaborative view of
their ordering process. Therefore, they need to apply business
rules to their interaction to establish that collaborative view.
In general, they apply the Seller's view of the ordering
process, which integrates the Quality check within the Seller's
domain of control.
Within the view of the Seller, the quality check is applied and is
integrated into the ordering process. However, this quality check
MAY or MAY NOT be applied as it relates to an instance of an
ordering process interaction between the Buyer and the Seller. The
application of the business rules MAY be driven by the business
context, requirements and the agreement.
For example, external events, such as a low-risk, high-availability
turnaround requirement for ultimate customer delivery may require a
different path be taken in the ordering process. When the Buyer
interacts with the Seller, it often takes the product component and
integrates it into another solution. With one ultimate Customer,
the Buyer, on certain occurrences, must deliver in 2 days.
Therefore, the Buyer may need to ask the Seller to bypass the
quality check. However, in this instance, the Buyer takes on
additional responsibility, releasing the Seller from some
responsibilities.
Where these rules are applied MAY vary by which Buyer or Seller is
involved in this ordering process. (This implies a many-to-many
relationship between the role and the services provided).
Where these rules are applied MAY also vary by which Buyer or
Seller is involved in this ordering process. The choreography
definition should handle either case to provide flexibility to
these roles in the ordering process.
In this case, independence is maintained. _Handle
Questionnaire" is actually executed against business rules
during process execution, although its path is known prior to
execution. Each is a valid path. Business rules related to the
quality check are applied 'in' the process, even though a
business context rule is applied prior to the order process
initiation to maintain process independence.
In this second case, business rules are applied first and either
path is actually executed before and during process execution
(although both paths are known prior to execution). Each is a valid
path. The business rules are applied overall before and
'in' the process.
Allocate responsibility for quality control to Buyer or Seller
based on business context. Either the Buyer or the Seller provides
maintenance support for product.
Initiate the ordering process.
If for ultimate Customer X, apply this choreography definition:
Pick a product;
Pay for a product;
Ship a product; and,
Deliver product.
Otherwise, if not Customer X, apply the default choreography
definition:
Pick a product;
Apply a quality check (see business rule);
Pay for a product;
Apply a quality check (see business rule);
Ship the product; and,
Deliver product.
Order is completed successfully.
Exception propagation.
When combined with exception propagation, external events may
affect the ultimate business outcome of the ordering process use
case focusing on alternative paths.
This use case motivates the following potential requirements:
A choreography agreement or agreement(s) should provide the
business context of the choreography definition.
A choreography should include process controls and sequencing
options, where sequence/order is affected by the agreement or
references in the choreography definition.
The outcome given order or the assumptions about the outcome of the
given order should be based on the business context and
agreement(s).
Dependencies may exist between or within processes, which should be
describable using nested processes or choreography sets. Whether or
not these dependencies are substantive should be discussed.
Optional paths may be taken that affect dependencies and outcomes.
From a business perspective, selecting one path over another could
have different agreement implications if an error occurs.
|
Editorial note
|
|
|
Submitted by: Sun Microsystems
|
|
Editorial note
|
|
|
Ref:
http://lists.w3.org/Archives/Member/member-ws-chor/2003Jun/0060.html
|
Buyer
Seller
Quality Control or Customs (External Views to the Current Process)
This business case extends the Alternative Paths Based on Business
Rules use case. In that case, several business processes could
occur and take different paths based on business agreement,
application of business context, and choice of business rules.
This use case integrates the Seller and Buyer views into one
Business Process; A. Quality Control at the Seller Company has
Business Process B, where Quality Control evaluates the
Questionnaire. During shipment, a Customs Control process (Business
Process C) may be initiated, affecting Business Process A. Multiple
concurrent and independent processes exist. Multiple and
independent process outcomes could occur and depend on how they are
choreographed and how the process is defined within a choreography
set or higher-level collaboration.
This business case step should address these requirements:
Exception handling/propagation;
Choreography and choreography sets;
Typing of exceptions (process and control failure);
Impact of signals (receipt acknowledgement or acceptance
acknowledgement), if used to indicate process validation success or
failure;
Confirmation that the propagation occurs to the application as
opposed to the service or service interface; and,
Integration of process and control flow failures (such as Process
or validation failure on Handle Questionnaire and control failure
on Business Process A).
For brevity, the Ordering Process defined in the Alternate Paths
Based on Business Rules use case is not duplicated here. The
relationship between Business Process B and C to Business Process A
will be outlined.
For Business Process B, the precondition is:
A business rule has been applied either prior to process initiation
or during the process, where the business rule is required, and a
Handle Questionnaire check is initiated.
An exception on Handle Questionnaire cannot occur unless Handle
Questionnaire is initiated. Therefore an exception precondition
exists in Business Process B when a Quality Control check is
applied. Whether or not Business Process B is exposed, the
exception affects the outcome of Business Process A.
For Business Process C, the precondition is:
A business rule has been applied where required, either prior to
process initiation or during the process, and a Customs Control
check is initiated. The precondition is that an international order
is processed, where "international" means that the
Buyer's ship-to location is subject to regional customs
requirements.
An exception on Customs Control cannot occur unless Customs Control
is initiated. Therefore, an exception precondition exists in
Business Process C, when a Customs Control check is applied.
Whether or not the Business Process C is exposed or not, the
exception affects the outcome of Business Process A.
Exception propagation SHOULD occur within Business Process B and C,
to the originator of the service request (e.g., Handle
Questionnaire within the parent process, Business Process B).
The triggering event for an Exception is an exception in Business
Process B or C that is considered substantive to the completion of
Business Process A.
Handle Questionnaire MAY be handled by an outside service. This
service checks the quality of the product produced and applies a
quality control check. The results of the Quality Control check are
provided to the Handle Questionnaire process step.
Business rules, agreed upon by the partners in the interaction,
determine whether or not the Quality Control check for the Handle
Questionnaire process step is handled externally. The application
of these business rules before or inside the processes is typically
driven by agreement. See the Alternate Paths Based on Business
Rules use case for more detail on the ordering process for further
details.
In general, the Seller's view of the ordering process is
applied, integrating the Quality check within the Seller's
domain of control. When this Quality check is applied, the Handle
Questionnaire process step is initiated. The Handle Questionnaire
process step is applied prior to the Pay process step and the
results are reported prior to the release to Ship the product. On
high-risk items (for example, those items showing a higher
incidence of failures), the Seller turns the Quality check over to
another specialized service, designated here as Quality Control.
Quality Control completes the check with a set of parameters
provided by the initiating party for the service, which is the
Handle Questionnaire process step in Business Process A. This may
be based on the role involved with the service or the service
itself, which here is the Seller or Handle Questionnaire
respectively.
Quality Control is responsible to:
Complete the checks;
Report the results to the Handle Questionnaire process step for the
Seller;
Log success and notify Business Process A;
The ordering process continues and completes successfully (assuming
no other business exceptions).
See the ordering process under Alternate Paths Based on Business
Rules use case for alternative flows that are presupposed here
(e.g., rules that dictate whether the Handle Questionnaire process
step occurs).
If a Quality Check response fails (i.e., an exception occurs), the
Quality Control MUST be reported to the Handle Questionnaire
process step in Business Process A. In addition, a decision SHOULD
be made to propagate this to the main Business Process A. Whether
or not the ordering process continues is based on business rules,
context or agreements between the Seller and Buyer.
The same premise applies to the Customs Control process, external
to Business Process A. The Customs Control process is external to
Business Process A. If an exception occurs, the Customs Control
exception MUST be reported to Business Process A, at the Ship
process step. Whether or not the Business Process A ends
successfully or not is based on business rules held within the Ship
process step. This criteria is not externally visible to Business
Process A. Unless the Seller is willing to provide these details,
this process step and the rules associated with the state MAY or
MAY NOT be externally observable by the Buyer from the Seller.
Business Processes B and C should be considered as 'black
boxes' to Business Process A, reporting only their outcome back
to the requesting process.
The Buyer and the Seller SHOULD know the business state of the
externally observable behavior or process outcomes. If an event
outside of the observable behavior impacts the state and progress
of the Business Process, the events or the services MAY be made
known to the Buyer and Seller, for auditing and reporting purposes.
The Seller will make this data available for business purposes.
See the ordering process for the Alternate Paths for Business Rules
use case. Here the exceptions and their propagation are shown in
Figure 1. An exception has the following paths:
See Ordering Process.
When an international order is triggered, or certain business rules
met, a Customs Control process is initiated. The Customs Control
Process, Business Process B, is external to Business Process A.
The Customs Control process checks the conditions of Order and
provides the result back to Business Process A.
The results of the Customs Control Process MUST be reported back to
Business Process A, as they can affect the outcome, prior to the
completion of the Ship process step and the final transition of
state to the end of parent business process.
See Alternate Flows for further details.
For Quality Control related to Handle Questionnaire:
See Ordering Process.
When specific business rules are met, an external Quality Control
process is initiated. The Quality Control Process, Business Process
C, is external to Business Process A.
The Quality Control process checks the conditions of Order and
provides the result back to Business Process A.
The results of the Quality Control Process MUST are reported back
to Business Process A, as they can affect the outcome, prior to the
initiation of the Ship process step.
Further details can be found in the Description and Alternative
Flows sections of this use case.
The exception propagation use case is an extension of the
Alternative Paths Based on Business Rules use case, dealing with
the ordering process. However, it could be related to many other
use cases.
Consider this process view, and the possibility that exceptions
could occur anywhere in this stack. This could impose requirements
on:
Exception handling within and across processes;
Impact of conflicting business requirements;
Dependencies within or between business processes;
Agreements;
Auditing and reporting;
State management and timing within a or between business processes;
and,
Differentiation between errors and exceptions - for example, the
latter SHOULD typically be known and therefore, handled.
Finally, it is an open question whether an error condition should
be considered in this use case, to understand how or whether it is
propagated. This affects the execution of Business Process A, and
whether it ends in Success or Failure.
|
Editorial note
|
|
|
Submitted by: ?
|
|
Editorial note
|
|
|
Ref: [URL]
|
This use case describes the idea of creating an instance
of a choreography definition (i.e. an actual choreography) allowing
one role to inquire on outstanding activities being taken by
another role after a catastrophic failure. This allows partially
complete choreographies to reach their normal conclusion.
This use case suggests the idea of defining an "Outstanding
Activities" choreography instance designed to support recovery
after a catastrophic failure. The idea is that the Outstanding
Activities choreography could be used after the failure of ANY
choreography and is therefore generally applicable and so will
benefit from standardization.
In this example the choreography is used by a Buyer to recover the
processing of an order after the Buyer suffers a system crash.
Buyer places an order.
Buyer system suffers from a crash.
In this example the choreography is used by a Buyer to recover the
processing of an order after the Buyer suffers a system crash.
Buyer Recover Process | Supplier Recovery Process
Send PO ---------B (using a RM protocol)
B--------- Send PO response (using a RM protocol)
Resend outstanding PO response ------B
... Continue with the original process ...
Buyer Process |Supplier Process
B----------- Send PO response (using a RM protocol)
Buyer continues from where he left off ...
In this particular scenario the choreography that was started in #1
is carried to completion. When the buyer fails, the buyer asks the
seller (in fact, all parties it talked to before failure) to
perform recovery by indicating the last messages sent. It then
requests that these messages be sent in the original context, which
causes all outstanding choreographies to proceed on schedule.
Successful recovery of order.
Simple Client Server.
|
Editorial note
|
|
|
Submitted by:
|
Ref: [URL]
Buyer Agent
Supplier Agent
This use case illustrates the dependencies between two
choreographies. The details are explained in the event flow
section.
A Buyer sending a Supplier an order status request.
The first choreography (Order Placement):
A Buyer sends a Supplier an Order.
The Supplier sends an Order Response document to the buyer,
indicating the extent to which the supplier can satisfy the Order.
This is dependent on step 1.
Optionally, the Buyer can send a Change Order to the Supplier,
modifying the original Order. This is dependent on step 1, and can
occur multiple times.
Upon receipt of a Change Order, the Supplier sends a new Order
Response document to the Buyer, indicating the extent to which the
supplier can satisfy the changed Order. This is dependent on, and a
response to, step 3.
Optionally, the Buyer can send a Cancel Order to the Supplier,
canceling the original Order and any changes. This can occur at any
point after step 1, provided that step 5 (this step) has not been
executed previously.
Upon receipt of a Cancel Order, the Supplier sends a Cancel Order
Response to the Buyer, indicating whether or not the Cancel Order
has been accepted. This is dependent on step 5.
Either Buyer or Supplier can send an Error Response document to the
other actor as a reply to any message received, indicating that
there was some error in the message that prevented it being
processed
The second choreography (Order Status):
This choreography allows a Buyer to make an inquiry on the status
of any Order they have previously placed. The dependency is that
the Buyer should only do an order status query if they have
previously started the execution of an order placement
choreography. The steps are:
A Buyer sends a Supplier an Order Status Request. This is dependent
on step 1 of the first choreography.
The Supplier returns an Order Status Response indicating: a) if the
order was recognized, and b) if so, the state of the processing of
the order (e.g. received but not processed, processed, shipped,
billed, etc.)
In addition, Error Response documents can be sent as in the first
choreography.
Successful completion of two choreographies.
|
Editorial note
|
|
|
Submitted by: W. W. Grainger, Inc.
|
|
Editorial note
|
|
|
Ref: [URL]
|
Buyer - Role that requests a quote from the supplier.
Supplier - Role that provides products/services for direct purchase
by the Buyer (potentially aggregating products from one or more
manufacturers).
Manufacturer - Role that makes one or more products covered in a
request for quotation from the Buyer. The Manufacturer role does
not have a direct relationship with the Buyer.
This use case describes a situation in which a Supplier and one or
more Manufacturers collaborate to provide pricing and availability
on a set of products requested by the Buyer. From a Web Services
choreography perspective, the use case illustrates some of the key
features that must be accounted for in the choreography, including:
Contract provisions, such as:
Start and end times for contract validity (e.g. how long is the
quote valid?);
Renewal policies; and,
Responsibilities for each party (i.e., CRCs for each role).
Service level agreements, such as:
Response time; and,
Service availability.
Security provisions
Privacy provisions
Non-repudiation
Escalation procedures
Exception handling
This use case also demonstrates a basic flow of interaction between
two Web Services: negotiate contract, negotiate interface, exchange
data, execute transaction, and return results.
Figure X - Interaction between services
Supplier has a defined interface for quoting items it supplies to
Buyers.
Buyer knows Supplier item identifiers for items requested for
quotation.
Metadata required to negotiate contract is known by the Supplier,
and available to the Buyer.
Buyer has list of products for which a quote is to be requested,
and the product identifiers are understandable by the Supplier.
Buyer receives the requested quote from Supplier, including pricing
and availability.
Quote conforms to contract specifications.
Supplier and Buyer save contract specifications.
Supplier has commitments to receive product from Manufacturer(s),
per Buyer's requirements.
In the primary scenario, the contractual relationships between
Supplier and Manufacturer roles are already in place.
Buyer sends contract requirements to Supplier.
Supplier approves contract requirements for the quote, and returns
approval to the Buyer. Where terms are disputed, Supplier offers
counter-terms.
Buyer accepts contract terms returned by Supplier, and requests
interface information from Supplier.
Supplier returns interface information to Buyer.
Buyer generates a quote request, conforming to Supplier's interface
specification, and submits it to Supplier.
Supplier determines the Manufacturers that will be used to fulfill
the quote based on existing knowledge about Manufacturer(s) ability
to meet Buyer specifications. Supplier creates price and
availability requests for each Manufacturer, and submits them to
the Manufacturer(s).
Manufacturer(s) provide price and availability information for
items in the price and availability request, and returns to
Supplier.
Supplier identifies whether all items requested in the quote by the
Buyer have at least one Manufacturer able to deliver product.
Supplier reviews responses from Manufacturer(s), determining which
items to include from each Manufacturer in response to Buyer.
Supplier builds the quote, and returns it to Buyer. The response
includes items requested, items quoted, and items not quoted,
price, and availability.
Fig. X - request quote event sequence
Contractual relationships between Supplier and Manufacturer roles
do not exist prior to start of use case. This will be documented as
a separate use case.
Step 2 alternatives: The Supplier may reject one or more terms
requested by the Buyer. To handle the negotiation of terms, there
may be multiple request / response sequences between Buyer and
Supplier.
Step 5 alternatives: Buyer is unable to provide information in the
format specified by the Supplier's interface. Use case ends.
Step 7 alternatives: Manufacturer is unable to commit to delivering
items requested in the quote, and declines to provide price and
availability for one or more items.
For the purpose of illustrating relationships between use cases,
the Supplier role is represented by the use cases, not as a
separate actor as we have documented above.
Figure 3 - Request-to-quote event sequence
Need to distinguish the idea of a contract between services (e.g.
the equivalent of CRCs) from a legal contract.
Need additional detail about what happens with the agreed to
contract provisions.
Submitted by: BEA Systems, Inc
Ref: [URL]
User Agent from Large Company
User Agent from a small company
This use case charts a major corporation's efforts to gain
control over the message choreographies used between its various
systems. The work uses Really Big Company (RBC) as the example
company. RBC sells the Really Big Product (RBP), requiring the
cooperation of approximately 100 different Tiny Companies (TCs).
The main activities involved in creating the RBP are order
handling, manufacturing, shipping and billing.
Each of the four activities may involve 20 to 30 different systems,
some of which are internal to RBC. TC partners run the rest. When
the RBP was first being produced RBC handled communication between
the systems, both internal and external, in an ad-hoc manner. The
operators of any two systems that needed to communicate would write
down on a piece of paper what messages they expected, give some
description of the acceptable order and then go write code and test
until things finally worked.
At first, RBC tries to create a single document describing all the
systems, messages and choreographies, but quickly finds that the
complexity of the document is so great that it can't be used
for any practical purpose and will be out of date long before
it's finished. They next try to use a CPL, Java, to describe
the choreography behavior but quickly find that the result is so
complex that no one can really understand it.
Eventually RBC realizes that they need a CDL. The corporation tries
to design its CDL by starting with a CPL and removing features.
First the control logic is vastly simplified to the point where it
just encodes a graph. Then the CDL is made to encode a global view
rather than the participant-level view required by CPLs. They then
add in the ability to segment the CDL so that participants can be
given CDLs that only show them the part of the message choreography
they need to know about. Finally, they add the ability to abstract
away subsystems so that it is easier to understand the over all
logic of the CDL without drowning in the details.
Gain control over message choreographies used between its various
systems in a corporation.
TBD
The first change RBC made was obscuring the control logic. RBC
realized that most of the information provided by the CPL, even
though it was just about choreography, wasn't actually
necessary for understanding the system's behavior. No one
really needed to know, for example, the gory details of how a
message was ripped apart before being processed. The easiest way to
hide this kind of information was to remove control logic from the
CDL. So all the control statements in the IFs, WHILEs and other
program elements were removed in the CDL. In the CDL programmers
would have to annotate the logic with human readable statements in
order to explain their intent.
The second change RBC made was to switch to a multi-party global
view. CPLs, by their very nature, provide a view on the
choreography from the perspective of a single participant. To
understand the system end-to-end using CPLs one has to stitch
together all the participant views to create a coherent whole. By
writing the CDL using a global view that could show all the parties
interacting at once it made it much easier to understand the
system's end-to-end functionality.
TBD
The challenge with using a global view is that it makes it harder
to hide information. After all, if one can see all the participants
simultaneously then how does one hide anything? For example, Tiny
Company 1 may talk to RBC, who then talks to Tiny Company 2. While
RBC needs to have a complete global view of all of its activities,
it only wants to show each Tiny Company the part of the global view
relevant to that TC. The solution RBC choose was to make their CDL
support segmentation _ that is, to enable multiple CDLs to
reference each other and describe their overlapping parts.
RBC understood that what they really needed was two different
solutions: one solution to make it easier to write long running
programs (a CPL), and another solution for describing the
choreography between systems (a CDL).
With both solutions in place RBC was able to use the CDL to
document the full choreography for all message exchanges in their
entire order processing system, including the ability to segment
the picture so that partners only saw the parts they needed. They
were then able to repeat the procedure for their other three
activities and to hook together all the choreographies for all the
activities using segmentation.
RBC still had a problem, however; the final picture was too
complex. With 100 different systems and 400 different messages
across all four activities, no one could understand the whole
picture. RBC needed some way to abstract away subsystems that
didn't need to be understood in detail in order to see the
overall system flow. Segmentation didn't solve this problem
because segmentation allows one to hide information not add a level
of indirection. The solution RBC chose was to make their CDL
hierarchical by allowing the CDL format to wrap CDL functionality
inside of a function call.
The end result of RBC's efforts is that they had implemented
and deployed two solutions: a CPL to make it easier to write long
running logic, and a CDL to make it easier for different systems to
understand their messaging obligations to each other.
Submitted by: BEA Systems, Inc
Ref: [URL]
Buyer View
Seller View
In this use case two companies (BSC and DC) are working together to
design a bridge. In order to improve communication, the two
companies want to connect their document management systems.
This leads to problems with the selection of a reliable messaging
protocol that are resolved by allowing the CDL to be annotated with
information about what reliable messaging protocol is to be used,
rather than building the reliable messaging protocol's messages
directly into the CDL.
Two companies agree on interconnecting their systems.
Concern of the two companies regarding legal and criminal
liability. In their area, there are very strict legal requirements
for who must review and approve any changes to the bridge's
design.
BSC and DC were subcontractors on a project to build a new bridge.
Recognizing the need to work closely together, they decided to
implement a series of Web Services, enabling the companies to
submit proposed changes to the bridge's design. These Web
Services accepted changes, drove the process of getting the
appropriate approvals, and then altered the central design and
notified the appropriate parties.
Both companies had existing approval processes and document
management systems so, as the joint choreography was designed, each
team used segmentation to integrate the joint choreography with
their local systems.
One of the first problems the joint team ran into was that they
wanted to use a reliable messaging system to allow them to transfer
messages. At first they tried to include the messages related to
reliable messaging directly into the choreography. That proved to
be a mess, especially when, half way through the project, they
decided to change their reliable messaging algorithm when a new
group in some standards organization started up and they felt they
needed to be standards-compliant. Eventually, the joint group
decided to enhance their CDL to support annotations. This allowed
them to mark a message exchange as reliable using an identifier
without having to actually include all the reliability details.
They used a similar strategy to deal with message correlation _
that is, rather than trying to invent a generic correlation
language, they used an annotation to specify what correlation
algorithm they were using.
One problem the joint team didn't run into was selecting what
Web Service description language to use. The joint team, wanting to
be strictly standards compliant, was only interested in using Web
Services. So they were happy to find a Web Services CDL working
group. By definition Web Services means WSDL, in this case WSDL
1.2. Rather than taking precious working group time to invent a
generic description framework that could potentially host any and
all descriptors (including ones for ebXML, RosettaNet, EDIINT,
etc.), thus causing the group to likely never ship while they
busily re-invented the work of the WSDL working group, the Web
Services CDL working group that the joint team choose focused
exclusive on WSDL 1.2.
A problem the joint team did run into was that, by law, certain
change approvals must be signed off in a certain order. While the
general rule for interoperability is be generous in what you
accept, whose corollary is be flexible in your processing, such
cannot be where the law is concerned. A CDL can only provide so
much detail and in some limited cases more detail is needed, but
not so much detail as to write the actual code. This is where
abstract processes in choreography programming languages (CPL) come
in.
An abstract process is a CPL program that has been stripped of some
logic. More complete abstract processes may show variable handling
but hide certain types of variable handling behind opaque
functions. More bare-bones abstract processes do not even specify
what variables are to be used. A bare-bones abstract process is
similar to a CDL in the sense that it is not executable but, unlike
a CDL, an abstract process can deal with issues beyond sending and
receiving messages, and specifies its behavior from the perspective
of a single participant. A CDL, on the other hand, exclusively
illustrates messaging behavior, and does so only from a global view
_ that is, from the perspective visible to multiple participants
rather than a single participant.
After the joint team created the CDL to describe the messages
involved in the legally mandated change approval process, they then
created two abstract processes. These abstract processes provided
the details of exactly how each participant was to process a change
request. The abstract processes went beyond just describing the
messaging behavior, dealing with issues such as the actual logic
used to route messages and some of the transformations involved.
The level of detail provided by the abstract processes was
necessary to ensure that both teams behaved exactly as legally
required. Since it is impossible to express this level of detail in
a CDL, an abstract process was necessary.
The joint team chose an abstract process over an executable process
so as not hinder each company's ability to implement the logic
in the way they saw fit. What was needed was only a detailed
description of the desired behavior, not actual running code. This
made the abstract process the more desirable choice.
TBD
By using annotations to specify their reliable messaging and
correlation behavior, the joint team was able to produce a flexible
CDL that could focus on their business logic rather than lower
level infrastructure issues. By using both a CDL and an abstract
process, the joint team was able to provide the level of detail
needed to write a CPL that would enable both companies to
interoperate.
Submitted by: BEA, Inc.
Ref: http://lists.w3.org/Archives/Member/member-ws-chor/someURL
Companies A, B and C do business together. Each has differing
infrastructures in support of their business, but they all have
access to the web. In terms of Web Service actors they have the
following:
Web Service A - the primary Web Service that A offers to the
others.
Web Service B _ the primary Web Service that B offers to the
others.
Web Service C _ the primary Web Service that C offers to the
others.
Each company has made different choices in terms of technology
adoptions. Each company has differing degrees of Web Service
adoption. Each company implements their Web Services using
different technological choices.
The problem: Participants A, B and C collaborate on
designing a system to join their businesses together using Web
Services at each end. To do this, they do the usual pictures and
prose that describes the interaction of the system that they
jointly wish to build. This is sent out as the requirements and
architectural overview of the system.
The high level design: A team of CPs get together at A, B
and C and describe their own roles using a CDL, and then get
together to knit the three CDLs together. This forms what is a
nascent global view for A, B and C.
The transport: This nascent view is further elaborated as
the importance of different parts of the choreography are
identified and marked as requiring a certain Quality of Service
from the underlying transport.
The low level design: This choreography is then used to
drive the development of the Web Services at A, B and C. In the
case of A, which has no existing Web Service that meets these
requirements, it is used to generate the appropriate code skeletons
based on their favorite CPL. Company B has a couple of Web Services
that together will meet the requirements; they stitch these
together as a choreography and restrict the visibility of the
original Web Services, offering only entry and exit points in the
sub-choreography. As it turns out, Company C has an old system that
really does meet the requirements, and so they simply wrap that
system using WSDL and present it as a Web Service as-is.
Testing: Having done all of this, each of the participants
(A, B and C) use the agreed choreography expressed in this CDL to
drive their testing. The CDL, together with a special tool, is used
to generate test messages and is used to validate the responses as
they perform the requisite unit testing. When they enter the system
and integration testing phases of the overall system, the CDL comes
into its own yet again, by enabling them to have a clear picture of
the message exchanges and, therefore, the external observable
behaviors of each other's systems. This ensures that the
testing is completed within the time and under budget.
Verification: In a market place that is highly regulated,
it turns out that the interchange between A, B and C needs to be
shown to be correct. The agreed choreography is checked against the
regulator's view of what the choreography should be. By
performing a bi-simulation, it is shown to be incorrect, and the
regulator requires changes. The changes are made, but the impact is
quiet different for A, B and C. For A, the changes are fairly
simple because they generated from the CDL. They simply apply the
changes at the high level and the changes get rolled in. For B, who
combined Web Services to meet the requirements upon them, took more
time because they could not simply generate. They had to do the
usual impact analysis and so on and then apply the changes by hand;
fortunately their changes were simply structural on the
choreography itself and not on their Web Services. C had the worst
job of all, because it required changes to their legacy system. So
they had to implement a WSDL wrapper for their system and add new
functionality on top. Then they wrapped the new functionality and
applied yet more WSDL, and then bundled it all back into a
sub-choreography and so on. The bi-simulation results in only minor
changes to the choreography which are implemented and the system
resubmitted. This time it is passed and provisioned. The
regulator's choreography description, again using the CDL, is
used for runtime continual validation by the regulator and the
companies A, B and C.
In this use case the roles of A, B and C are as follows:
Company A plays the role of supplier to end users.
Company B provides credit-checking facilities to A.
Company C provides shipping facilities to A.
TBD
An order is placed with A.
TBD
TBD
An order is either fulfilled (by being shipped and received) or
cancelled (terminated because of some exception that occurred, or
because of a customer request for cancellation).
TBD
TBD
This use case compares and contrasts two distinct
choreography-related problems that may require complementary but
separate solutions. For the purpose of clarity we define these
problems in terms of two languages that we call a choreography
programming language (CPL) and a choreography description language
(CDL).
A CPL is a programming language specifically designed to address
long running asynchronous logic such as that commonly used in
business process scenarios. A participant in a choreography would
be expected to implement their executable codes using a CPL.
Examples of CPLs are Java and C#. For the purpose of clarity, other
CPL examples, which are not yet mainstream, are DAML-S and
BPEL4WS1.1 as well as WS-BPEL, which is in development at Oasis.
A CDL is a description language used to provide a declarative,
multi-party global view of a message choreography. A CDL only
focuses on message passing and exist primarily to enable
participants in a choreography to understand the expectations of
their messaging behavior in relation to other participants. Thus:
A CDL can describe the external, observable, interactive behavior
of two or more Web Services relative to each other.
A CDL can be used to generate CPL code skeletons.
A CDL can be used to verify the behavior of a participant with
respect to its role.
A CDL can be used to generate test cases.
A CDL is independent and orthogonal to the language in which its
participating Web Services are implemented.
As a consequence of this a CDL may not need to be executable and
there may be a reason to have this fact stated in some way in a CDL
language.
|
D-CR-001
|
Category: Charter Constraint
|
Level: MUST
|
|
All specified choreography descriptions MUST be compatible
with WSDL 1.2.
|
|
|
|
D-CR-014
|
Category: Charter Constraint
|
Level: SHOULD
|
|
A choreography SHOULD not be bound to any specific
implementation.
|
|
|
|
D-CR-010
|
Category: Interoperability
|
Level: MAY
|
|
A choreography MAY provide an extensible binding mechanism
such that choreographies could be bound to diverse
technologies.
|
|
|
|
D-CR-023
|
Category: Interoperability
|
Level: MUST
|
|
A choreography definition language MUST NOT be restricted
to any single implementation.
|
|
|
TBD
TBD
|
D-CR-004
|
Category: Management and Provisioning
|
Level: MUST
|
|
It MUST be possible to query the state of a choreography.
|
|
|
|
D-CR-052
|
Category: Management and Provisioning
|
Level: MUST
|
|
It MUST be possible to manage choreographies and their
relationships and the messages exchanged between them.
|
|
|
|
D-CR-053
|
Category: Management and Provisioning
|
Level: MUST
|
|
It MUST be possible to observe the state of a choreography
as it occurs in time.
|
|
|
|
D-CR-056
|
Category: Management and Provisioning
|
Level: MUST
|
|
It MUST be possible to create "limited global
views" of a choreography, where not all interactions
are presented.
|
|
|
|
D-CR-013
|
Category: Management and Provisioning
|
Level: MUST
|
|
A choreography MUST provide support for a specific
observer role.
|
|
|
|
D-CR-016
|
Category: Management and Provisioning
|
Level: MUST
|
|
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.
|
|
|
|
D-CR-020
|
Category: Management and Provisioning
|
Level: MUST
|
|
It MUST be possible and practicable to store instances of
use of choreographies in a repository, and to be able to
search for such instances and to retrieve them.
|
|
|
|
D-CR-005
|
Category: Exception Handling
|
Level: MUST
|
|
A choreography MUST provide exception handling that allows
propagation of errors.
|
|
|
|
D-CR-009
|
Category: Exception Handling
|
Level: MUST
|
|
A choreography MUST provide the ability to transition to a
distinct state when a timeout occurs.
|
|
|
|
D-CR-018
|
Category: Exception Handling
|
Level: SHOULD
|
|
A choreography SHOULD define a standardized way to recover
from catastrophic failure.
|
|
|
|
D-CR-026
|
Category: Exception Handling
|
Level: MUST
|
|
A choreography MUST support robust exception handling.
|
|
|
|
D-CR-027
|
Category: Exception Handling
|
Level: MUST
|
|
Error/fault handling and compensation features MUST to be
able to be expressed in the choreography definition
language.
|
|
|
|
D-CR-030
|
Category: Exception Handling
|
Level: MUST
|
|
A choreography MUST be able to distinguish error and
regular state transitions, and to describe unhandled
exceptions.
|
|
|
|
D-CR-031
|
Category: Exception Handling
|
Level: MUST
|
|
A choreography MUST support an exception condition for
Delivery Failure - The message was sent but was (probably)
not received.
|
|
|
|
D-CR-032
|
Category: Exception Handling
|
Level: MUST
|
|
It MUST be possible to manage exceptions between
choreographies, and to include exception-handling
information in dependency management.
|
|
|
|
D-CR-033
|
Category: Exception Handling
|
Level: MUST
|
|
A choreography MUST provide support for defining behavior
of the system, when valid error/exception messages arrive
for choreography instances after their completion (or
before their initiation).
|
|
|
|
D-CR-043
|
Category: Exception Handling
|
Level: MUST
|
|
It MUST be possible to differentiate errors (unknown and
fatal) and exceptions (known and potentially recoverable)
in the context of choreography.
|
|
|
|
D-CR-061
|
Category: Exception Handling
|
Level: MUST
|
|
A choreography MUST provide the ability to transition to a
predefined state when an exception occurs.
|
|
|
|
D-CR-064
|
Category: Exception Handling
|
Level: SHOULD
|
|
If a process detects that a choreography is not being
followed correctly, then the process SHOULD be able to use
the choreography definition to identify exactly what went
wrong.
|
|
|
|
D-CR-065
|
Category: Exception Handling
|
Level: MUST
|
|
A choreography definition language MUST support the
following exception: message format error - the components
of the message were not validly constructed.
|
|
|
|
D-CR-066
|
Category: Exception Handling
|
Level: MUST
|
|
A choreography definition language MUST support the
following exception: message content structure error.
|
|
|
|
D-CR-067
|
Category: Exception Handling
|
Level: SHOULD
|
|
A choreography definition language SHOULD support
exceptions whereby a given service component could be sent
at any point in the transaction.
|
|
|
|
D-CR-068
|
Category: Exception Handling
|
Level: MUST
|
|
Exception types MUST be limited to the ones that will be
used in the choreography definition language.
|
|
|
|
D-CR-069
|
Category: Exception Handling
|
Level: MUST
|
|
It MUST be possible to model different states for
termination of the choreography (e.g., failure and
success).
|
|
|
|
D-CR-070
|
Category: Exception Handling
|
Level: MUST
|
|
A choreography definition language MUST support the
following exception: transmission error - message not
sent.
|
|
|
|
D-CR-002
|
Category: Messaging
|
Level: MUST
|
|
A choreography MUST be independent of message formats.
|
|
|
|
D-CR-007
|
Category: Messaging
|
Level: SHOULD
|
|
A choreography SHOULD express the types of messages a
participant may send, and the types of messages/responses
the participant should anticipate receiving from the other
participant(s) (including time-outs) based on the apparent
state of the exchange.
|
|
|
|
D-CR-011
|
Category: Messaging
|
Level: SHOULD
|
|
A choreography SHOULD describe exchanges of information
that change the state of the process.
|
|
|
|
D-CR-029
|
Category: Messaging
|
Level: MUST
|
|
A choreography MUST support some standard taxonomy of
messages, such as a business messages, generic error
reporting messages and acknowledgement messages.
|
|
|
|
D-CR-035
|
Category: Messaging
|
Level: MUST
|
|
It MUST be possible to model message flows that repeat,
based on information within the messages (for instance,
the contract negotiation protocol).
|
|
|
|
D-CR-039
|
Category: Messaging
|
Level: MUST
|
|
It MUST be possible to describe a sequence of
communications among choreographies.
|
|
|
|
D-CR-051
|
Category: Messaging
|
Level: MUST
|
|
A choreography definition language MUST provide a
construct that describes the sending of a single message.
|
|
|
|
D-CR-055
|
Category: Messaging
|
Level: SHOULD
|
|
It SHOULD be possible to define a choreography that uses a
callback mechanism.
|
|
|
|
D-CR-060
|
Category: Messaging
|
Level: MUST
|
|
It MUST be possible to define a choreography without
having to specify the contents of the messages being used.
|
|
|
|
D-CR-015
|
Category: Interfaces
|
Level: MUST
|
|
A choreography MUST provide the ability to have prose
associated with it to enable its behavior to be explained.
|
|
|
|
D-CR-044
|
Category: Interfaces
|
Level: MUST
|
|
A choreography MUST enable information hiding.
|
|
|
TBD
|
D-CR-017
|
Category: Transaction
|
Level: SHOULD
|
|
A choreography SHOULD enable an agreement or agreement(s)
that provides the business context of the choreography
definition.
|
|
|
|
D-CR-037
|
Category: Transaction
|
Level: MUST
|
|
It MUST be possible to describe a behavior recursively.
|
|
|
|
D-CR-038
|
Category: Transaction
|
Level: MUST
|
|
It MUST be possible to describe conditional behavior for a
choreography.
|
|
|
|
D-CR-048
|
Category: Transaction
|
Level: MUST
|
|
It MUST be possible to describe a choreography in terms of
its messaging behavior.
|
|
|
|
D-CR-057
|
Category: Transaction
|
Level: MUST
|
|
It MUST be possible to define multi-party interaction.
|
|
|
|
D-CR-058
|
Category: Transaction
|
Level: SHOULD
|
|
It MUST be possible for a choreography to modify its
behavior based on its operational context.
|
|
|
|
D-CR-059
|
Category: Transaction
|
Level: MUST
|
|
It MUST be possible to describe negotiation between Web
Services participating in a choreography, where the result
of a transaction may depend on repeated iterations of an
ask/answer cycle.
|
|
|
|
D-CR-003
|
Category: Composition
|
Level: MAY
|
|
A choreography MAY have run time changes that allow the
actual participants to vary.
|
|
|
|
D-CR-006
|
Category: Composition
|
Level: MUST
|
|
It MUST be possible to describe choreographies as a
composition of other choreographies.
|
|
|
|
D-CR-019
|
Category: Composition
|
Level: MUST
|
|
It MUST be possible to make a choreography C2 dependent on
another choreography C1 such that you can only create a
new instance of C2 after a related instance of C1 has been
completed.
|
|
|
|
D-CR-024
|
Category: Composition
|
Level: MUST
|
|
It MUST be possible to dynamically determine the
participants in a choreography at runtime.
|
|
|
|
D-CR-034
|
Category: Composition
|
Level: MUST
|
|
Choreographies MUST be composable into a hierarchy.
|
|
|
|
D-CR-036
|
Category: Composition
|
Level: SHOULD
|
|
Choreographies SHOULD be able to call other choreographies
in a hierarchical fashion.
|
|
|
|
D-CR-040
|
Category: Composition
|
Level: MUST
|
|
It MUST be possible to describe parallel composition of
services.
|
|
|
|
D-CR-041
|
Category: Composition
|
Level: MUST
|
|
It MUST be possible to model events that are strictly
related in time, as well as those that are unrelated in
time - i.e. parallelism or partial ordering.
|
|
|
|
D-CR-042
|
Category: Composition
|
Level: MAY
|
|
A choreography MAY have run time changes that allow the
behavior of the actual choreography to vary based on
state.
|
|
|
|
D-CR-047
|
Category: Composition
|
Level: MUST
|
|
It MUST be possible to define a new choreography by
"extending" an existing one.
|
|
|
|
D-CR-054
|
Category: Composition
|
Level: SHOULD
|
|
A choreography SHOULD express the composition of
participant Web Services into a new service.
|
|
|
|
D-CR-062
|
Category: Composition
|
Level: MUST
|
|
It MUST be possible to dynamically add sub-choreographies
to a "running" choreography.
|
|
|
|
D-CR-008
|
Category: Testing and Validation
|
Level: MUST
|
|
An implementation of a process that is following a
choreography MUST be able to verify that the choreography
is being followed correctly as specified in the
choreography definition.
|
|
|
|
D-CR-049
|
Category: Testing and Validation
|
Level: MUST
|
|
It MUST be possible to validate a choreography definition
for correct behavior at the time it is designed.
|
|
|
|
D-CR-050
|
Category: Testing and Validation
|
Level: MUST
|
|
It MUST be possible to validate a choreography definition
for correct behavior at the time it is in operation.
|
|
|
|
D-CR-012
|
Category: Ease of Use
|
Level: MUST
|
|
A choreography MUST be uniquely named.
|
|
|
|
D-CR-025
|
Category: Support for Semantics
|
Level: SHOULD
|
|
There SHOULD be a distinction between a
"participant" and a "role", where the
participants might be dynamic but the roles need not be.
|
|
|
TBD
TBD
TBD
No requirements document can provide complete coverage for any
particular technology. However, these use cases, and 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.
DAML-S
DAML-S: Semantic Markup for Web Services, The DAML
Services Coalition, Version 0.9 Beta. Available from http://www.daml.org/services/daml-s/0.9.
SOAP-1.2
Simple Object Access Protocol (SOAP) 1.1, Martin Gudgin,
Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk
Nielsen, Editors. World Wide Web Consortium, 24 June 2003.
Available from http://www.w3.org/TR/soap12-part1.
RFC2119
S. Bradner, RFC 2119: Key words for use in RFCs to Indicate
Requirement Levels, Internet Engineering Task Force, 1997.
Available from http://www.ietf.org/rfc/rfc2119.txt.
WS-ARCH
Web Services Architecture, David Booth, Michael Champion,
Chris Ferris, Francis McCabe, Eric Newcomer, David Orchard,
Editors. World Wide Web Consortium Working Draft. Available from http://www.w3.org/TR/ws-arch.
WS-CHOR
Web Services Choreography Working Group Charter, World
Wide Web Consortium, January 2003. Available from http://www.w3.org/2003/01/wscwg-charter.
WSDL-1.2
Web Services Description Language (WSDL) Version 1.2 Part 1:
Core Language, Roberto Chinnici, Martin Gudgin, Jean-Jacques
Moreau, Sanjiva Weerawarana, Editors. World Wide Web Consortium
Working Draft. Available from http://www.w3.org/TR/wsdl12.
BPEL
Business Process Execution Language for Web Services Version
1.1, Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron
Goland, Johannes Klein, Frank Leymann, Kevin Liu, Dieter Roller,
Doug Smith, Satish Thatte, Ivana Trickovic, Sanjiva Weerawarana.
BEA, IBM, Microsoft, SAP, and Siebel, 2003. Available from http://www-106.ibm.com/developerworks/library/ws-bpel.
BPML
Business Process Markup Language 1.0, Assaf Arkin.
BPMI.org, 2002. Available from http://www.bpmi.org/specifications.esp.
BPSS
ebXML Business Process Specification Schema Version 1.01,
ebXML Business Process Project Team. UN/CEFACT and Oasis, 11 May
2001. Available from http://www.ebxml.org/specs/ebBPSS.pdf.
CSF
Chief Executives Define Their Own Data Needs, Rockart, J.,
Harvard Business Review, March/April 1979.
UML
Unified Modeling Language Version 1.5, Object Management
Group, March 2003. Available from http://www.omg.org/technology/documents/formal/uml.htm.
WSA-REQ
Web Services Architecture Requirements, Daniel Austin, Abbie
Barbir, Christopher Ferris, Sharad Garg, Editors. World Wide Web
Consortium Working Draft, 14 November 2002. Available from http://www.w3.org/TR/wsa-reqs.
WSCI
Web Service Choreography Interface 1.0, Assaf Arkin, Sid
Askary, Scott Fordin, Wolfgang Jekeli, Kohsuke Kawaguchi, David
Orchard, Stefano Pogliani, Karsten Riemer, Susan Struble, Pal
Takacsi-Nagy, Ivana Trickovic, Sinisa Zimek, Editors. World Wide
Web Consortium, 15 March 2001. Available from http://www.w3.org/TR/wsci.
WSCL
Web Services Conversation Language (WSCL) 1.0 W3C Note 14 March
2002, Arindam Banerji, Claudio Bartolini, Dorothea Beringer,
Venkatesh Chopella, Kannan Govindarajan, Alan Karp, Harumi Kuno,
Mike Lemon, Gregory Pogossiants, Shamik Sharma, Scott Williams,
Editors. World Wide Web Consortium, 14 March 2002. Available from
http://www.w3.org/TR/wscl10.
WS-COOR
Web Services Coordination (WS-Coordination), Felipe
Cabrera, George Copeland, Tom Freund, Johannes Klein, David
Langworthy, David Orchard, John Shewchuk, Tony Storey. BEA, IBM and
Microsoft, 2002. Available from http://www-106.ibm.com/developerworks/library/ws-coor/.
WS-TRANS
Web Services Transaction (WS-Transaction), BEA, IBM and
Microsoft, 2002. Available from
http://www-106.ibm.com/developerworks/webservices/library/ws-transpec/.
The editors would like to thank Jack Herer, Len Greski, and all of
the members of the Web Services Choreography Working Group for
their assistance.