\section{Development Framework}
\label{sec:development}

% Language {\scribble} is intended to be useful for modelling and
% development.  Only through actual usage can we know how
% the framework we envisaged, centring on types and logics
% for communications, 
% fare in their use for building distributed applications.
% In turn, for developers to {\em use} {\scribble}, we
% need concrete tools integrated into a development
% environment, which integrated modelling and development
% environment for building will make use of, and interface
% with, many existing tools and environments.  

\subsection{General Concepts}

\PARA{Development Environment of Distributed
  Applications.}
For {\scribble} to be useful for development, 
it should be complemented with 
associated software tools including programming languages, 
integrated into a development environment.
%% , which integrated modelling and development
% environment for building will make use of, and interface
% with, many existing tools and environments.  
The present authors, in conversation and collaboration
with academic and industry colleagues, started the
design and implementation of core development tools
centring on {\scribble} in late 2009, complemented
by other activities. Our aim
is to reach a simple and effective tool chain for
the development of distributed applications
which can effectively interface with existing artifacts
and tools such as UML and Java.
%% , with a view to full integration in future.  
We are still in an early stage
of design assessment and prototyping: below we
illustrate some of its key ideas.
%% technical elements, placing
% them in the context of the underlying general
% development ideas.

% Among the
% collection of tools to be used in such a development
% environment, one of the distinguishing features {\em
%   scribble} and its underlying theory offers is the
% {\em validation algorithms} for distributed
% applications.
% \PARA{Requirement Capture and Use Cases.}
% To present a focused discussion, we consider a simple
% flow of development, starting from requirements and
% reaching runtime management.  The development process
% will start from requirement capture and analysis,
% which will be distiled as {\em use case diagrams}
% and detailed description of each use case.
% Each use case will generally represent interactions
% among multiple actors, assisted by a system in
% question, rather than an interaction between an actor
% and a system. We may as well consider the use of other
% diagrams to describe scenarios. The tool developed by
% one of the authors (G.B.) with Steve Ross-Talbot offers 
% {\em scenario editors}, by which a user can present
% normal and other flows of interactions as diagrams.

\PARA{Modelling with Protocols.}

The requirement capture phase of the software development
life cycle leads to the identification of
significant scenarios, or use cases, associated
with the target system's usage. For
interactional systems, many of such use cases
may as well be {\em conversational} --- in the sense
that they represent interactions among more than
one actor. A use case can then be elaborated
into one or more scenarios-as-conversations,
each of which will obey a certain protocol: just
as an object referred to in a use case
scenario belongs to a class.

There are two functions which a tool can provide for
this modelling stage: to {\em\bf edit} protocols (with
grammatical checks) and to {\em\bf validate} their
semantic consistency or conformance to other
documents. To share protocols with other developers
one can also {\em\bf publish} protocols.  One can also
{\em\bf project} a protocol with multiple participants
to each endpoint (role), to produce a {\em local
  protocol} using the algorithm coming from the
underlying theory (see Section \ref{sec:theory}). This
gives a model of conversations from the local
viewpoint.

\PARA{Programming with Protocols.}

Protocols produced at the modelling stage may be
refined into more concrete protocols at the
design stage, so that they are eventually usable
for implementation.  A programmer may also need
new protocols just for implementation purposes,
as well as using already published protocols.
She will then {\em\bf edit a program}, which
uses typed sessions for communications among
programs, for example through a \scribble-aware
API for communications. She can then statically
{\em\bf check conformance} of her program to
stipulated protocols. Protocol descriptions can
also be used to {\em\bf test programs}, where
interactions are checked against protocols.

%% \PARA{Execution and Runtime Management.}

At runtime, each endpoint application is executed
through a runtime which links the high-level
communication operations for sessions to the
underlying messaging
infrastructure~\cite{HU07TYPE-SAFE,event}. Multiple
such endpoints will converse with each other over
multiple conversations, where each endpoint
participates in a session taking some role, as
specified in the underlying protocol. Communications
can be monitored to prevent a conversation from
violating a protocol, at each endpoint and/or
globally. If some anomaly is detected, a monitor will
notify this fact to an entity (a virtual agent) in
charge of policy enforcement. The protocol documents
also form basic part of the design document of the
system.

\subsection{Concrete Design}

\PARA{Project for {\scribble}-based Development Environment.}

{\scribble} and associated tools are being developed
by an open source project hosted at
\cite{ScribbleDevelopmentToolSite}, with multiple
academic and industry participants. Its purpose is to
provide a collaborative environment to support the
development of the language {\scribble} and associated
tools. One of the exciting aspects of the project is
the collaboration between academia and industry.
Within the project, we are aiming to harness the best
of these two worlds: leverage the academic results to
develop cutting edge capabilities, while providing the
stable software development life cycle required to
deliver a higher quality and better supported product
for use in industry.

Our current design of a tool chain focuses on Eclipse.  To
enable extensibility in this environment, we leverage the
OSGi standard. The tooling includes an Eclipse-based
context sensitive editor for \scribble.  Since Eclipse is
based on the OSGi framework, various \scribble-related
functions become automatically available in the editor as
OSGi modules become available. 
Extensibility also
facilitates incorporation of new research
ideas into existing tool functionalities.

Protocols are parsed by a parser generated by the
ANTLR parser generator, producing an internal
representation (a Java object model) through the
abstract syntax tree. It is this representation which
is used and acted upon by various validation modules,
discussed next.

% The parser is used to convert the text based Scribble
% notation into an internal representation (Java object
% model), which is used for processing by subsequent
% tooling modules. The parser is defined by a simple
% interface that can be used by any Java application or
% OSGi/Dependency Injection framework.
 
% The current implementation for the parser uses the
% ANTLR parser generator. This generator takes a grammer
% definition for the protocol notation and generates some
% Java classes to implement the parser. The parser
% produces an abstract syntax tree which is then
% converted into a domain specific Scribble protocol
% object model, using a custom adapter configured with
% some simple rules.
 
% A subset of the grammer is shown here:
% \begin{verbatim} 
% roleName: ID ;
% typeReferenceDef: ID ;
% interactionSignatureDef: ( typeReferenceDef | ID '('! ( typeReferenceDef
% 						( ','! typeReferenceDef )* )? ')'! ) ;

% interactionDef: interactionSignatureDef ( 'from' roleName )?
% 						( 'to' roleName ( ','! roleName )* )? ;
 
% whenBlockDef: interactionSignatureDef blockDef ;

% choiceDef: 'choice'^ ( 'from' roleName )? ( 'to' roleName )?
% 						'{'! ( whenBlockDef )+ '}'! ;

% repeatDef: 'repeat'^ ( '@' roleName ( ','! roleName )* )? blockDef ;
% \end{verbatim}  
% \NI The grammer above defines the syntax of three
% protocol activities, interaction, choice and repeat.
 
\PARA{Static Validation and Other Algorithms.} 

One of the fruits of the industry-academia
collaboration in the {\scribble} project is the
use of the latest research results on validation
and other algorithms that are provably correct
to give the required results.  Each validation
module is responsible for processing a
{\scribble} protocol object model to output
whether it is valid or not (with respect to a
specific criteria). Validations can be
arbitrarily chained, and are usually set up so
that they are triggered automatically as a
protocol description is created or updated in
the editor.  A new validation function can be
added simply by installing an OSGi module
implementing the appropriate interface. The main
validation functions include:
\begin{enumerate}
\item Syntactic consistency (parsability)
\item Semantic consistency of session types (including
  linearity guarantee, which avoids a race condition
  in a conversation \cite{HYC08})
\item Conformance checking of a local protocol against 
  a global one \cite{mostrous_yoshida_honda_esop09}.
\end{enumerate}
The conformance checking noted above is also
used for local protocols extracted from an
implementation of an endpoint in an already
existing program, written in e.g. BPEL.
These validations,
together with other functions such as the
projection of a global protocol to local
protocols (using the latest algorithm from
\cite{yoshida.denielou.bejleri.hu10}), 
can be lifted to logical specifications 
following \cite{BHTY10}.
Another form of validation is dynamic validation
through monitors, using an efficient internal
representation of protocols. 
The design and implementation of
these and other validation modules are under way, with
a stable release planned in late 2011.

Finally, programming support for {\scribble} for
existing languages comes from two sources: APIs and
language extensions. In both cases, a type checker,
which validate type correctness of programs against
local protocols, plays a key role.  Three
implementations covering both approaches are under
way, based on the latest research on session-based
programming and runtime \cite{HU07TYPE-SAFE,event}.

% Intuitively, we need to ensure that the local
% representation (which could be derived from an
% endpoint program) correctly reflects the behaviour
% associated with the role within the global model.
% Achieving this task is a validation module for
% conformance checking. Unlike most other validations,
% this validation demands two arguments, a local
% protocol and a global protocol. The programming experience
% using protocols and their conformance checking in Java
% are reported in \cite{SJ,SJ2}.

% Static protocol checking is another form of conformance,
% checking whether or not an endpoint program
% (implementing some role) conforms to a local protocol.
% For example, in the simplest case, the message type
% associated with a particular interaction in a program
% may be wrong. In a more advanced case, the interaction
% sequence implemented in a program may not match what is
% stipulated in a protocol.


%  An efficient
% monitoring engine polices the behaviour of a particular
% endpoint, using a state machine representation of a
% protocol. When messages are either sent or received, on
% behalf of that role within the local endpoint, then the
% message is delegated to the monitor to check if it is
% valid, using a context information.  If the monitor
% determines that the message is inappropriate, then the
% containing environment will be notified. It can then
% decide whether or not to continue delivery of the
% message.

