Web Services Choreography Requirements 1.0

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 analagous behaviour.

The client has declared it's external observable behaviour as described above.

The server has declared it's external observable behaviour 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 not explicit post-conditions. Implicitly the system must return to Idle for both the Client and the Server and this can be done by ensuring that the Client sends a "close" and that the Server is ready to receive a "close"

This use case shows a clear problem with potential LiveLock situations. In this example it is possible that any Clienti is locked out from dealing with a server forever. Generates the following requirements:

1. The ability to uniquely name a behaviour (i.e. IdleServer, BusyServer, IdleClient, BusyClient).

2. The ability to describe a behaviour in terms of their interaction. Their interaction is defined as the sending of a communication on a named channel (o,req,resp,c).

3. The ability to describe a behaviour recursively (i.e. the defn of BusyServer refers to itself).

4. The ability to describe a behaviour that has choice to enable different behaviours to be references (i.e. the use of the + operator).

5. 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 composition, the behavioural contract that exists between a Client and a Server can be defined in pi-calculus as follows:

ComposedSystem = (!IdleClient | IdleServer)

The Composed system enables Clients to communicate with a Server. IdleClient1 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 IdleClienti.

1. This ability compose behaviours into higher level processes such as our ComposeSystem above gives rise to another requirement, namely

2. The ability to describe parallel composition of services (i.e. the "|" operator).

The use case demonstrates some of the basic interactions and behaviours that may be required to enable us to describe a choreography between two processes.

Network Agent Actor: Resposibility is to detect Devices or agnets on devices and their ontology.

A device (sensors, cell phones, printers) manufacturer builds a device that interoperates with (sensor/actuator) devices built by other manufacturers. The 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 by 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. The 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 the possible device configurations to achieve interoperability.

Device is connected to the network. An agent is online.

Device is aware of its capabilities.

Device attaches to network and become on-line.

Device is detected by agent.

Successful instalation of device to network.

Simple Client Server.

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 customer satisfaction and sell packages. The service providers are aiming at selling as many products as possible. The credit card companies guarantee and do the payments of the purchased products. Developers use WSDL and platforms to create instances of web services.

Basic assumptions for the use case:

1. 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.

2. Service providers (airlines, bus companies, hotel chains, etc) are providing Web services to query their offerings and perform reservations.

3. Credit card companies are provide services to guarantee payments made by consumers.

4. The discovery of the specific service providers and metadata happens prior to the invocation, and that 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 very large number of cases by making payment Web services available and make profit with each money transaction. The consumer books a vacation easily by choosing among a large variety of offers. Only the user in the scenario is a human being. The travel agent service, airline, hotel and payment services that the travel agent service is interacting with, are agents.

User logs on the web site to perfrom a reservation.

User is capable of successfully completing the transaction.

Simple Clinet Server.

Service and Device Interoperability.

Buyer View

Seller View

This business process use case entails two different paths on an ordering process from the view of two actors: The 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:

1. Multiple paths can occur

2. Is successful completion of any one path substantive or not (affect final outcome)? Here the seller sees the 'Handle questionnaire' as an obligation. This may not hold true for the buyer.

3. Opens question of optional behavior and what is allowed in the context of a business process and choreography (affects interoperability).

4. Raises questions about pre-post conditions as well as the impact of other business processes or external events.

Variation on the Case listed below:Similar to case (1) except raises exception issue

1. Exception propagation up and down the stack

2. Business action based on exception.

The business pre-condition is that 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 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 on 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.

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:

1. Pick a product.

2. Pay for a product.

3. Ship a product.

4. Deliver product.

Otherwise, if not Customer X, apply the default choreography definition:

1. Pick a product.

2. Apply a quality check (see business rule).

3. Pay for a product.

4. Apply a quality check (see business rule).

5. Ship the product.

6. Deliver product.

Order is completed successfully.

Exception propagation.

When combined with the exception propagation use case, external events may affect the ultimate business outcome of the ordering process use case focusing on alternative paths.

Upon entry, this use case evidences the following potential requirements:

1. Choreography agreement or an agreement(s) that provides the business context of the choreography definition.

2. Process controls and sequencing options: Sequence / order is affected by the agreement or references in the choreography definition.

3. The outcome given order or the assumptions about the outcome of the given order is based on the business context and agreement(s).

4. Nested processes or choreography sets: Dependencies may exist between or within processes (Whether they are substantive or not should be discussed).

5. Optional paths may be taken that affect dependencies and outcomes.

6. From a business perspective, selecting one or the other could have different agreement implications if an error occurs

Buyer View

Seller View

Quality Control or Customs View (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 agrement, 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 the Business Process B where Quality Control evaluates the Questionnaire. During shipment, a Customs Control process (Business Process C) may be initiated that affects 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 collaboration [higher level].

This business case step should address these requirements:

1. Exception handling/propagation

2. Choreography and choreography sets

3. Typing of exceptions (process and control failure)

4. Signal impacts if used to indicate process validation success or failure (receipt acknowledgement or acceptance acknowledgement)

5. Confirmation that the propagation occurs to the application as opposed to the service or service interface

6. Integration of process and control flow failures (such as Process [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 pre-condition is:

1. 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.

2. An exception on 'Handle Questionnaire' can not 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 the Business Process B is exposed or not, the exception affects the outcome of Business Process A.

For Business Process C, the pre-condition is:

1. A business rule has been applied either prior to process initiation or during the process, where the business rule is required, and a Customs Control' check is initiated. An order is to be shipped to the Buyer by the Seller to an international location. Therefore, the pre-condition is an international order is processed. International is defined as a condition whereby the ship-to location is considered to be international and subject to regional customs requirements.

2. An exception on 'Customs Control' can not 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.

3. Exception propagation SHOULD occur within Business Process B and C, to the originator of the service request (For example, 'Handle Questionnaire' within the parent process, Business Process B).

The triggering event for an Exception is an exception in the process for Business Process B or C, which is considered substantive to the completion of Business Process A.

The business state of the externally observable behavior or process outcomes SHOULD be known by the Buyer and the Seller. If an event, outside of the observable behavior, impacts the state and progress of the Business Process, the events or the services MAY be 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 is shown in Figure 1. An exception has the following paths:

1. See Ordering Process

2. 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.

3. The Customs Control process checks the conditions of Order and provides the result back to Business Process A.

4. The results of the Customs Control Process MUST be reported back to Business Process A, as it 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.

Seel Alternate Flows for further details.

For Quality Control related to Handle Questionnaire:

1. See Ordering Process.

2. 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.

3. The Quality Control process checks the conditions of Order and provides the result back to Business Process A.

4. The results of the Quality Control Process MUST be reported back to Business Process A, as it 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 of the possibility that exceptions could occur anywhere in this stack. And what requirements that could levy on:

1. Exception handling within and across processes

2. Impact of conflicting business requirements

3. Dependencies within a or between business process (es)

4. Agreements

5. Auditing and reporting

6. State management and timing within a or between business process (es)

7. Differentiation between errors and exceptions (For example, the latter SHOULD typically be known and therefore, handled).

Finally, it is an open question if 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.

This use case describes the idea of creating an *instance* of a choreography definition (i.e. an actual choreography) that allows one role to inquire on the 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.

Successful recovery of order.

Simple Client Server.

Buyer Agent

Supplier Agent

Use case illustrate the dependencies between two Choreographies. The details are explained in the event flow section.

A Buyer sending a Supplier an order status request.

Succesful completion of two choreographies.

1. Buyer - Role that requests a quote from the supplier

2. Supplier - Role that provides products / services for the Buyer to purchase directly, potentially aggregating products from one or more manufacturers.

3. Manufacturer - Role that makes one or more products that are covered in a request for quotation from the Buyer. The Manufacturer role does not have a direct relationship with the Buyer.

The request quote from Supplier use case describes a situation where 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:

1. Contract provisions, including

   
   

   1. Start and end times when contract is valid (e.g. how long is the quote valid?)

   2. Renewal policies

   3. Responsibilities for each party (i.e. CRCs for each role)

   
   
   

2. Service level agreements

   
   

   1. Response time

   2. Service availability

   
   
   

3. Security provisions

4. Privacy provisions

5. Non-repudiation

6. Escalation procedures

7. Exception handling

The 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

1. Supplier has a defined interface for quoting items it supplies to Buyers.

2. Buyer knows Supplier item identifiers for items requested for quotation.

3. 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.

1. Buyer receives a quote for products requested from supplier, including pricing and availability.

2. Quote conforms to contract specifications.

3. Contract specifications are saved by Supplier and Buyer.

4. Supplier has commitments to receive product from Manufacturer(s), per Buyer's requirements.

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 quote event sequence

1. Need to distinguish the idea of a contract between services (e.g. the equivalent of CRCs) from a legal contract.

2. Need additional detail about what happens with the agreed to contract provisions.

User Agent from Lrge Company

User Agent from a small company

This use case charts a major corporations' efforts to gain control over the message choreographies used between its various systems. The work uses RBC as the example company. RBC sells the Really Big Product (RBP) that requires the cooperation of approximately 100 different tiny companies. 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, Tiny Company 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 that describes 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 sub-systems 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

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 then. The solution RBC choose was to make their cDl support segmentation, e.g. 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 the other three activities and to hook all the choreographies for all the activities together using segmentation.

However RBC still had a problem, 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 sub-systems which didn't need to be understood in detail in order to see the over all system flow. Segmentation didn't solve this problem because segmentation allows one to hide information not add a level of indirection. The solution RBC choose was to make their cDl hierarchical, e.g. allow 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.

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 of 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 sub-contractors on a project to build a new bridge. Recognizing the need to work closely together they decided to implement a series of web services to enable the companies to submit proposed changes to the bridge's design. The 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.

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.

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 Particpants 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 which 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 CP's get together at A, B and C and describe their own roles using a cDL and then get together to knit the three cDL's together thus forming 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 QoS of the underlying transport.

The low level design This choreography is then used to do drive the development of the web services at A, B and C. In the case of A, who has no existing web service that meets these requirements it is used to generate the appropriate code skeletons based on their favourite cPL. In the case of B who have a couple of web services that together will meet the requirements, they stitch it together as a choreography itself and restrict the visibility of the web services that they use to do it offering only entry and exit points in the sub-choreography. In the case of C, well it turns out they have 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 step up to 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 behaviours of each others systems thus ensuring 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 regulators 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, 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 is provisioned. The regulators 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.

An order is either fulfilled or cancelled. This can occur because an order was shipped and received or an order was terminated because of some exception that occurred or because the customer cancelled the order.

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 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 code using a cPL, examples of cPL's 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 behaviour 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 behaviour of a participant with respect to it's role.

• A cDL can be used to generate test cases.

• A cDL is independent and orthogonal to the language in which it's participating web services are implemented.

As a consequence of this a cDL may not need to be executable and there maybe a reason to have this fact stated in some way in a cDL language.