1 Introduction
1.1 Structure of the primer
This primer is intended to give an overview of WS-CDL and can be read by WS-CDL business users (e.g. a business analyst) and WS-CDL implementers (e.g software engineer) alike. The first 5 sections are intended for both audiences while the last is intended primarly for WS-CDL implementors.
Section 2 provides an overview of WS-CDL. The first half of Section 3 describes an example using UML sequence diagrams. The second half of Section 3 walks through building the WS-CDL description of the example. Section 4 examines WS-CDL at a deeper level describing how more advanced features can be employed through the use of the same example. Section 5 described the use of WS-CDL within an organization. Section 6 describes some of the implementation considerations for likely implementers.
2 An Overview of WS-CDL
It is essential in understanding Web Services Choreography Description Language (WS-CDL) to realize that there is no single point of control. There are no global variables, conditions or workunits. To have them would require them to be somewhere and that somewhere would be, by definition, a centralization point. WS-CDL is a language for specifying peer-to-peer protocols where each part wishes to remain autonomous and in which no party is master over any other – i.e. no centralization point. WS-CDL does permit a shorthand notation to enable variables and conditions to exist in multiple places, but this is syntactic sugar to avoid repetitive definitions. There is also an ability for variables residing in one service to be aligned (synchronized) with the variables residing in another service, giving the illusion of global or shared state.
It is also important to understand that WS-CDL does not distinguish between observable messages from applications, that might be considered as application or business messages, or from the infrastructure upon which an application is based, that might be considered as some form of signal. In WS-CDL all messages are described as information types and have no special signficance over each other. All that WS-CDl described is the ordering rules for the messages which dictate the order in which they should be observed. When these ordering rules are broken WS-CDL considers them to be out-of-sequence messages and this can be viewed as an error in conformance of the services that gave rise to them against the WS-CDl description regardless of how they may be derived.
WS-CDL is an XML-based language that can be used to describe the common and collaborative observable behavior of multiple services that need to interact in order to achieve some goal. WS-CDL describes this behavior from a global or neutral perspective rather than from the perspective of any one party and we call a complete WS-CDL description a global model.
Services are any form of computational process with which one may interact, examples are a buying process and a selling process that are implemented as computational services in a Service Oriented Architecture (SOA) or indeed as a Web Services implementation of an SOA. The distinction between SOA and Web Services is that the latter has its interface described using WSDL whereas the latter may not. Because WS-CDL is not explicitly bound to WSDL it can play the same global model role for both SOA services and Web Services.
Common collaborative observable behavior is the phrase we use to indicate describe the behavior of a system of services, for example buyer and seller services, from a global perspective. Each service has an observable behavior that can be described today using WSDL or some other interface description language (e.g. Java). Such observable behavior is described as a set of functions, possibly with parameters, that a service offers coupled with error messages or codes that indicate failure along with the return types for the functions offered. If we used abstract BPEL along with WSDL we can also describe the valid sequences of functions that cannot be done with WSDL or Java alone. We refer to this set as the “observable behavior” for a service. This level of “observable behavior” does not describe the order in which functions may be used. It may be the case in many services that a service requires a session open function and a session close function that bracket a long lived interaction. If we captured such ordering rules then we would have the observable behavior fully specified.
Individual service behaviors can be used in the composition of wider collaboration in which a set of services with their own behaviors could be gainfully employed and guaranteed to work. In order to do so a global model that described the peer to peer observable interactions of such a set of services is required to ensure that the services will in-fact cooperate to a commonly understood script. That script is the global model and that script is what WS-CDL is used to describe.
A global model, ensures that the common collaborative observable behavior is not biased towards the view of any one of the services. Instead it describes as peers the entire collaborative observable behavior of all of the services such that no one service can be said to exert any control over any other service. In effect it described the services as a complete distributed application in which each service plays a distinct role and has distinct relationships with its peer services.
One may think of WS-CDL as a language for describing the observable activities of a set of services some of which are synchronized through some common understanding realized by a specific business interaction between the services or by a declaration of interest in the progress of one service by another (e.g. has the buyer accepted the price offered by the seller). The least interesting scenario is one in which WS-CDL can be used to describe a set of services that never synchronize at all; that is there is no observable relationships and no statement of an unobservable relationship that exists between the services. In this case the services perform a choreography, but effectively on different stages and thus need no form of coordination (e.g. a buyer and seller choreography for WallMart versus a Bloomberg Reuters choreography for the exchange of news items). In all other cases the synchronization is what makes life interesting (e.g. a buyer seller choreography coupled with a seller credit check choreography or indeed a seller shipper choreography).
In WS-CDL the mechanisms for describing the common observable behavior range from specific information alignment (e.g. when a buyer and seller record the fact that an order has been accepted in variables that reside at the buyer and at the seller), interaction (e.g. when a buyer requests a price from a seller and receives a price as a response from the seller) and a declaration of interest in the progress of a choreography (e.g. has the bartering choreography between buyer and seller “started” or has it “finished”). In the first two cases synchronization is explicit and visible as a business related activity (e.g. the observable recording of information and it’s alignment and the description of an information exchange between a buyer and seller) and in the last case (e.g. choreography has “started” or “finished”) it is implicit based on the progress of a choreography and not any business relationships.
2.1 Using WS-CDL
WS-CDL is a description and not an executable language, hence the term “Description” in it’s name. It is a language that can be used to unambiguously describe observable service collaborations, we might also refer to this a business protocols within and across domains of control that govern how the services interact.
When WS-CDL is focused on describing collaboration within a domain of control (e.g. a single company or enterprise) WS-CDL is used to describe the internal workflows that involves multiple services (also called end-points) that constitute observable collaborative behavior. The value in so doing is to encourage conformance of services to a negotiated choreography description and to improve interoperability of services through an agreed choreography description. This is no more than describing a business protocol that defines an observable collaboration between services. You can think of it as a way of ensuring services are well behaved with respect to the goals you wish to achieve within your domain.
When the focus of WS-CDL is across domains of control, WS-CDL is used to describe the ordering of observable message exchanges across domains such as the those that govern vertical protocols such as fpML, FIX, TWIST and SWIFT. These protocols have some form of XML data format definition and then proceed to describe the ordering of message exchanges using a combination of prose and UML sequence diagrams. WS-CDL provides an unambiguous way of describing the ordering of message exchanges and in so doing ensure that the services that participate in the observable collaborations based on such vertical standards conform to the choreography description. You can think of it as a way to ensure that services are well-behaved with respect to their common goals across domains.
2.2 Why use WS-CDL?
WS-CDL can be used to ensure interoperability within and across domains of control to lower interoperability issues, such as downtime, and create solutions within and across domains of control.
WS-CDL can be used to ensure that the total cost of software systems in a distributed environment, within a domain of control and across the world-wide-web is lowered by guaranteeing that the services that participate in a choreography are well behaved on a continuous basis.
Both of these benefits translate into greater up-time and so increase top line profits. At the same time they translate into less testing time and so reduce cost of delivery which decreases bottom line costs.
2.3 The Structure of WS-CDL
WS-CDL is a layered language that provides different levels of expressability to describe a choreography. These levels are illustrated below in Figure 1.
At the top most level for any WS-CDL there is a package that contains all other things. All choreographies described in WS-CDL will include as a minimum a set of Roles that are defined as some sort of behavior (i.e. a WSDL description) and so represent our WS-CDL notion of a service, Relationships between those roles, Channels used by roles to interact and a Choreography block that uses channels to describe Interaction. What the choreography describes at this level is a basic set of typed and unambiguous service connections that enable the various roles to collaborate in order to achieve some common goal.
Adding further ordering rules through Structured composition allows Interactions and Choreographies (which are just logical groupings of interactions) to be combined into sequences, parallel activities and so on.
Adding Non-Observable Conditionals makes it is possible to model branching based on observing changes in the interactions that occur (e.g. one might observe an exchange between a buyer and a seller which is said to be terminated when a “completed” interaction is observed).
If we have no observable conditionals then it is not necessary to perform any explicit state management at the roles that are interacting because we have not needed to express any explicit computation (e.g. totalOrderValue EQUALS expectedOrderValue) required of an observable condition. None of roles used in choreographies of this type have the need for any state variables to control a choreography, rather the progression of a choreography is expressed purely in terms of observable interactions and use observation to determine their state with respect to the other roles.
Some business protocols are defined exposing specific business rules. These constitute shared knowledge between the concerned roles. For example we may terminate an order completion between a buyer and a seller when we calculate that the items delivered match the original order. The business rule in this example is the shared constraint that buyer_quantity equals completion_quantity. At some level the roles must have some shared knowledge of both variables and their values. When business rules of this nature become part of the business protocol such Observable Conditionals can be added into a choreography and which implies state management is needed.
WS-CDL provides some basic interfaces for state management defining it’s requirements as a coordination protocol. The specifics of state management is left as an implementation detail for the community.
3 Getting Started
In order to understand WS-CDL is best to illustrate it through the use of an example. In this section we shall introduce an example and use it throughout the rest of document to illustrate different parts of WS-CDL. The Appendicies have the full listing of the various WS-CDL encodings of the example as well as a url to the WS-CDL descriptions. In all cases the WS-CDL descriptions have been tested against at least one implementation of WS-CDL having been constructed in a validating editor.
3.1 The Example
The example that we use concerns the collaborative behavior of a buyer, a seller, a credit check agency and a shipper. The buyer interacts with the seller to determine a price. When a price is acceptable to the buyer the buyer interacts with the seller to order the relevant goods based on this price whereupon the seller checks their credit worthiness by interacting with a credit agent and if this is acceptable requests a delivery date by interacting with the shipper. In our example the shipper interacts directly with the buyer once an agreed delivery date has been achieved and informs the buyer of the delivery details.
The example is further illustrated by means of a number of sequence diagrams below:
The Normal Collaboration, illustrated in Figure 2, shows the buyer requesting a quote and the seller responding with a quote. The buyer then accepts the quote, which is akin to placing the order. As a result the seller checks the buyers credit rating. As the buyers credit rating is ok the seller then confirms the order with the buyer and requests from the shipper delivery details which are passed back to the seller by the shipper. The shipper will have picked up all that is necessary from the seller, who received it from the buyer as part of the order placement, all of the details necessary to communicate directly with the buyer so that delivery details can be passed back from the shipper to the buyer.
The Quote Timeout Collaboration, illustrated in Figure 3, illustrated the buyer requesting a quote, the seller sending back a quote response that has a timeout associated with the quote. If the buyer fails to act on the quote in time (before the timeout elapses) the buyer may not honor the quote. In the scenario presented we show the opportunity for the buyer to accept the quote just as the seller decides that the quote has timed-out. This demonstrates a classic race condition between the parties.
Figure 4 shows a credit check rejection for the buyer. After the buyer requests the quote, the seller responds, the buyer accepts the it, the seller then checks the credit rating for the buyer. In this case the credit check agency determines that the credit rating is low and returns a credit rejection to the seller who in turn returns a credit rejection to the buyer, terminating the collaboration.
The final scenario to introduce is that of the bartering collaboration. This is illustrated in Figure 5 below.
In this collaboration the buyer requests a quote from the seller who responds with a quote. Thereafter the buyer may request an updated quote, filling in a desired price and quantity, from the seller. The seller may respond by accepting the quote, returning a quote response message to the seller. If the seller does not respond then the buyers update is subject to a timeout in the same way that the sellers quote is valid for a specified duration. In receipt of a quote response from the seller the buyer may accept the quote (and by so doing enter into the act of buying with the seller) or may request a further updated quote or simply do nothing at all –allowing the quote to timeout.
We have used a heavily annotated form of sequence diagram to describe the business collaboration protocol necessary for the buyer, seller, credit agency and shipper to go about their business. WS-CDL is very much designed to enable the entire business collaboration protocol to be described in an unambiguous manner. We hope that this becomes self evident to the reader as we walk through constructing the WS-CDL description for this example.
3.2 Degenerate Example
Having laid out a reasonably full example in the previous section we shall restrict it to what we call a degenerate example. This degenerate example has enough it in to create a choreography description to represent it but otherwise it is not interesting, at least from a business perspective.
The degenerate example involves just the buyer and the seller from the previous example. The buyer simply requests a price from the seller and the seller responds with a price or a fault if the goods are not known or not available. This is illustrated in the sequence diagram in Figure 6 below.
3.3 Interaction Oriented Design
In this section we introduce the fundamental concept of an interaction, which underpins WS-CDL. We shall use our degenerate example that we have described above and go through the necessary steps to define it as a choreography description in WS_CDL. We shall define the roles, tokens, channels, relationships, participants and variables necessary to properly describe it.
3.3.1 Interactions
An interaction is the realization of a collaboration between roles or participants. The difference between roles and participants will be detailed later on for now we can consider them as synonymous.
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 for which the quote is for. 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:
<interaction name="QuoteElicitation" operation="getQuote" channelVariable="tns:Buyer2SellerC">
<description type="documentation">
Quote Elicitation
</description>
<participate relationshipType="tns:Buyer2Seller" fromRoleTypeRef="tns:BuyerRole" toRoleTypeRef="tns:SellerRole"/>
<exchange name="QuoteRequest" informationType="tns:QuoteRequestType" action="request">
<description type="documentation">
Quote Request Message Exchange
</description>
<send variable="cdl:getVariable('quoteRequest','','')"/>
<receive variable="cdl:getVariable('quoteRequest','','')"/>
</exchange>
<exchange name="QuoteResponse" informationType="tns:QuoteResponseType" action="respond">
<description type="documentation">
Quote Response Message Exchange
</description>
<send variable="cdl:getVariable('quoteResponse','','')"/>
<receive variable="cdl:getVariable('quoteResponse','','')"/>
</exchange>
<exchange name="QuoteResponseFault" informationType="tns:QuoteResponseFaultType" action="respond" faultName="InvalidProductFault">
<description type="documentation">
Quote Response Fault Exchange
</description>
<send variable="cdl:getVariable('faultResponse','','')" causeException="InvalidProduct"/>
<receive variable="cdl:getVariable('faultResponse','','')" causeException="InvalidProduct"/>
</exchange>
</interaction>
Interactions are descriptions of one or more exchanges between a sender and a receiver. Interactions are labeled with an operation name that could 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 on a channel, as indicated by a channelVariable, the variable itself will have been declared to be of a particular channelType. The participating relationship restricts the interaction to be between roles that are valid for that relationship.
Each exchange names 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 shall 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:
- Define our roleTypes,
- Define our relationshipTypes,
- Define our informationTypes,
- Define our tokenType,
- Define our channelTypes
3.3.2 Roles
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:
<roleType name="BuyerRole">
<description type="documentation">
Role for Buyer
</description>
<behavior name="BuyerBehavior" interface="BuyerBehaviorInterface">
<description type="documentation">
Behavior for Buyer Role
</description>
</behavior>
</roleType>
<roleType name="SellerRole">
<description type="documentation">
Role for Seller
</description>
<behavior name="SellerBehavior" interface="SellerBehaviorInterface">
<description type="documentation">
Behavior for Seller
</description>
</behavior>
</roleType>
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:
3.3.3 Participants
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 beit a organisation or line of business within an organisation.
"Partipants" 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 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:
<participantType name="Seller">
<description type="documentation">
Seller Participant
</description>
<roleType typeRef="tns:SellerRole"/>
</participantType>
<participantType name="Buyer">
<description type="documentation">
Buyer Participant
</description>
<roleType typeRef="tns:BuyerRole"/>
</participantType>
3.3.4 Relationships
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:
<relationshipType name="Buyer2Seller">
<description type="documentation">
Buyer Seller Relationship
</description>
<roleType typeRef="tns:BuyerRole"/>
<roleType typeRef="tns:SellerRole"/>
</relationshipType>
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, though WS-CDL does not
require this directionality to be declared in the name of a relationship.
The abstract syntax for relationships is defined as follows:
3.3.5 Information Types
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:
<informationType name="QuoteRequestType" type="primer:QuoteRequestMsg">
<description type="documentation">
Quote Request Message
</description>
</informationType>
<informationType name="QuoteResponseType" type="primer:QuoteResponseMsg">
<description type="documentation">
Quote Response Message
</description>
</informationType>
<informationType name="QuoteResponseFaultType" type="primer:QuoteResponseFaultMsg">
<description type="documentation">
Quote Response Fault Message
</description>
</informationType>
<informationType name="IdentityType" type="xsd:string">
<description type="documentation">
Identity Attribute
</description>
</informationType>
<informationType name="URI" type="xsd:uri">
<description type="documentation">
Reference Token For Channels
</description>
</informationType>
The abstract syntax for defining information types is as follows:
3.3.6 Tokens and locators
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. We define some tokens and token locators here because they are needed when defining channel types. The tokens and their locators are used later on to define the identity attributes that ensure channel communication can be correlated.
The tokens we define will also be used to refer to a service reference, that is a url, t 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.
The additonal information types that we defined earlier are needed because they are references in the token definitions and the locator definitions. And this is why we needed to define them when we did.
We define the tokens id which represents the information type IdentityType and
URI, which represents the information type URI. We define the
locators for the different message types that are exchanged, namely QuoteRequestType,
QuoteResponseType and QuoteResponseFaultType
as id, id and id respectively. These locoators will be used to
represent the identity attributes on channel communication for the different messages. The full
description of the tokens and the locators is given below:
<token name="id" informationType="tns:IdentityType">
<description type="documentation">
Identity token
</description>
</token>
<token name="URI" informationType="tns:URI">
<description type="documentation">
Reference Token for Channels
</description>
</token>
<tokenLocator tokenName="tns:id" informationType="tns:QuoteRequestType" query="/quote/@id">
<description type="documentation">
Identity for Quote Request
</description>
</tokenLocator>
<tokenLocator tokenName="tns:id" informationType="tns:QuoteResponseType" query="/quote/@key">
<description type="documentation">
Identity for Quote Response
</description>
</tokenLocator>
<tokenLocator tokenName="tns:id" informationType="tns:QuoteResponseFaultType" query="/quote/@key">
<description type="documentation">
Identity for Quote Response Fault
</description>
</tokenLocator>
The abstract syntax for defining a token is as follows:
3.3.7 Channels
Finally, having defined our roles, information types, tokens and locatorswe are in a position to define our channel. Channels are the principle mechanism used to realize an interaction.
In our interaction that we presented earlier we have a channel variables called
Buyer2SellerC. This channel variable has a type and it is that type that we shall
now define.
To define a channel we need to name it, we need to, optionally, describe it, we need to tell it which role realises it's behavioral interface (the role we send things to and receive things from). We need to provide a reference to a service and we need to imbue our channel type with some notion of how to derive it's identity when in use.
The channel type we shall define is called Buyer2SellerChannel and it is defined
as follows:
<channelType name="Buyer2SellerChannel">
<description type="documentation">
Buyer to Seller Channel Type
</description>
<roleType typeRef="tns:SellerRole"/>
<reference>
<token name="tns:URI"/>
</reference>
<identity type="primary">
<token name="tns:id"/>
</identity>
</channelType>
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:
<channelType name="ncname"
usage="once"|"unlimited"?
action="request-respond"|"request"|"respond"? >
<passing channel="qname"
action="request-respond"|"request"|"respond"?
new="true"|"false"? />*
<role type="qname" behavior="ncname"? />
<reference>
<token name="qname"/>
</reference>
<identity>
<token name="qname"/>+
</identity>?
</channelType>
3.3.8 Choreographies
We can now consider describing the choreography itself. We shall do this by taking the normal collaboration and building a choreography based on the first interaction within that collaboration.
Before we can really start describing the interactions between the roles we need to define some basic variables that we shall use. We have already seen that we need to have a channel variable in an interaction. We shall also need some way of controlling the iteration for the bartering part of our choreography.
What we shall need to do is define instances for the "Buyer2SellerChannelType","Seller2ShipperChannelType", "Seller2ShipperChannelType" and "2BuyerChannelType" that we shall name "Buyer2SellerC", "Seller2ShipperC", "Seller2ShipperC" and "DeliveryDetailsC" respectively. We shall also define a variable called "barteringDone" that will be of type "BooleanType" that will be used to control the bartering iteration.
<choreography name="DegenerateChoreography" root="true">
<description type="documentation">
The Choreography for the degenerate use case
</description>
<relationship type="tns:Buyer2Seller"/>
<variableDefinitions>
<variable name="Buyer2SellerC"
channelType="tns:Buyer2SellerChannel"
roleTypes="tns:BuyerRole tns:SellerRole">
<description type="documentation">
Channel Variable
</description>
</variable>
<variable name="quoteRequest"
informationType="tns:QuoteRequestType"
roleTypes="tns:BuyerRole tns:SellerRole">
<description type="documentation">
Request Message
</description>
</variable>
<variable name="quoteResponse"
informationType="tns:QuoteResponseType"
roleTypes="tns:BuyerRole tns:SellerRole">
<description type="documentation">
Response Message
</description>
</variable>
<variable name="faultResponse"
informationType="tns:QuoteResponseFaultType"
roleTypes="tns:BuyerRole tns:SellerRole">
<description type="documentation">
Fault Message
</description>
</variable>
</variableDefinitions>
We also need to declare the relationships for which we shall describe behavior in the form of interactions that will be the basis of this choreography. In our case this is the "BuyerSeller", "SellerCreditCheck", "SellerCreditCheck"and "ShipperBuyer". Relationships are declared to act as a cross-check against the channel usage within the choreography. This allows implementations of CDL editors to cross-check the relationships that can be inferred from the channels used against that that is explicitly declared.
This first part of the actual choreography is
illustratedabove. We have named our choreography name="Main", we have marked the
choreography as the root, root="true" so that we know that this initiates the
whole thing and we have declared our relationship types and defined our
variables in the variableDefinitions section.
Taking just one of the variables defined, "DeliveryDetailsC"
,we can see that variables have a variable name and a type which may be a
channelType or an informationType. Variables also have a roleTypes that
determines where the variable resides. We can have as many roleTypes as we like
so that the same named variable resides at all of the roles. What this means is
that each role has a variable of the same name. It does not mean that the
variable is the same. In our case the list of roleTypes is "BuyerRoleType
SellerRoleType ShipperRoleType". We have seen these variables in the different
roles in the interaction described above. To make the variable have the same
information we ensure that we align them in some way which can only be done
through some interaction and exchange. This is exactly what is done in the
interaction already described.
<choreography name="ncname"
complete="xsd:boolean XPath-expression"?
isolation="true"|"false"?
root="true"|"false"?
coordination="true"|"false"? >
<relationship type="qname" />+
variableDefinitions?
Choreography-Notation*
Activity-Notation
<exceptionBlock name="ncname">
WorkUnit-Notation+
</exceptionBlock>?
<finalizerBlock name="ncname">
WorkUnit-Notation
</finalizerBlock>*
</choreography>
<variableDefinitions>
<variable name="ncname"
informationType="qname"?|channelType="qname"?
mutable="true|false"?
free="true|false"?
silent="true|false"?
roleTypes="list of qname"? />+
</variableDefinitions>
3.3.9 Sequences
We start off by defining a sequence. The sequence encapsulates the overall choreography that we are modeling and in it we shall place our first interaction. The first interaction starts the choreography and it is the one between the buyer and the seller in which the buyer requests a quote and the seller responds with a quote. Clearly we can model this as a single interaction with a request/response exchange. The buyer initiates the exchange of information that defines the request and the seller responds with an exchange that defines the response. The interaction is part of a sequence illsuratedbelow.
The first element of this sequence is the interaction that
has the name "Buyer requests a Quote - this is the initiator" and the
operation "requestForQuote". The "requestForQuote" operation is something
implemented by the seller as part of its service description (i.e. WSDL). It
will use the channel that we have defined called "Buyer2SellerC" and it has
initiate set to "true". This means that the channel will use "Buyer2SellerC" to
realize the first interaction in the choreography.
The interaction declares the relationship type that is
participating in the interaction and in the exchanges the roles involved. These
act as cross-check to ensure that the channel is the correct channel for the
named roles and that the roles have a pre-declared relationship. In this case
the participate relationshipType is "BuyerSeller" and the roles are
"BuyerRoleType" and "SellerRoleType" respectively.
<?xml version="1.0" encoding="UTF-8"?>
<package
name="DegenerateExample"
author="Stephen Ross-Talbot"
version="1.0"
targetNamespace="http://www.w3.org/2002/ws/chor/primer"
xmlns:tns="http://www.w3.org/2002/ws/chor/primer"
xmlns="http://www.w3.org/2005/10/cdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:primer="http://www.w3.org/2002/ws/chor/primer">
<description type="documentation">
Degenerate Example for Primer
</description>
…
<choreography name="DegenerateChoreography" root="true">
<description type="documentation">
The Choreography for the degenerate use case
</description>
…
<sequence>
<interaction name="QuoteElicitation" operation="getQuote" channelVariable="tns:Buyer2SellerC">
<description type="documentation">
Quote Elicitation
</description>
<participate relationshipType="tns:Buyer2Seller" fromRoleTypeRef="tns:BuyerRole" toRoleTypeRef="tns:SellerRole"/>
<exchange name="QuoteRequest" informationType="tns:QuoteRequestType" action="request">
<description type="documentation">
Quote Request Message Exchange
</description>
<send variable="cdl:getVariable('quoteRequest','','')"/>
<receive variable="cdl:getVariable('quoteRequest','','')"/>
</exchange>
<exchange name="QuoteResponse" informationType="tns:QuoteResponseType" action="respond">
<description type="documentation">
Quote Response Message Exchange
</description>
<send variable="cdl:getVariable('quoteResponse','','')"/>
<receive variable="cdl:getVariable('quoteResponse','','')"/>
</exchange>
<exchange name="QuoteResponseFault" informationType="tns:QuoteResponseFaultType" action="respond" faultName="InvalidProductFault">
<description type="documentation">
Quote Response Fault Exchange
</description>
<send variable="cdl:getVariable('faultResponse','','')" causeException="InvalidProduct"/>
<receive variable="cdl:getVariable('faultResponse','','')" causeException="InvalidProduct"/>
</exchange>
</interaction>
</sequence>
</choreography>
</package>
Finally we have the exchanges that make up this interaction. Interactions can have one or more exchanges. This one only requires two because it is a request/response pattern. Thus the first exchange that we have named as "request" described an exchange from the buyer to the seller in which a "RequestForQuoteType" message is exchanged as a "request". The second named "response" exchanges is the other direction from seller to buyer and uses a "QuoteType" message that is marked as a "respond".
NOTE: Add text to explain interaction lifecycle, and that exchanges are only guaranteed if align=true, or else modelled to catch specific exceptions
3.3.10 Complete Example
Having described all of the necessary types and having described the salient aspects of the Choreography we present the complete example.
<?xml version="1.0" encoding="UTF-8"?>
<package
name="DegenerateExample"
author="Stephen Ross-Talbot"
version="1.0"
targetNamespace="http://www.w3.org/2002/ws/chor/primer"
xmlns:tns="http://www.w3.org/2002/ws/chor/primer"
xmlns="http://www.w3.org/2005/10/cdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:primer="http://www.w3.org/2002/ws/chor/primer">
<description type="documentation">
Degenerate Example for Primer
</description>
<informationType name="QuoteRequestType" type="primer:QuoteRequestMsg">
<description type="documentation">
Quote Request Message
</description>
</informationType>
<informationType name="QuoteResponseType" type="primer:QuoteResponseMsg">
<description type="documentation">
Quote Response Message
</description>
</informationType>
<informationType name="QuoteResponseFaultType" type="primer:QuoteResponseFaultMsg">
<description type="documentation">
Quote Response Fault Message
</description>
</informationType>
<informationType name="IdentityType" type="xsd:string">
<description type="documentation">
Identity Attribute
</description>
</informationType>
<informationType name="URI" type="xsd:uri">
<description type="documentation">
Reference Token For Channels
</description>
</informationType>
<token name="id" informationType="tns:IdentityType">
<description type="documentation">
Identity token
</description>
</token>
<token name="URI" informationType="tns:URI">
<description type="documentation">
Reference Token for Channels
</description>
</token>
<tokenLocator tokenName="tns:id" informationType="tns:QuoteRequestType" query="/quote/@id">
<description type="documentation">
Identity for Quote Request
</description>
</tokenLocator>
<tokenLocator tokenName="tns:id" informationType="tns:QuoteResponseType" query="/quote/@key">
<description type="documentation">
Identity for Quote Response
</description>
</tokenLocator>
<tokenLocator tokenName="tns:id" informationType="tns:QuoteResponseFaultType" query="/quote/@key">
<description type="documentation">
Identity for Quote Response Fault
</description>
</tokenLocator>
<roleType name="BuyerRole">
<description type="documentation">
Role for Buyer
</description>
<behavior name="BuyerBehavior" interface="BuyerBehaviorInterface">
<description type="documentation">
Behavior for Buyer Role
</description>
</behavior>
</roleType>
<roleType name="SellerRole">
<description type="documentation">
Role for Seller
</description>
<behavior name="SellerBehavior" interface="SellerBehaviorInterface">
<description type="documentation">
Behavior for Seller
</description>
</behavior>
</roleType>
<relationshipType name="Buyer2Seller">
<description type="documentation">
Buyer Seller Relationship
</description>
<roleType typeRef="tns:BuyerRole"/>
<roleType typeRef="tns:SellerRole"/>
</relationshipType>
<participantType name="Seller">
<description type="documentation">
Seller Participant
</description>
<roleType typeRef="tns:SellerRole"/>
</participantType>
<participantType name="Buyer">
<description type="documentation">
Buyer Participant
</description>
<roleType typeRef="tns:BuyerRole"/>
</participantType>
<channelType name="Buyer2SellerChannel">
<description type="documentation">
Buyer to Seller Channel Type
</description>
<roleType typeRef="tns:SellerRole"/>
<reference>
<token name="tns:URI"/>
</reference>
<identity type="primary">
<token name="tns:id"/>
</identity>
</channelType>
<choreography name="DegenerateChoreography" root="true">
<description type="documentation">
The Choreography for the degenerate use case
</description><relationship type="tns:Buyer2Seller"/>
<variableDefinitions>
<variable name="Buyer2SellerC"
channelType="tns:Buyer2SellerChannel"
roleTypes="tns:BuyerRole tns:SellerRole">
<description type="documentation">
Channel Variable
</description>
</variable>
<variable name="quoteRequest"
informationType="tns:QuoteRequestType"
roleTypes="tns:BuyerRole tns:SellerRole">
<description type="documentation">
Request Message
</description>
</variable>
<variable name="quoteResponse"
informationType="tns:QuoteResponseType"
roleTypes="tns:BuyerRole tns:SellerRole">
<description type="documentation">
Response Message
</description>
</variable>
<variable name="faultResponse"
informationType="tns:QuoteResponseFaultType"
roleTypes="tns:BuyerRole tns:SellerRole">
<description type="documentation">
Fault Message
</description>
</variable>
</variableDefinitions>
<sequence>
<interaction name="QuoteElicitation" operation="getQuote" channelVariable="tns:Buyer2SellerC">
<description type="documentation">
Quote Elicitation
</description>
<participate relationshipType="tns:Buyer2Seller" fromRoleTypeRef="tns:BuyerRole" toRoleTypeRef="tns:SellerRole"/>
<exchange name="QuoteRequest" informationType="tns:QuoteRequestType" action="request">
<description type="documentation">
Quote Request Message Exchange
</description>
<send variable="cdl:getVariable('quoteRequest','','')"/>
<receive variable="cdl:getVariable('quoteRequest','','')"/>
</exchange>
<exchange name="QuoteResponse" informationType="tns:QuoteResponseType" action="respond">
<description type="documentation">
Quote Response Message Exchange
</description>
<send variable="cdl:getVariable('quoteResponse','','')"/>
<receive variable="cdl:getVariable('quoteResponse','','')"/>
</exchange>
<exchange name="QuoteResponseFault" informationType="tns:QuoteResponseFaultType" action="respond" faultName="InvalidProductFault">
<description type="documentation">
Quote Response Fault Exchange
</description>
<send variable="cdl:getVariable('faultResponse','','')" causeException="InvalidProduct"/>
<receive variable="cdl:getVariable('faultResponse','','')" causeException="InvalidProduct"/>
</exchange>
</interaction>
</sequence>
</choreography>
</package>
4 Intemediate Topics
In the previous choreography example all we described was some simple interactions in a sequence. We had no conditionality, no repetition and no variables and no structuring other than sequentiality. In this section we examine WS-CDL more closely to better understand how to exert finer grain control over the interactions that are the core to a choreography description.
In this section we examine what we call intermediate topics. The intermediate topics will provide the reader with further structuring of a choreography and enable the reader to describe repetitive, parallel and conditional behavior and as such be able to declare and use variables in so doing. The reader will also be able to describe exception conditions and understand how these relate to faults in WSDL. The reader will be able to decompose a choraeography into sub choreographies that make it easier to reuse the described behavior and easier to understand a choreography as a set of related sub choreographies.
4.1 Variables
Apart from defining channel variables, the previous complete example had no other variables. Variables can be used in a choreography description to extert finer grain control. They might be used in predicates that determine what to do next. They might be used as messages in exchanges and so might need to be copied from one variable to another.
In WS-CDl variables are always situated. That is they are defined at one or more roles. When variables are manipulated in some way, copied for example, they are also situated. Variables are not shared explicitly. Rather they exist in 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. But they very much variables in their own right and at their own roles. The fact that they have they may have the same name has no bearing on the semantics of a variable.
4.2 Workunits
In this section we look at workunits. Workunits play several roles in structuring a choreography. A workunit provides repetition based on some predicate and a workunit provides a way of adding conditionality. Workunits in general have a body that includes the other choreography constructs. These constructs are only performed is the workunits attributes enable them to be performed. In the case of a conditional the condition is evaluated and if true the body is performed. In the case of repetition the conditional part is set to true, the body is performed and if the repetition condition evaluates to true it is performed again and again until the repeitition condition evaluates to false.
The general structure of a workunit is as follows:
Workunit (G) (R) (B is False)
Body
Where G and R are of type xsd:boolean Xpath expressions and
B is an xsd:boolean constrainted to be "true" or "false"
A typical order of evaluation is as follows:
(G) Body (R G) Body (R G) Body
Which equates to (in pseudo code):
while (G) {
Body
} until (!R)
IF G is always True THEN it equates to:
repeat {
Body
} until (!R)
IF R is always False THEN it equates to:
if (G) {
Body
}
4.2.1 Repetition
Once we initiate this first interaction we need to use some form of repetition to describe the collaboration pattern for the bartering-process. In this process the buyer may request an update to a quote, perhaps putting in a target price, and the seller may either accept or reject the updated quote from the buyer. The buyer may decide that the initial quote is acceptable and take action accordingly or the quote itself may timeout because in our example the price/quote is valid only for a specified period.
We need to model repetition to control the bartering process itself and we need some form of choice in which the choices made are the buyer deciding to update quote, the buyer deciding to accept the quote or the quote timing-out. Such a workunit is illustrated below. For now ignore the choice construct as we shall deal with it and it’s elements in the next section.
<workunit name="Repeat until bartering has been completed" repeat="barteringDone = false">
<choice>
<silentAction roleType="BuyerRoleType">
<description type="description">Do nothing - let the quote timeout</description>
</silentAction>
<sequence>
<interaction name="Buyer accepts the quote and engages in the act of buying"
operation="quoteAccept" channelVariable="Buyer2SellerC">
<description type="description">Quote Accept</description>
<participate relationshipType="BuyerSeller"
fromRole="BuyerRoleType" toRole="SellerRoleType" />
<exchange name="Accept Quote" informationType="QuoteAcceptType"
action="request">
</exchange>
</interaction>
<interaction name="Buyer send channel to seller to enable callback behavior"
operation="sendChannel" channelVariable="Buyer2SellerC">
<description type="description">Buyer sends channel to pass to shipper</description>
<participate relationshipType="BuyerSeller"
fromRole="BuyerRoleType" toRole="SellerRoleType" />
<exchange name="sendChannel" channelType="2BuyerChannelType" action="request">
<send variable="cdl:getVariable('DeliveryDetailsC','','')" />
<receive variable="cdl:getVariable('DeliveryDetailsC','','')" />
</exchange>
</interaction>
<assign roleType="BuyerRoleType">
<copy name="copy">
<source expression="true" />
<target variable="cdl:getVariable('barteringDone','','')" />
</copy>
</assign>
</sequence>
<sequence>
<interaction name="Buyer updates the Quote - in effect requesting a new price"
operation="quoteUpdate" channelVariable="Buyer2SellerC">
<description type="documentation">Quot Update</description>
<participate relationshipType="BuyerSeller"
fromRole="BuyerRoleType" toRole="SellerRoleType" />
<exchange name="updateQuote"
informationType="QuoteUpdateType" action="request">
</exchange>
<exchange name="acceptUpdatedQuote"
informationType="QuoteAcceptType" action="respond">
<description type="documentation">Accept Updated Quote</description>
</exchange>
</interaction>
</sequence>
</choice>
</workunit>
In this workunit, that we have named "Repeat until bartering has been completed", we have a repetition condition "barteringDone = false". This condition evaluates the declared variable "barteringDone" to see if it is false. If false the workunit proceeds and repeats until such time as the condition ("barteringDone = false") evaluates to true.
4.2.2 Conditional
There if often a need to have one or more activities grouped together based on some predicate for conditional processing. In WS-CDL we do this by using a non blocking workunit in which the guard condition acts as the predicate. Thus conditionals are expressed in the following way:
Example that does an interaction with a record to check if a buyer is valid
Depending on the value of the recorded information a workunit then performs
the credit checking.
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 domethink akin to:
buyerIsValid = perform buyerValidtion
If (buyerIsValid)
perform credit checking
4.3 Exceptions and Faults
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 cause exception to interrupt the flow of the choreo. The Exception handler returns a message to the buyer to let them know that the order has been cancelled
4.4 Finalization
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 finanlizers 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).
4.5 Silent Actions and Conditions
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.
4.7 Time
Buyer side does a timeout on the RequestForQuote (e.g. 30 mins). if they hit the timeout they give up. Note: hasDurationPassed belongs in 5. Advanced with 5.1 Concurrent Performs
4.9 Choices
The body of the above workunit is 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:
<workunit name="Repeat until bartering has been completed" repeat="barteringDone = false">
<choice>
<silentAction roleType="BuyerRoleType">
<description type="description">Do nothing - let the quote timeout</description>
</silentAction>
<sequence>
…
</sequence>
<sequence>
…
</sequence>
</choice>
</workunit>
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:
<workunit name="Repeat until bartering has been completed" repeat="barteringDone = false">
<choice>
<silentAction roleType="BuyerRoleType">
<description type="description">Do nothing - let the quote timeout</description>
</silentAction>
<sequence>
…
</sequence>
<sequence>
<interaction name="Buyer updates the Quote - in effect requesting a new price"
operation="quoteUpdate" channelVariable="Buyer2SellerC">
<description type="documentation">Quot Update</description>
<participate relationshipType="BuyerSeller"
fromRole="BuyerRoleType" toRole="SellerRoleType" />
<exchange name="updateQuote"
informationType="QuoteUpdateType" action="request">
</exchange>
<exchange name="acceptUpdatedQuote"
informationType="QuoteAcceptType" action="respond">
<description type="documentation">Accept Updated Quote</description>
</exchange>
</interaction>
</sequence>
</choice>
</workunit>
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:
<workunit name="Repeat until bartering has been completed" repeat="barteringDone = false">
<choice>
<silentAction roleType="BuyerRoleType">
<description type="description">Do nothing - let the quote timeout</description>
</silentAction>
<sequence>
<interaction name="Buyer accepts the quote and engages in the act of buying"
operation="quoteAccept" channelVariable="Buyer2SellerC">
<description type="description">Quote Accept</description>
<participate relationshipType="BuyerSeller"
fromRole="BuyerRoleType" toRole="SellerRoleType" />
<exchange name="Accept Quote" informationType="QuoteAcceptType"
action="request">
</exchange>
</interaction>
<interaction name="Buyer send channel to seller to enable callback behavior"
operation="sendChannel" channelVariable="Buyer2SellerC">
<description type="description">Buyer sends channel to pass to shipper</description>
<participate relationshipType="BuyerSeller"
fromRole="BuyerRoleType" toRole="SellerRoleType" />
<exchange name="sendChannel" channelType="2BuyerChannelType" action="request">
<send variable="cdl:getVariable('DeliveryDetailsC','','')" />
<receive variable="cdl:getVariable('DeliveryDetailsC','','')" />
</exchange>
</interaction>
<assign roleType="BuyerRoleType">
<copy name="copy">
<source expression="true" />
<target variable="cdl:getVariable('barteringDone','','')" />
</copy>
</assign>
</sequence>
<sequence>
…
</sequence>
</choice>
</workunit>
4.14 Recording information
QuoteAcceptance can have a record to take out the PO on the QuoteAcceptance from the buyer to record the PO at the Seller and then reuse it for the OrderConfirmation.
4.15 Complete Example
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.
<interaction name="Seller check credit with CreditChecker"
operation="creditCheck" channelVariable="Seller2CreditChkC">
…
</interaction>
<choice>
<interaction name="Credit Checker fails credit check"
operation="creditFailed" channelVariable="Seller2CreditChkC">
…
</interaction>
<sequence>
<interaction name="Credit Checker passes credit"
operation="creditOk" channelVariable="Seller2CreditChkC">
…?
</interaction>
<interaction name="Seller requests delivery details"
operation="requestShipping" channelVariable="Seller2ShipperC">
…
</interaction>
<interaction name="Shipper forward channel to shipper"
operation="sendChannel" channelVariable="Seller2ShipperC">
<description type="description">Pass channel from buyer to shipper</description>
<participate relationshipType="SellerShipper"
fromRole="SellerRoleType" toRole="ShipperRoleType" />
<exchange name="forwardChannel" channelType="2BuyerChannelType" action="request">
<send variable="cdl:getVariable('DeliveryDetailsC','','')" />
<receive variable="cdl:getVariable('DeliveryDetailsC','','')" />
</exchange>
</interaction>
<interaction name="Shipper sends delivery details to buyer"
operation="deliveryDetails" channelVariable="DeliveryDetailsC">
<description type="description">Pass back shipping details to the buyer</description>
<participate relationshipType="ShipperBuyer"
fromRole="ShipperRoleType" toRole="BuyerRoleType" />
<exchange name="sendDeliveryDetails"
informationType="DeliveryDetailsType" action="request">
</exchange>
</interaction>
</sequence>
</choice>
</sequence>
</choreography>
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.
5 Advanced Topics
5.1 Dependent Workunits
We can change our example and make it somewhat more interesting by having two workunits. The first is unchanged and the second incorporates all of the previous choreography notation that follows the completion of the first workunit. What we shall do to model this is to make the second workunit dependent on the availability and value of 'barteringDone'. To do this we shall introduce a guard condition into our workunit and make a blocking workunit. Such dependent workunits represent a structural dependence that might exist in real systems and so provides the choreography designer with an elegant way of expressing the dependencies directly as opposed to adding further conditional and state to achieve much the same thing.
Our workunit sketch looks like the following:
<parallel> <workunit name="Repeat until bartering has been completed" repeat="barteringDone = false"> … </workunit> <workunit name="Process Order" guard="barteringDone = true" blocking="true"> … </workunit> </parallel>
In this example the guard condition is "barteringDone =
true" and the blocking is set to "true". This second workunit waits until
"barteringDone" is available and is set to true before enacting whatever is
described inside of it. We place the two workunits inside a parallel construct
which means that the two workunits operate concurrently. The second being
dependent on the first waits until its preconditions are met before
proceeding.
<parallel> <workunit name="Repeat until bartering has been completed" repeat="barteringDone = false"> … </workunit> <workunit name="Process Order" guard="barteringDone = true" blocking="true"> … </workunit> </parallel>
We can use the same data-driven collaboration technique to rewrite how we handle the credit checking response, by introducing another variable, 'creditRatingOk', at the seller role, that records, as a Boolean, the response from the credit check. The second, blocking, workunit is made dependent on the outcome of the first by using a guard that looks a little like the following:
<parallel>
<workunit name="Check Credit Rating">
<sequence>
<interaction name="Seller check credit with CreditChecker"
operation="creditCheck" channelVariable="Seller2CreditChkC">
<description type="description">
Check the credit for this buyer with the credit check agency
</description>
<participate relationshipType="SellerCreditCheck"
fromRole="SellerRoleType" toRole="CreditCheckerRoleType" />
<exchange name="checkCredit" informationType="CreditCheckType" action="request">
</exchange>
</interaction>
<choice>
<sequence>
<interaction name="Credit Checker fails credit check"
operation="creditFailed" channelVariable="Seller2CreditChkC">
<description type="description">
Credit response from the credit checking agency
</description>
<participate relationshipType="SellerCreditCheck"
fromRole="SellerRoleType" toRole="CreditCheckerRoleType" />
<exchange name="creditCheckFails"
informationType="CreditRejectType" action="respond">
</exchange>
</interaction>
<assign roleType="SellerRoleType">
<copy name="copy">
<source expression="false" />
<target variable="cdl:getVariable('creditRatingOk','','')" />
</copy>
</assign>
</sequence>
<sequence>
<interaction name="Credit Checker passes credit"
operation="creditOk" channelVariable="Seller2CreditChkC">
<description type="description">
Credit response from the credit checking agency
</description>
<participate relationshipType="SellerCreditCheck" fromRole="BuyerRoleType"
toRole="CreditCheckerRoleType" />
<exchange name="creditCheckPasses"
informationType="CreditAcceptType" action="respond">
</exchange>
</interaction>
<assign roleType="SellerRoleType">
<copy name="copy">
<source expression="true" />
<target variable="cdl:getVariable('creditRatingOk','','')" />
</copy>
</assign>
</sequence>
</choice>
</sequence>
</workunit>
<workunit name="Request Delivery" guard="creditRatingOk = true" blocking="true">
…
</workunit>
</parallel>
The operational semantic of the workunit in WS-CDL can be described as follows:
Blocking
Workunit (G) (R) (B is True)
Body
Where
G => guard condition
R => repeat condition
B => blocking attribute
Body => CDL activities within the work unit
A typical order of evaluation is as follows:
(G) Body (R G) Body (R G) Body
With respect to a G then the G is only evaluated when the variables are available and evaluate to True and otherwise we wait at the guard condition. Thus the Body after the first G only gets executed when G is True. Or put another way Body is primed ready for action and then is executed when G evaluates to True.
IF G is unavailable or evaluates to False THEN it equates to:
when (G) {
Body
} until (!R)
IF G is always True THEN it equates to:
repeat {
Body
} until (!R)
IF R is always False THEN it equates to:
when (G) {
Body
}
5.2 Concurrent Performs
This is the unbounded number of sellers in an RFQ process that may use hasDurationPassed in a join condition in one scenario and may use first past the post in another join condition
5.3 Isolation Levels
In the RFQ process with multilple sellers the multiple concurrent subchoreos at the buyer await responses from the sellers. When a response comes back the buyer in the sub choreo updates an isolated variable if it's value that it has is better than the value it can see for that variable. This ensures that the subchoreos are synchronised in their updating of the new isolated variable so that the correct value is arrived at. Note: This raises a pitfall and implementation consideration about when isolated variables get locked. If you lock too soon you may not get the correct or desired behavior.
5.4 Advanced Channels
Once - The passed channel to the shipper is usage once so that it adds to privacy and ensures sound behavioral typing (aka this cannot participate in deadlock and livelock) Shared/Distinct and passing using "new" to be done Note: The "new" could be used to ensure that a fresh channel is passed. This would be used with the once in the advanced example and used as per normal in the normal example. Seller should not have "new" because the seller has received a channel from the buyer to pass to the shipper.
5.6 Alignment and Coordination
Coodination - Credit Check fails. Seller throws exception so goes into an exception state. And because the choreo is coordinationed the buyer also goes into its exception state because it was all coordinated. This of course involves hidden communication so that buyer and seller know abotu each other state wrt exceptions. Alignment will be done after we have sorted out the rest