\section{Background: Modelling Interactions through Protocols} 
\label{sec:motivation}

\PARA{Protocols in Interactional Computing.}
The idea of protocols becomes important for general software
development when the shape of software becomes predominantly
a collection of numerous distributed processes communicating
with each other. Such {\em interactional computing} is
increasingly common in practice, from web services to
financial protocols to services in clouds to parallel
algorithms to multicore chips. Processes will be engaged in
many interleaving conversations, each obeying a distinct
protocol: the aggregate of overlapping conversations make up
a whole distributed system. Dividing the design into
distinct conversations promote tractability because the
structure of one conversation in an
application are relatively unaffected by 
other conversations.

% Observe that it is
% generally unfeasible to divide a distributed
% application into disjoint subsytems (for example
% Alice's interactions with banks will overlap with
% mine with travel agency, obeying distinct protocols
% but overlapping at the participant Alice): a naive
% application of the divide-and-conquer method, often
% effective for simple parallel algorithms, does not
% work.

% \axm{Looks redundant}\sout{For example, a travel agency may electronically
% interact with its
% customer obeying an agreed-upon protocol,
% and, to meet the demands of the customer, interacts with
% other service providers, for example airline
% companies, again following a certain protocol. 
% It is good to have these two conversations 
% separately
% since, for example, when it is necessary to have
% different interactions for the agency to purchase
% airline tickets (e.g. through another wholesale agent),
% we can keep the interaction structures with
% customers intact.}

A protocol offers an agreement on the ways interactions
proceed among two or more participants.
Without such an agreement, it is hard to
do meaningful interactions: participants cannot
communicate effectively, since they do not know when the
other parties will send what kind of data and 
through which channels.
%: it is too costly to carry
%out communications in such an ad-hoc way.  Simply put, it is
%unfeasible as an engineering practice.
%  to try to build
% interactional software without having a clear notion of
% protocols. % As we shall discuss in Sections 3, protocols
% % also offer an interactional notion of components' {\em
% %   interface}, enabling modular software development.
This is why the need to describe protocols have been
observed in many different contexts in the practice of
interactional computing, as we illustrate below.

\PARA{Needs for Protocols (1): Global Financial Network.}

ISO TC68, the Technical Committee for Global Financial
Services in ISO, recognized the need for a mechanism to
register and maintain international financial protocols
(FPs) under the auspice of ISO. This has led to the
establishment of a working group for FPs, WG4, which is in
charge of drafting the evolving global standard for FPs,
ISO20022 \cite{UNIFI}, using high-level models for describing message
formats based on UML. The use of high-level models enable
flexible engineering, such as compilation to different
document format (e.g. XML schemas and ASN.1), semantic matching
of message fields, and model-driven 
development.~\cite{MDAFrankel}
%%% part of the development document.

However a message format alone cannot describe an FP in
its entirety: the flows in which asynchronous messages
are exchanged is at the heart of the FPs.  In ISO20022,
this dynamic aspect of a FP is called its {\em message
  choreography} 
%% \begin{quote}
(``Every Business Transaction contains its own
  Message Choreography''~\cite{UNIFI}).
%% \end{quote}
In spite of its importance, the chair of WG4
observed that the description of the message
choreography through the current %%modelling
technology has severe limitations:
\begin{enumerate}
\item {\em It is imprecise:} The descriptions
  of protocols are unclear, ambiguous and misleading, and
  legally unusable.
\item {\em It is incomplete:} It is impossible to
  describe the structure and constraints of FPs in their
  entirety up to a suitable abstraction level.
\item {\em It is informal:} The description cannot
  be used for formal reasoning about protocols;
  for checking their internal consistency; for
  verifying, either by hand or by machine, the
  conformance of endpoint programs against a given
  protocol; for code generation; for testing; and
  for runtime control.
\end{enumerate}
A precise, complete and formal description of message
choreography would offer a vital tool for harnessing and
governing global FPs. A long-term goal of WG4 is to
identify an effective method for describing message
choreography of FPs, and use it in future versions of
ISO20022.

\PARA{Needs for Protocols (2): Operating System for Multicore CPUs.}

We turn our eyes to a basic form of systems
software, operating systems. Most commodity computers
nowadays are equipped with multi-core processors,
which offer an effective way of harnessing high-density
transistor circuits without incurring the performance
penalties associated with monolithic processors. This trend
is expected to continue in future, where many-core
processors, whose numerous cores share a
high-bandwidth on-chip interconnect, will become a
commonplace \cite{BPSSRBI09}.  As a
consequence, computers are increasingly resembling a
distributed system, which cannot be effectively utilised by
traditional monolithic OS kernels built around shared data
structures that suffer from performance and scalability
issues in a parallel execution environment.

Barrelfish is a new multi-kernel OS architecture that
aims to address the challenge~\cite{BBDHIPRSS09}. It is designed
to run on heterogeneous multicore machines and is
structured as a distributed system of cores that
communicate via explicit message passing and share no
memory. Early benchmarks on present day multi-core
computers showed that the performance of Barrelfish is
comparable to that of existing commodity operating
systems and can scale better to support future many-core
hardware \cite{BBDHIPRSS09}.  There are clear parallels between
Barrelfish OS and a distributed system, and in
particular, the importance of having unambiguous
specification of communication protocols. However,
the current programming development for Barrelfish 
only offers description of procedural interface,
making it hard to ensure compatibility at the 
level of asynchronous message passing among
OS components, a predominant mode in
this operating system.

\PARA{Needs for Protocols (3): Web Services.}

In web services, applications make an extensive use of
communications among components and services through the
standardised format and transport technologies
(e.g. URI, XML and TCP/HTTP), increasingly combined with
other distributed computing technologies such as clouds,
messaging and distributed store. Business transactions
using web services are often termed {\em business protocols}
because each of them obeys an agreed-upon conversation
structure.  Web Services Choreography Description
Language (WS-CDL) \cite{CDL} was conceived in W3C as a declarative,
XML-based domain-specific language for specifying
%% communication interactions in 
business protocols. It is
also a first standardization effort done 
%% instigated by the
%% working group 
in collaboration with the $\pi$-calculus
experts from academia.

WS-CDL is notable in that its description captures
``global'' ordering -- a {\em choreography} -- of
observable behaviour of participants in a
channel-based communication.  It comprises a rich
set of concepts (roles, work units, exceptions,
etc.) and general control constructs (sequencing,
parallel, conditionals, recursion) for expressing
multi-party interaction.  At the same time, as a
descriptive means for protocols, it has several
drawbacks: first, although a subset of WS-CDL has
been given a formal semantics using the
$\pi$-calculus
\cite{CDLa,carbone.honda.yoshida:esop07}, the language
as a whole is not equipped with the notion of {\em
  projection from a global specification to
  endpoint specifications} (which is important for
deriving communication specification for local
participants); and it lacks a clear stratification
between specifications and executable programs.

\PARA{Needs for Protocols (4): Large-scale Cyberinfrastructure.}
The Ocean Observatories Initiative (OOI) is a large-scale project
funded by US National Science Foundation for implementation of a
distributed environmental science observatory with persistent and
interactive capabilities that have a global physical observatory
footprint~\cite{ooi,Chave2009}. A key component of the OOI is a
comprehensive cyberinfrastructure (CI), whose design is based on
loosely coupled distributed services and agents, expected to reside
throughout the OOI observatories, from seafloor instruments to
on-shore research stations.
%%%
The CI acts as an integrating element that links the 
sub-networks of OOI into a
coherent system-of-systems and uses a large
catalogue of communication protocols among distributed
instruments and stakeholders. These protocols are required
to be unambiguously specified for the implementation and
runtime communication monitoring.
%% within the
%% infrastructure.
%%
% \axm{ditto}\sout{We are presently working with the OOI team on the
%   application of \name{Scribble} and its tools for that purpose.}

\PARA{Towards a Descriptive Basis for Protocols.}
The pervasiveness and complexity of interactional
computation in modern and future
computing 
%ranging from large-scale distributed
%applications to systems software for multi-core chips,
highlight the need for a general and rigorous protocol
description framework, usable throughout the software
development life cycle, equipped with a clear, transparent semantic
basis, and
offering foundations for modular software development
through 
computer-aided validation and verification tools.
%% these purposes, we need a clear, unambiguous, and
%% expressive descriptive means for application-level
%% protocols.
%% In the following we report our 
We now illustrate our recent efforts to develop 
such a framework, centred on a small description language
for scribbling protocols. 
%founded on the long tradition of the study of process algebras.
