\section{Formal Foundations of \scribble}
\label{sec:theory}

\PARA{General Ideas.}

{\scribble} is formally based on the
$\pi$-calculus and its type theory called {\em session
  types}. Having a general, well-understood theoretical
foundation is important since without such a foundation,
we cannot establish clear semantics for protocol
descriptions, we cannot rigorously analyse how
descriptions relate to dynamics, and we cannot accurately
state and validate properties of a target system.  The
$\pi$-calculus enjoys full expressiveness for representing
interactional behaviours in spite of its tiny syntax: it
can mathematically embed a large class of
communication-centred software behaviours, including those
of existing programming languages, without losing
precision. For this reason, the study of session types in
the $\pi$-calculus, including various validation
algorithms, can be directly applicable to real-world
programming languages.  Below we informally outline the
correspondence between the theory of session types and
\scribble, including assurance of properties founded on
this theory.

% In this way, the study of the
% $\pi$-calculus enables a broad exploration of
% specification and verification methods, offering a general
% and effective basis for diverse development efforts.

% The purpose of this section is not to introduce the
% formal theory of the $\pi$-calculus and session
% types. Rather we wish to illustrate how a formal
% notation and its theory of
% sessions can offer such a theoretical basis. Born
% from a theoretical study of the $\pi$-calculus,
% session types provide a simple, robust and feasible
% method for specifying and validating protocols for
% distributed applications. We informally illustrate the
% main idea of global session types (which correspond to
% protocols in \scribble) and their projections to
% endpoints. Then we discuss how they can be used for
% static type checking, and what safety and liveness
% properties this framework can ensure, a linchpin of
% session types. This framework can be ramified to
% dynamic validation, as we briefly discuss.

\PARA{Types for Protocols: Session Types.}

In sequential programming language such as Java and C, a
type mainly stipulates the data type of a variable.  In
particular, in typed languages, all variables should first
be declared before they can be used. For example, {\small
\[
\begin{array}{c}
 \keyword{int}\ \ \keyword{storage} = 1;
\end{array}
\]
} \NI 
This program involves stating the type and name of a
variable, and telling program that a field named
$\keyword{storage}$ exists, holds numerical data, and
has an initial value of $1$.

Extending this view to interactional computing,
session types set the rules for a session
(conversation), ensuring safe interactional behaviours
for each session. The specification starts from a {\em
  global session type} or a {\em global type}
\cite{HYC08}, which describes the whole
conversation scenario. It gives a specification for
the whole protocol from a bird's eyes by giving the
rules of conversations for all participants. This
global type corresponds to a protocol in \scribble:
the \scribble's protocol notation was born from the
theories of global types studied in
\cite{BettiniCDLDY08}, which is the advancement of the theory
presented in \cite{HYC08}.

A local type represents the type of interactions for
each role, played by a principal in a conversation. It
is given by projecting the corresponding global type
onto a specific role. The following example shows
that, in a Buyer-Seller-Broker session $s$, a
$\keyword{Buyer}$ asks $\keyword{Broker}$ for a
product, and sends the product's
name. $\keyword{Broker}$ refers this request to
$\keyword{Seller}$, then $\keyword{Seller}$ replies to the
$\keyword{Broker}$ with the product's
price. $\keyword{Broker}$ refers the price to
$\keyword{Buyer}$ after receiving it. 
{\small
\[
\begin{array}{rcl}
G &=& \keyword{Buyer} \rightarrow \keyword{Broker}: \keyword{string}.\\
  &&  \keyword{Broker} \rightarrow \keyword{Seller}: \keyword{string}.\\
  &&  \keyword{Seller} \rightarrow \keyword{Broker}: \keyword{int}. \\
  &&  \keyword{Broker} \rightarrow \keyword{Buyer}: \keyword{int}. \\
  &&  \keyword{end}.\\
\end{array}
\]
}
The local types for $\keyword{Buyer}$ are
$$
\langle \keyword{Broker}\rangle
! \langle \keyword{string} \rangle . \langle
\keyword{Broker}\rangle ? (\keyword{int}),
$$
%%%%%
which are the projection from $G$ onto
$\keyword{Buyer}$. This local types indicate that a
$\keyword{Buyer}$ should firstly send a name
of type $\keyword{string}$ to $\keyword{Broker}$, and
then wait to receive a price, which is a variable of
type $\keyword{int}$, sent from $\keyword{Broker}$.

Similarly, the local type for $\keyword{Seller}$ is
given as
$$
\langle \keyword{Broker}\rangle ? (\keyword{string})
. \langle \keyword{Broker}\rangle !  \langle
\keyword{int} \rangle,
$$ 
and the local type for $\keyword{Broker}$ is
$$
\langle \keyword{Buyer}\rangle?
(\keyword{string}) . \langle \keyword{Seller}\rangle
! \langle \keyword{string} \rangle . \langle
\keyword{Seller}\rangle ? (\keyword{int}) . \langle
\keyword{Buyer} \rangle ! \langle \keyword{int} \rangle.
$$
Through a global type, we can stipulate the whole set of
rules of interactional behaviours participated by all
participants; whereas a local type enables the
corresponding endpoint (local program) to know the rules
of behaviours for a specific role in a conversation.

\PARA{Safety Assurance by Session Types.}

The typing system of {\scribble} for multi-party sessions
follows \cite{BettiniCDLDY08}, using their global types and
projection rules. A well-designed typing system can
ensure error-free conversations among multi-party
sessions \cite{HYC08}, by typing each endpoint
with the corresponding local type, which is projected from a
stipulated global type. Thus, for a given
conversation, we can assure each of its participants
plays its role correctly. This assurance can be done
effectively at the programming/compilation-time: we
can derive a typing algorithm from the tying rules,
which can (in)validate that a process, corresponding 
to an application program at some
endpoint, is conforming to a projected local type.
Thus session types provide static type-checking at the
programming time.

When all endpoints are type-checked and they start
interaction, they satisfy several significant
properties. First, we have a formal theorem which says
that
\begin{quote}
{``well-typed processes never exchange wrong values.'' }
\end{quote}
That is, if a process is expecting an integer, it will
get an integer; and if it expects a string, it will
receive a string. Secondly, inside each session
(conversation), there is what is often called {\em
  linearity}:
\begin{quote}
  ``an output is never shared by more than one inputs,
  and vice versa.''
\end{quote}
Finally, we can assure that the interactions through a
well-typed conversation follow the initially stipulated protocol:
\begin{quote}
  ``interactions inside a session among well-typed
  processes under a global type, never violate the
  scenarios given in that type.''
\end{quote}
This property can be further strengthened under certain
conditions that interactions can always proceed in a
session, so that they inevitably complete one of the
scenarios given in a protocol, assuring an important
liveness property. Here by a {\em liveness} property we mean a
property demanding a process can surely do a good thing.
In contrast, the preceding three properties are about
{\em safety} since each says that a process never does a
stipulated bad thing.

The type-based static checking (including projection) and properties
ensured by the typing algorithm give a basis of diverse engineering
practice and theories centring on session types. As has been studied
in \cite{BHTY10}, a logical method, which elaborates session types
with assertions (just as Design-by-Contract elaborates procedural
types with logical formulae), can be built on this basis, offering a
form of a rely-guarantee-based method \cite{Jones83} for
modular specification and verification for communicating processes. The
logical method uses precisely the same validation framework except
that the original algorithms are lifted from session types to their
logical elaboration.  Further, a series of studies show how we can
consistently and effectively incorporate session types in the
semantics and pragmatics of existing programming languages
\cite{ecoop06,HU07TYPE-SAFE,event}. % Further, on the basis
% of the theory of types and static type checking
% outlined above, we can extend the framework to dynamic
% checking of various kinds as suggested in
% \cite{BHTY10}. Such dynamic checking is necessary for
% large-scale distributed systems.

% assure system safety and detect misbehaviours during
% runtime. Dynamic checking can be realised through a
% monitoring system by monitoring behaviours of
% participants in every session with session types. We
% adopt the basic idea of distributed monitoring
% proposed by \cite{Ogle93} for a large-scale
% distributed system. In a distributed monitoring
% system, every participant, such as an application, has
% a corresponding monitor, which monitors both the
% behaviour (messages) coming from the participant, as
% well as the messages flowing into that
% participant. Messages are shipped among monitors in
% one session. The corresponding local monitors can
% efficiently deal with messages and response error
% messages effectively.

% \subsubsection{Monitoring Grammar}
% \label{sec:mon_grammar}
% For theoretical formalism, we use $M[P]$ to denote that process $P$ is being monitored by its corresponding monitor $M$. Assume we use $\Gamma$ to denote the shared environment for monitoring, and $\Delta$ to denote the typing environment, which illustrate the current typing status for communication processes. A monitor $M$ and a monitoring network $N$ can be defined as:
% {\small
% \[
% \begin{array}{rcll}
% M & \quad::=\quad &
%                  \Gamma , \Delta 
% \\
% N & \quad::=\quad &
%     \emptyset \;\ | \;\ 
%     M[P] \;\ | \;\ 
%     N_1 \mid N_2 \;\ | \;\ 
%     (\nu n) N \;\ | \;\ 
%     s:\VEC{h} \;\ | \;\ 
%     \AOUTPUT{a}{s[p]}

% \end{array}
% \]
% }
% With this design, a monitor $M$ consists of shared typing environment $\Gamma$ and typing environment $\Delta$. It gets monitoring rules from the both. A monitoring network $N$ is a network of processes and their corresponding monitors, as well as message queues $s:\VEC{h}$ and message $\AOUTPUT{a}{s[p]}$, which denotes creating a new session $s$ and inviting a principal to play a role $p$ in shared channel $a$. $(\nu n) N$ means to create a new session/shared channel in a monitoring network $N$.

% The theoretical formalism for distributed monitoring can help us not only establishing provable properties and checking the soundness of monitoring mechanism, but also provide a robust basis for Scribble. With this basis, Scribble is capable to be a communication programming language in monitoring.   

%%%----citation part-----%%%
%@inproceedings{Bettini,
%  author    = {Lorenzo Bettini and
%               Mario Coppo and
%               Loris D'Antoni and
%               Marco De Luca and
%               Mariangiola Dezani-Ciancaglini and
%               Nobuko Yoshida},
%  title     = {Global Progress in Dynamically Interleaved Multiparty Sessions},
%  booktitle = {CONCUR},
%  year      = {2008},
%  pages     = {418-433},
%  ee        = {http://dx.doi.org/10.1007/978-3-540-85361-9_33},
%  crossref  = {DBLP:conf/concur/2008},
%  bibsource = {DBLP, http://dblp.uni-trier.de}
%}

%@inproceedings{HondaYC08,
%  author    = {Kohei Honda and
%               Nobuko Yoshida and
%               Marco Carbone},
%  title     = {Multiparty asynchronous session types},
%  booktitle = {POPL},
%  year      = {2008},
%  pages     = {273-284},
%  ee        = {http://doi.acm.org/10.1145/1328438.1328472},
%  crossref  = {DBLP:conf/popl/2008},
%  bibsource = {DBLP, http://dblp.uni-trier.de}
%}

%@article{Ogle93,
% author = {Ogle, D. M. and Schwan, K. and Snodgrass, Richard Thomas},
% title = {Application-Dependent Dynamic Monitoring of Distributed and Parallel Systems},
% journal = {IEEE Trans. Parallel Distrib. Syst.},
% volume = {4},
% number = {7},
% year = {1993},
% issn = {1045-9219},
% pages = {762--778},
% doi = {http://dx.doi.org/10.1109/71.238299},
% publisher = {IEEE Press},
% address = {Piscataway, NJ, USA},
% }
