An Executable Calculus for Service Choreography
Paolo Besana1 and Adam Barker2
1University of Edinburgh, 2University of Melbourne
Abstract The Lightweight Coordination Calculus (LCC) is a compact
choreography language based on process calculus. LCC is a directly ex-
ecutable specification and can therefore be dynamically distributed to a
group of peers for enactment at run-time; this offers flexibility and allows
peers to coordinate in open systems without prior knowledge of an inter-
action. This paper contributes to the body of choreography research by
proposing two extensions to LCC covering parallel composition and cho-
reography abstraction. These language extensions are evaluated against
a subset of the Service Interaction Patterns, a benchmark in the process
modelling community.
1 Introduction
A core challenge in today’s ever connected world is in combining distributed
resources on-demand to perform coordinated tasks. Coordination of distributed
resources can be achieved through the use of workflow technologies. Workflow
specifications defined using standard orchestration languages such as the Busi-
ness Process Execution Language1 typically facilitate statically defined work-
flows to be enacted by a centralised workflow engine. The resulting workflow
specifications can be brittle due to the highly dynamic nature of distributed
resources and scalable only to a point [1]. Dynamic composition of resources
around tasks can address these issues.
The OpenKnowledge project2 has produced a framework providing the mid-
dleware that assorted peers can use to interact within an open system. Peers in-
teract following protocols, named interaction models, that define their externally
observable behaviours. These protocols provide a global view of the interactions,
and therefore fit into the definition of choreography, as opposed to the one of or-
chestration, considered to be a description of coordination from the perspective
of a single process. The protocols are written in the Lightweight Coordination
Calculus (LCC), a compact choreography language based on process calculus.
This paper introduces the LCC syntax, corresponding OpenKnowledge frame-
work (Section 2) and discusses its current limitations and possible workarounds
(Section 3). We propose two extensions to the LCC language (Section 4) and
evaluate these changes by analysing the representations of two interaction pat-
terns (Section 5). Related work is discussed (Section 6) in the context of our
language extensions. Finally our contributions are summarised (Section 7).
1 www.oasis-open.org/committees/wsbpel/
2 www.openk.org/

2 OpenKnowledge and LCC
The OpenKnowledge kernel [7] has been designed with the goals of light weight-
ness and compactness. The core concept is the set of shared interaction models,
enacted by participants, called peers, that play roles within them. Interaction
models are written in the Lightweight Coordination Calculus (LCC) [5], a com-
pact, executable choreography language based on process calculus.
An interaction model in LCC is a set of role clauses. Clauses can refer to
entry-roles, which participants initially assume, and auxiliary-roles, that can be
reached only from other roles. Participants in an interaction take their entry-
role and follow the unfolding of the clause specified using a combination of the
sequence operator (‘then’), or choice operator (‘or’) to connect messages and
changes of role. A participant can take several roles during an interaction and
can recursively take the same role (for example when processing a list). Messages
are either outgoing to (‘)’) or incoming from (‘(’) another participant in a
given role. Message input/output or change of role is controlled by constraint
satisfaction.
a(auctioneer(Product; Bidders); A) ::
a(caller(Product; Bidders); A)
then a(waiter(Bidders; curwinner(nul; 0); Winner)
then sold(Product; Price)) a(bidder; WB) curwinner(WB; Price) = Winner
a(caller(Product; Bidders); A) ::
null Bidders = [] %no bidders left
or

invite_bid(Product)) a(bidder; BH) Bidders = [BHjBT]
then a(caller(Product; BT); A) % recursion

a(waiter(Bidders; Bids; curwinner(WinBidder; WinBid); Winner) ::
null allarrived(Bids; Bidders) and Winner = curwinner(WinBidder; WinBid)
or null timeout() and Winner = curwinner(WinBidder; WinBid)
or
0
@
bid(Offer)( a(bidder; B) then
a(waiter([BjBidders]; curwinner(B; Offer); Winner) Offer > WinBid
or a(waiter([BjBidders]; curwinner(WinBidder; WinBid); Winner)

1
A
or a(waiter(Bidders; curwinner(WinBidder; WinBid); Winner) sleep(1000)
a(bidder; B) ::
invite_bid(Product)( a(caller; A)
then bid(Product; Offer)) a(caller; A) bid_at(Product; Offer)
then sold(Product; Price)( a(auctioneer; A)
Figure 1. Auction protocol, % represents a comment.
Figure 1 shows an interaction model for an auction. The interaction starts
with the auctioneer role that receives the product to sell and the list of bidders
as an input parameters. It immediately changes its role to caller passing in
the list of bidders and the product to sell. The caller recurses over the list of