WS Choreography Model Overview

3.1.1 Roles

A Role identifies a set of related behaviors, for example the Buyer role is associated with purchasing of goods or services and the Supplier role is associated with providing those goods or services for a fee.

3.1.2 Participants

A Participant identifies a set of related Roles, for example a Commercial Organization could take both a Buyer Role when purchasing goods and a Seller role when selling them.

3.1.3 Relationships

A Relationship is the association of two Roles for a purpose. A relationship represents the possible ways in which two roles can interact. For example the Relationships between a Buyer and a Seller could include:

• A "Purchasing" Relationship, for the initial procurement of goods or services, and

• A "Customer Management" Relationship to allow the Supplier to provide service and support after the goods have been purchased or the service provided.

Although Relationships are always between two Roles, Choreographies involving more than two Roles are possible. For example if the purchase of goods involved a third-party Shipper contracted by the Supplier to deliver the Supplier's goods, then, in addition to the Purchasing and Customer Management relationships described above, the following relationships might exist:

• A "Logistics Provider" relationship between the Supplier and the Shipper, and

• A "Goods Delivery" relationship between the Buyer and the Shipper.

3.3.1 Choreography Composition

Choreography Composition is the creation of new Choreographies by reusing existing choreography definitions. For example if two separate Choreographies were defined as follows:

• A Request for Quote (RFQ) Choreography that involved a Buyer role sending a request for a quotation for goods and services to a Supplier to which the Supplier responding with either a "Quotation" or a "Decline to Quote" message, and

• An Order Placement Choreography where the Buyer placed and order for goods or services and the Supplier either accepted the order or rejected it.

You could then create a new "Quote and Order" Choreography by reusing the two where the RFQ choreography was executed first, and then, depending on the outcome of the RFQ Choreography, the order was placed using the Order Placement Choreography.

In this case the new choreography is "composed" out of the two previously defined choreographies. These choreographies may be specified either:

• Locally, i.e. they are included, as a Sub Choreography, in the same choreography definition as the choreography that performed them, or

• Globally, i.e. they are specified in a separate choreography definition that is defined elsewhere.

Using this approach, Choreographies can be recursively combined to support choreographies of any required complexity allowing more flexibility as Choreographies defined elsewhere can be reused.

3.3.2 Import Statements

An Import statement can contain references to a complete Choreography or part of a Choreography.

Import statements must be interpreted in the sequence they occur.

When the Import statement contains references to variables or other data that have the same identity, then the content of the later Import statement replaces the same content referenced by the earlier Import statement.

This means, for example, that if an initial Choreography definition referenced by an Import statement contained variables, etc, that were defined in an Abstract way, then the replacement definition could either be Portable or Concrete.

It also enables one Choreography definition to effectively be "cloned" by replacing the definitions for some or all of its variables.

3.4.1 Types

3.4.2 Variables

Variables capture information about objects in a Choreography. They have the following usages as defined by the Variable Usage:

• Information Exchange Variables that contain information such as an Order that is used to:

  • Populate the content of a message to be sent, or

  • Populated as a result of a message received

• State Variables that contain information about the State of a Role as a result of information exchanged. For example:

  • When a Buyer sends an order to a Seller, the Buyer could have a State Variable called "OrderState" set to a value of "OrderSent" and once the message was received by the Seller, the Seller could have an State Variable called "OrderState" set to a value of "OrderReceived". Note that the variable "OrderState" at the Buyer is a different variable to the "OrderState" at the Seller

  • Once an order is received, then it might be validated and checked for acceptability in other ways that affect how the choreography is performed. This could require additional states to be defined for "Order State", such as: "OrderError", which means an error was detected that stops processing of the message, "OrderAccepted", which means that there were no problems with the Order and it can be processed, and "OrderRejected", which means, although there were no errors, it cannot be processed, e.g. because a credit check failed.

• Channel Variables that contain information that describes how and where a message is sent to a Role. For example, a Channel Variable could contain information such as the URL to which the message should be sent, the policies that are to be applied, such as security, whether or not reliable messaging is to be used, etc.

• Other Variables including

  • Locally Defined Variables that contain information created and changed locally by a Role. They can be Information Exchange, State or Channel Variables as well as variables of other types. For example "Maximum Order Amount" could be data created by a seller that is used together with an actual order amount from an Order received to control the flow of the choreography. In this case how Maximum Order Amount is calculated and its value would not be known by the other Roles

  • Common Variables that contain information that is common knowledge to two or more Roles, e.g. "OrderResponseTime" which is the time in hours in which a response to an Order must be sent

The value of Variables can be:

• Known by all the roles prior to the start of the choreography

• Assigned by one role and optionally communicated to other roles

• Assigned as a result of an interaction

• Assigned by one role from other information

• Used to determine the decisions and actions to be taken in a Choreography.

The way Variables are defined will vary depending on the type of choreography.;

3.4.3 Tokens

A Token is an alias for a piece of data in a variable or message that needs to be used by a Choreography. Tokens differ from Variables in that Variables contain values whereas Tokens contain information that defines how to access the piece of the data that is relevant.

For example a Token for "Order Amount" within an Order business could be an alias for an expression that pointed to the Order Amount element within an XML document. This could then be used as part of a condition that controls the flow of a choreography, for example "Order Amount gt; $1000"

All tokens may have a type, for example, an Order Amount would be of type amount, Order Id could be alphanumeric and counter an integer.

The way these tokens are defined will vary depending on the type of choreography.;

3.5.1 Interaction Roles

Interactions always have a "direction" in that there is a From Role that sends the original message and a To Role that receives the message. In the case of a request/response MEP, the "To Role" will also send a response message back to the "From Role".

3.5.2 Interaction Message Content

Message Content identifies the type of information that is exchanged between the roles and the Information Exchange Variables used as follows:

• One Way From Message is the variable that is the source for a One-Way Message at the From Role

• One Way To Message is the variable that is the destination for a One-Way Message at the To Role

• Request From Message is the variable that is the source for Request Message at the From Role

• Request To Message is the variable that is the destination for Request Message at the To Role

• Response To Message is the variable that is the source for Response Message at the To Role

• Response From Message is the variable that is the destination for Response Message at the From Role

The type of information that is referenced will vary depending on the type of the Choreography.;

3.5.3 Interaction Channel Variables

A Channel Variable contains information on where and how to send information to a specific instance of the To Role. This is because Concrete Channel information plus Correlation information about a Choreography contains sufficient information to identify how to send messages to a specific instance of a process.

Additionally, Channel Variable information can be passed within Message Content. This allows the destination for messages in a choreography to be determined dynamically.

For example, a Buyer could specify Channel information to be used for sending delivery information. The Buyer could then send the Channel information to the Seller who then forwards it to the Shipper. The Shipper could then send delivery information directly to the Buyer using the Channel Information originally supplied by the Buyer.

The content varies depending on the type of the choreography.;

At run time, information about a channel variable is expanded further. This requires that the messages in the Choreography also contain Correlation information, for example by including:

• A SOAP header that specifies the correlation data to be used with the Channel, or

• Using the actual value of data within a message, for example the Order Number of the Order that is common to all the messages sent over the Channel

In practice, when a Choreography is performed, several different ways of doing correlation may be employed which vary depending on the Channel Type.

3.5.4 Interaction Operations

An Operation specifies the particular part of an interface that is the target for a message. The content varies depending on the type of choreography.;

3.5.5 Interaction State Changes

States contain information about the State of a Role as a result of information exchanged in the form of an Interaction. For example after an Interaction where an order is sent by a Buyer to a Seller, the Buyer could create the State Variable "Order State" and assign the value "Sent" when the message was sent, and when the Seller received the order, the Seller could also create its own version of the "Order State" State Variable and assign it the value "Received".

As a result of a State Change, several different outcomes are possible which can only be determined at run time. The Interaction lists each of these allowed State Changes, for example when an order is sent from a Buyer to a Seller the outcomes could be one of the following State Changes:

1. Buyer.OrderState = Sent, Seller.OrderState = Received

2. Buyer.OrderState = SendFailure, Seller.OrderState not set

3. Buyer.OrderState = AckReceived, Seller.OrderState = OrderAckSent

3.5.6 Interaction Based Alignment

In some choreographies there may be a requirement that, at the end of an Interaction, the Roles in the Choreography have agreement of the outcome. More specifically within an Interaction, a Role needs to have a common understanding of the state changes of one or more State Variables that are complimentary to one or more State Variables of its partner Role. Additionally within an Interaction, a Role needs to have a common understanding of the values of the Information Exchange Variables at the partner Role.

Without alignment the Buyer knows that her "OrderState" is set to "Sent", but does not know the value of the OrderState at the Seller. Once the Seller receives the Order then the Seller knows that his "OrderState" variable is set to "Received". He also knows the Buyers "OrderState" was set to "Sent", as the Choreography defines that the Buyer's Order State variable is set in this way when an Order is sent.

With Choreography Alignment the difference is that both the Buyer and the Seller have:

• State Variables such as Order State variables at the Buyer and Seller, that have Values that are complementary to each other, e.g. Sent at the Buyer and Received at the Seller, and

• Knowledge of the values of each others States Variables, i.e. the Buyer knows that the Seller's "OrderState" variable has the value "Received" and the Seller knows that the Buyer's "OrderState" variable is set to "Sent"

• Information Exchange Variables that have the same types with the same content, e.g. The Order variables at the Buyer and Seller have the same Variable Types and hold the same order

This assurance of the outcome with respect to States is achieved by an "agreement" protocol that is used in conjunction with the Choreography such as the Web Services and other specifications designed to coordinate long-running transactions.

3.5.7 Protocol Based Information Exchanges

The One-Way, Request or Response messages in an Interaction may also be implemented using a Protocol Based Exchange where a series of messages are exchanged according to some well-known protocol, such as the reliable messaging protocols defined in specifications such as WS Reliability.

In both cases, the same or similar Message Content may be exchanged as in a simple Interaction, for example the sending of an Order between a Buyer and a Seller. Therefore some of the same State Changes may result.

However when protocols such as the reliable messaging protocols are used, additional State Changes will occur. For example, if a reliable messaging protocol were being used then the Buyer, once confirmation of delivery of the message was received, would also know that the Seller's "Order State" variable was in the state "Received" even though there was no separate Interaction that described this.

3.6.1 Work Units

Each Work Unit has two optional conditions or guards associated with it:

• An Enabling Condition, which specifies a combination of states that must be available and also evaluate to true before the Work Unit can be performed, and

• A Repeat Condition that specifies a combination of states that, if they evaluate to true once the Work Unit is complete, means that the enabling condition of the Work Unit (if specified) is re-checked.

Examples of a Work Unit include:

• A Send PO Work Unit that includes Interactions for the Buyer to send an Order, the Supplier to acknowledge the order, and then later accept (or reject) the order. This work unit would probably not have a guard

• An Order Delivery Error Work Unit that is performed whenever the Place Order Work Unit did not reach a "normal" conclusion. This would have a Guard condition that identifies the error, see also Choreography Exceptions and Transactions

• A Change Order Work Unit that can be performed whenever an order acknowledgement message has been received and an order rejection has not been received.

3.6.2 Performed Choreography

The Performed Choreography Structure enables a Choreography to define that a separately defined Choreography is to be performed. The Choreography that is performed can be defined either within the same Choreography Definition or separately.

3.6.3 Assign

Assign sets, within one Role, the value of one Variable to the value of a Variable or Token, or makes a Token reference a Variable or another Token. The assignments may include:

• Assigning one Information Exchange Variable to another, for example so that a Choreography can define that a message received by one role is forwarded to another

• Assigning a Locally Defined Variable to part of the data contained in an Information Exchange Variable

3.6.4 NoAction

This Activity means that the choreography at this point should take no particular action. Examples of its use include:

• In a Work Unit, when there is a need to wait until the Guard condition on the Work Unit is true, for example you need to wait until say three separate Interactions are complete before progressing to the next step in the Choreography

• In a Choice so that you can enumerate all the possible choices even if some of the choices involve no Interactions.

3.6.5 Sequence Control Structure

The Sequence Control Structure enables a Work Unit to define that one or more Activities must be performed in sequence. It works by grouping the Activities within a lt;Sequencegt; ... lt;/Sequencegt;

Activities must be performed in the same sequence that they are defined.

3.6.6 Choice Control Structure

The Choice Control structure enables a Work Unit to define that only one of two or more Activities should be performed. It works by:

• Grouping the Work Units within a lt;Choicegt; ... lt;/Choicegt;

• Adding a Guard statement to each individual Activity within the Choice.

An Activity should only occur if the Guard on the Activity evaluates to true. Once one of the Activities in the Choice have been performed, then no other Activities in the Choice must be performed.

3.6.7 Parallel Control Structure

The Parallel Control Structure enables a Work Unit to define that Activities are performed in parallel. It works by grouping the Activities within a lt;Parallelgt; ... lt;/Parallelgt;

3.7.1 Exception Block

A Choreography can sometimes fail as a result of an exceptional circumstance or error. Different types of exceptions are possible including this non-exhaustive list:

• Interaction Failures, for example the sending of a message did not occur

• Protocol Based Exchange failures, for example no acknowledgement was received as part of a reliable messaging protocol

• Security failures, for example a Message was rejected by a recipient because the digital signature was not valid

• Choreography Sequence Failures, for example a Message was received that was not in the sequence as defined by the Choreography

• Timeout errors, for example an Interaction did not complete within a required timescale

• Validation Errors, for example an XML order document was not well formed or did not conform to its schema definition

• Business Process "failures" , for example the goods ordered were out of stock.

To handle these and other "errors" separate Work Units are defined in the Exception Block for each "exception" condition (as identified by its guards) that needs to be handled. Only one Work Unit per exception should be performed.

3.7.2 Transaction Block

Transaction handling allows one Choreography to perform another Choreography up to a suitable point and then later perform the Choreography again to compensate for its effects.

For example, a Choreography could exist that supported the purchasing of a property that involved exchanging information between many Roles including: a Purchaser who was buying the property, a Seller who was selling the property, a Buyers Agent who was advising the Purchaser, a Bank that was going to provide a mortgage, and a Title Company to prepare all the legal documents and handle the transfer of the actual moneys.

Only when the purchase was completed, could the choreography fully complete, and if the purchase fell through, then the effects of the Choreography would need to be reversed at each Role.

The Choreography model supports this type of example by defining a Transaction Block that contains one Work Unit that is followed when the effects of the Choreography need to be reversed.

In the example given above, this would work by defining a Choreography that:

• Performs one Choreography to carry out the main part of the process of creating and exchanging information required for the transaction

• Waits until the critical messages have been received that indicate that the transaction is either going to go ahead or fail

• Performs the main choreography again indicating that the effect of the Choreography should be Compensated by performing a Work Unit in the Transaction Block.