An interaction is the realization of a collaboration between roles. Roles are grouped into participants. Roles are analogous to the entities at the top of our UML sequence diagrams and participants group these roles into domains of control which can be said to be the location the behaviors defined by the roles.

With respect to our degenerate usecase a collaboration is a message exchange between the swim lanes in the sequence diagram in Figure 6. In the example when the buyer requests a quote a message is sent from the buyer to the seller with the details of the product included in the quote. The seller can either respond with a quote back to the buyer or can respond with a fault which indicates that the product is invalid. The WS-CDL fragment for this interaction is illustrated below:

Interactions are descriptions of one or more exchanges between a sender and a receiver. Interactions are labeled with an operation name that can be mapped to a WSDL operation, a topic in a publish-and-subscribe environment or a message queue in a point-to-point messaging environment. Interactions take place over a channel, as indicated by a channelVariable, the variable itself will have been declared to be of a particular channelType. The participating relationship further restricts the interaction to the roles that are valid for that relationship.

Each exchange names the type of the thing to be exchanged and the direction of the exchange (e.g. a request, a response, or a fault).

In our degenerate example we have one interaction called "Buyer requests a quote from the seller" which occurs over a channel variables called "Buyer2SellerC" with an operation name "quoteRequest". The interaction has three exchanges, one for the request called "Request Quote", one for the valid response called "Quote Response" and one for the fault called "Invalid Product".

In order to describe this more fully we have to define the channelType for the channelVariable called "Buyer2SellerC", in the interaction, and then define the information types "tns:QuoteRequestType", "tns:QuoteResponseType" and "tns:QuoteResponseFaultType" for the variables -, - and - respectively. We also need to define the relationships, roles and participants that are needed to support this interaction, such as "tns:Buyer2Seller", "tns:BuyerRole" and "tns:SellerRole".

Thus we shall do it in the following order:

1. Define our roleTypes,
2. Define our relationshipTypes,
3. Define our informationTypes,
4. Define our tokenType,
5. Define our channelTypes

There are 2 roles that are played out in the example. These are the “buyer” and the “seller”, they represent the same entities described in the sequence diagram in Figure 6. We define them as BuyerRole and SellerRole as follows:

In WS-CDL each role defined has a behavior. A behavior in this sense is the binding point for a WSDL description (either WSDL1.1 or WSDL2.0). The binding point is the interface which normally references a WSDL description but this is optional in WS-CDL. Because it is optional we can use this as a binding point to different service descriptions. In our example the respective interfaces for the roles BuyerRole and SellerRole are BuyerBehaviorInterface and SellerBehaviorInterface which do not refer to any WSDL description and so can be used by implementors to derive WSDL descriptions. For example one might well derive the WSDL descriptions and generate BuyerBehaviorInterface.wsdl and SellerBehaviorInterface.wsdl.

We shall look at how we would bind to an existing WSDL description in the Intermediate section.

The abstract syntax for roles is illustrated below:

In WS-CDL a "Participant" is a set of distinct roles that are implemented as a service. That is the behaviors that relate to the roles are all implemented by the same service. In a sense a "Participant" is akin to a Web Service in which the WSDL that describes that service fulfills the functional description needed to implement the collection of behaviors that the roles require to meet their obligations and in which the Web Service is implemented by the same logical entity albeit a organisation or line of business within an organisation.

"Participants" turn out to be very important in a WS-CDL description, which is why they are mandatory, because they represent the grounding of behaviors into a process - the Web Service that implements them. This is important because it governs our need to ground where things happen for the purpose of behavioral type checking and in understanding who may share what information. Normally roles do not share information, rather information is explicitly exchanged to gain a common understanding in a landscape of peer services. In the case of a "Participant" the information within a "Participant" may be shared in the same sense of information existing in some shared memory between different threads in a process. From a WS-CDL perspective this sharing is based on the roles within the participant. Thus the roles may share information within the boundary of the participant.

From a WS-CDL modeling perspective we might simply consider a "Participant" to be a collection of roles that are represented physically as a single service. In our example the roles would be members of their own participant so there would be a one-to-one mapping. Thus the roles BuyerRole and SellerRole would be in the participants Buyer and Seller respectively.

In WS-CDL the participants for our example would be written as follows:

Once we have some roles defined we can define the relationships. In WS-CDL a relationship declares an intention to interact between two roles. In a sequence diagram this is akin to any two of the actors in a sequence diagram that have connecting arrows in any direction. In our example we have relationships between the BuyerRole and the SellerRole and we would define it as the relationship Buyer2Seller as follows:

A relationship comprises a name and two role types. We use the convention in this document that the first role type defines the “from” role and the second the “to” role and connect them with the number 2, thus all of our relationships are of the form from2to. WS-CDL does not distinguish between the "to" and "from" roles in a relationship. We simple use this convention as a convenience. It does not imply any directionality with respect to the relationship and is only a naming convention for the primer.

The abstract syntax for relationships is defined as follows:

The informationTypes in a choreography are used to describe the types for many of the variables that we might use in a choreography. They are used to describe the types of messages that we might send between roles in an interaction. In our example we have information types we need to declare for the "request", "response" and "faultResponse". We shall call these QuoteRequestType, QuoteResponseType and QuoteResponseFaultType respectively.

We shall need a few other information types for our tokens, token locators and channel types. We shall explain why they are needed in the section that deals with tokens locators and channel types. For the purpose of completeness we shall define them here and they are called IdentityType and URI.

In WS-CDL the full description is as follows:

The abstract syntax for defining information types is as follows:

A token provides a mechanism for defining an alias for an information type. Token locators can then be defined to locate a particular token from within a message type. We define some tokens and token locators here because they are needed when defining channel types.

The key uses of tokens and locators are as follows:

• Tokens and their locators are used to define the identity attributes that ensure channel communication can be correlated. A token provides a mechanism for defining an alias for an information type. Token locators can then be defined to locate this particular token from within a message type. Tokens and token locators are shown here to define channel types

• The tokens we define will also be used to refer to a service reference, that is a url, for a web service. In this context a token defines an alias to the web service so that we can refer to it by a shorter name. In our degenerate example we do not reference any web service url but for the sake of completeness we define a URL token here. From an implementation perspective as opposed to a pure usage perspective the channel type reference is needed to understand what data type will be used to transfer an endpoint reference between services when channel passing is enacted. We shall visit channel passing later on in the intermediate section.

  The two informationTypes included earlier are used as references in the token and token locator definitions.

• Tokens and their locators are a mechanism to make the choreography description more readable and more maintainable through the indirection that they afford. Thus tokens and locators can be used as a simple alias mechanism to refer to informationTypes that have been previously defined and to refer to information within instances of informationTypes such as the purchase order number or the amount or value of an order and even the time to live of a quote which itself may timeout at some point.

We define the tokens id, which represents the information type IdentityType, and URI, which represents the information type URI. We define locators for QuoteRequestType, QuoteResponseType and QuoteResponseFaultType that will cause the identity information, associated with token id, for the informationTypes to be obtained from the contents of these messages when exchanged on the channel. The full description of the tokens and the locators is given below:

The abstract syntax for defining a tokens and token locators are as follows:

Finally, having defined our roles, information types, tokens and locators we are in a position to define our channel. Channels are the principle mechanism used to realize an interaction.

In our interaction we have a channel variables called Buyer2SellerC that has a type. A channel is named, described, and then related to the roles that realize its behavioral interface. A reference is provided to a service. The channel type will have the capability to derive its identity when in use.

The channel type we shall define is called Buyer2SellerChannel and it is defined as follows:

Our channel type, named Buyer2SellerChannel connects us from the BuyerRole to the SellerRole. The latter implements the service at the end of the channel. The reference simply refers to a service, in this case it does nothing for us because we have no specific service to refer to. The identity is marked as primary which means that the token id is interpreted as a primary key for correlation. The token locators we defined earlier are used together with the information type being sent or received on a channel to determine the actual key which can be a composite key if needed. In our example the identity is a single attribute.

The abstract syntax of a channel definition is provided below. We shall look at the other part of a channel type definition in later sections:

We can now consider describing the choreography itself. To do this we shall:

The only relationship we have is Buyer2Seller and we prefix this with the name space (tns).

Then we add the variable declaration based on the channel and information types that we have already defined for each of Buyer2SellerC, quoteRequest, quoteResponse and faultResponse which respectively are of types Buyer2SellerChannel, QuoteRequestType, QuoteResponseType and QuoteReponseFaultType. The variables are declared in a variableDefinitions block. In WS-CDL it is important to note that variables are always situated. That is variables are declared to reside at one or more roles independently of each other. This is why the variable declarations have a roleTypes attribute. In our degenerate example we declare our variables to be situated at both the buyer and the seller roles. The fact that two roles may have the same variable name does not have any meaning in WS-CDL. Using the roleTypes attribute in a variable declaration is simply for convenience. The same variable name could be declared twice at two different roles and this is the same as adding the two roles to the roleTypes. If you omit the roleTypes the default behavior is to declare the variable at all roles within this choreography where the roles are inferred from the declared relationships that participate in it.

The WS-CDL fragment below shows how the relationship and variable declarations are put together. We have named the choreography as DegenerateChoreography. We have also set the root attribute to be true because this choreography is the root of the interactions that will take place. When root is set to false the choreography is deemed not to start the interactions.

To recap, we have

What remains is to define the interactions and their ordering based on all that has preceded it.

We shall define our single interaction that we presented earlier within a sequence. We don't have to do this but it is good practice to start with a sequence and then add things to it. If you don't an explicit sequence then it is implied.

Thus our example now looks like the following:

In our example above there are three exchanges within a single interaction which is within a sequence. The first exchange is called QuoteRequest is based on a operation defined in the interaction called getQuote and this occurs over a channel variable called BuyerSellerC. This exchange is based on a message being sent from the buyer to seller which is of type tns:QuoteRequestType and it is marked as a request. The exchange also defines the variables that will be used to send and to receive the content of the message of type tns:QuoteResponseType, in each case the variable is called quoteRequest and appears inside a cdl function which understands how to get a variable called cdl:getVariable(...). The first parameter to this function is the name of the variable in the choreography, the second and third parameters in this case are left blank. The roles for these variables are inferred from the direction of the exchange and so we can infer ourselves that quoteRequest was populated before the interaction at the buyer and then when the exchange completes the seller's quoteRequest variable is populated with the same values. The variables are not shared but after the exchange they hold common knowledge between the roles that participate in the exchange.

The second exchange is similar to the first except that it is marked as a respond. As such we can infer the direction is from the seller back to the buyer.

The third and final exchange occurs if the seller finds a fault with the request and as a result decides to send a response, which is why it is marked as a respond. Because this is a fault, we also declare that the exchange has a faultName, in this case we have called the faultName InvalidProduct to denote that the product which is the subject of the quote request is invalid in some way. It could be because it does not exist or indeed because no stock exists at present and so no quote can be provided. The decision as to which one it really is, is obscured.

The abstract syntax for a choreography, thus far, is as follows:

Having described all of the necessary types and having described the salient aspects of the Choreography we present the complete example.

To continue with our example above we need to declare a variable that can be used to control the bartering process. We shall call this variable barteringDone and we shall give it a type of xsd:boolean which we shall declare as an information type in WS-CDL called Boolean. In WS-CDL variables are always situated (or located). That is they are defined at one or more roles. We have seen this already when we defined the channels and messages for the degenerate example. For our barteringDone we need to consider where the control for the value of the variable will be located. We need decide on the master for this process and the slaves. We shall select the SellerrRole as the master and so situate our variable at this role.

It is important to remember that when variables are manipulated in some way the manipulation is also situated. If a variable is situated at one role then it becomes clear that manipulation of that variable is also situation at the same place. When a variable is situated at more than one role we need to be clear about where manipulation takes place because the value of a variable after manipulation is scoped to that role and where it is situated.

Variables are not shared. Rather they exist at the roles they are defined at and only have the same value if some explicit exchange occurs that describes how they become the same value. The fact that they have they may have the same name has no bearing on the semantics of a variable as is no guarantee that they will ever hold the same content, but of course it would be normal to think that they might simply because they bear the same name. So it is good practice in describing choreographies to name variables well so that clarity can be preserved.

The scope of a situated variable, we say quoteRequest@buyer, is at it's role. So in this case it is at the buyer. The use of the @ sign has no significance in WS-CDL. We only use it here as a short hand to indicate where the variable is located. The same short hand is used in the formal description of WS-CDL which can be found at SOME URL TO MARCO'S WORK.

If we tried to copy quoteRequest@buyer to quoteRequest@seller we would exceed the scoping contract. It would not be allowed. If we tried to copy quoteRequest@buyer, in whole or in part, to x@buyer, where x is some variable declared at buyer, then it would succeed. The variable x@buyer after the copy was completed, would indeed have the same value as quoteRequest@buyer. If we wanted to ensure that quoteRequest@seller was populated with the same values as quoteRequest@buyer we would use an interaction in which the variables quoteRequest@buyer and quoteRequest@seller are in the appropriate send and receive parts of the exchange within the interaction, much as we did in our degenerate example in the previous section.

Our barteringDone variable will be situated at the SellerRole which we shall deem to be in control of the loop. The WS-CDL fragments for the information type and the variable declaration are shown below:

We may define other variables throughout the course of this section and we shall indicate where they are situated and what type they are as narrative.

In this section we look at repetitive workunits and come back to conditional workunits. A workunit provides repetition based on some predicate and provides a way of adding conditionality. Workunits in general have a Body that includes the other choreography structuring constructs. In the specification these structuring constructs are called ActionNotation. The ActionNotation is only performed if the workunits attributes enable it to be performed. In the case of a simple conditional the guard condition (G) is evaluated and if true the Body is performed. In the case of a simple repetition the guard condition (G) is omitted and so will always evaluate to true, the Body is therefore performed and if the repetition condition (R) evaluates to true it is performed again and again until the repetition condition evaluates to false. The more complex scenario is when a guard condition (G) and a repetition condition (R) are both present. In this case the workunit is dependent on the guard condition first and then the repetition condition afterwards. We present the general structure of, non-blocking (B is False), workunits as follows:

Where G and R are of type xsd:boolean Xpath expressions and B is an xsd:boolean constrained to be true or false. A typical order of evaluation is as follows:

Which equates to (in pseudo code):

IF G is always True THEN it equates to:

IF R is always False THEN it equates to:

In this extension to our simple bartering process we add a duration for a quote of 30 seconds. When a BuyerRole requests a quote the SellerRole sets a duration, or time to live, for the quote of 30 seconds. When a quote has exceeded this time then, as far as the SellerRole is concerned the quote becomes invalid.

This is modeled in the WS-CDL description presented below:

The description above is presented in psuedo-code as follows:

The two "Update" lines in the pseudo-code represent the records in the interactions and are tied to the quote response at the SellerRole. We shall look more closely how we define our records in the relevant interactions.

Often we need to record information returned from an interaction. For example we need some way of setting the duration on the quote time to live from the SellerRole to the BuyerRole. To do this WS-CDL provides us with a convenient way of recording information at both ends of an interaction. In our example above we add our record to the quote elicitation interactions so that the duration for the quote can be passed and used in the repetition above and we show these interaction as fragments of WS-CDL below:

Having recorded some information we now want to model the predicate and the activities that are dependent on the outcome of the predicate. To do this we use a conditional workunit that follows on from the recording example above, and we present this below:

In this example what we have done is ask some validation service if the buyer is valid. We have used a record to pull out the response and that response in the variable "buyerIsValid" is used in the guard for the workunit. The equivalent imperative language construct would be something akin to:

The body of the workunit that we described above we introduced a choice. The choice element is used to declare possible alternative paths in a choreography. In our example there are only three choices that can be made at this point. The quote could timeout, the buyer decides to accept the quote or the buyer requests an update to the existing quote. We model these as a silentAction for the timeout of the quote – we shall change this later on -, as a simple sequence for the buyer accepting the quote and as a complex sequence to handle the bartering process itself. After adding the basic components the workunit is illustrated below:

We shall start to elaborate the choice by defining the complex sequence that will control the bartering collaboration. What we shall describe are the interactions needed for the bartering process. We start by defining the interaction from buyer to seller to update the price, interaction name="Buyer updates the Quote - in effect requesting a new price", and the exchanges that comprise this interaction. We model this as an interaction within a sequence such that the exchanges are the outbound "updateQuote" and the inbound "acceptUpdatedQuote". This illustrated below:

The final choice element in this workunit is the element that manages the repeat variable "barteringDone". This sequence has two interactions, named "Buyer accepts the quote and engages in the act of buying" and "Buyer send channel to seller to enable callback behavior". The first describes the interaction between buyer and seller to accept the quote – this has an exchange called "Accept Quote" - and thus place an order. The second describes the additional information passed to the seller by the buyer – this has an exchange called "sendChannel" - so that a third party, in our case the shipper, may send back delivery details to the buyer without knowing the buyer before hand. To effect the exchange we need to make sure that the channel variable NAME that resides at both the buyer and the seller independently of each other is used as the output variable at the buyer and the input variable at the seller. To do this we use the WS-CDL function that gets a variable at a specified role. This is why we see "cdl:getVariable('DeliveryDetailsC','','')" and "cdl:getVariable('DeliveryDetailsC','','')" in the exchange. The role is omitted because it can be inferred through the channel used for interaction. The final part of the sequence is to change the value in the variable, "barteringDone", to "true"so that the workunit repeat condition evaluates to false and the workunit terminates. To do this we use an assign element and indicate the actual variable and where it resides my using the "cdl:getVariable('barteringDone','','')" WS-CDL function. This part of the workunit and choice is illustrated below:

In this section we examine how we use faults in WSDL (both WSDL1.1 and WSDL2.0) to drive exceptions in WS-CDL.

Credit Check returns a fault, which implies credit failure, and this is dealt with in an exception block and you raise an exception to interrupt the flow of the choreography. The Exception handler returns a message to the buyer to let them know that the order has been cancelled.

Supposing the credit checking (which implies debiting the card if ok) and the shipping details are done in parallel and are independent. Then we would have two finalizers which handle the yes go ahead or the no back out both. Add some further details that explain the use case in a real world situation in which separate legs of a trade are executed in parallel (e.g. arbitrage).

Add a silent action at the credit checker to show that something happens here to do the actual credit checking that is invisible. Silent variable conditional - silent conditional for sending back credit ok or credit fault.

The rest of the example is all about describing the interactions and choices needed by the seller to check credit and if successful to request delivery. This is listed in schematic form below. We have not filled all of the details because it is illustrated fully in Appendix I.

In this outline we can see a choice made after a credit check has been done. If the credit check fails we do very little. If it succeeds we "requestShipping" from seller to shipper and pass the buyer details that we got previously onto the shipper. The shipper then responds back to the buyer using the necessary channel details that were passed ("DeliveryDetailsC") to affect the interaction.

NOTE: In this section make sure we handle join conditions and arrays and lists.

NOTE: Description of the distributed choice problem