Formal Models for Programming and Composing
Correct Distributed Systems
Ludovic Henrio
Habilitation thesis (HDR)
Jury :
Gordon Blair
Pascal Poizat
Alan Schmitt
Fabienne Boyer
Michel Riveill
Eric Madelaine
Davide Sangiorgi
OASIS Team
INRIA – UNS – I3S – CNRS
Sophia Antipolis
Agenda
I. Introduction: Formal Methods
II. A Distributed Component Model
III. Behavioural Specification
IV. Dynamicity
V. A Few Hot Topics
2
My objective
Help the programmer write
correct distributed applications, and run them safely.
• By designing languages and middlewares
• By proving their properties
• By providing tools to support the development and proof of
correct programs
Programming easily correct concurrent programs is still a
challenge - ERC Bertrand Meyer:
“devise a powerful, efficient and secure concurrent solution to
address the needs of the programming community”
Distributed programming is even more difficult, and more and
more useful (cloud computing, service oriented computing …)
3
What are Formal Methods (here)?
• Mathematical techniques for developping computerbased systems:
 Programs
 Languages
 Systems
• What tools?
 Pen and paper (PP)
 Theorem proving (TP) = proof assistant
 Model checking (MC) = check a formula on (an
abstraction of) all possible executions
 …
4
For what?
For proving properties / correctness of
•Languages (ASPTP+PP, algorithmic skeletonsPP)
•Programs (work on behavioural specificationMC)
•Algorithms (CANTP)
•Middleware (future update strategiesTP, component
platformTP, fault-tolerancePP)
•…
 Increase the confidence people have in the system
 Help my colleagues implement correct (and efficient)
middlewares
 Help the programmer write, compose, and run correct and
efficient distributed programs
5
My general approach
Programming
model and
definitions
Generic
properties
Implementation
Optimizations
Verification and
tools
Optimizations
6
My general approach
Programming
model and
definitions
Generic
properties
Implementation
Optimizations
Verification tools
Definitions and Properties
Optimizations
are easy to understand
check the
proofs
7
My general approach
Programming
model and
definitions
Generic
properties
Implementation
Optimizations
Verification tools
Definitions and Properties
Optimizations
are easy to understand
8
Agenda
II. A Distributed Component Model
III. Behavioural Specification
IV. Dynamicity
V. A Few Hot Topics
9
What are Components?
Primitive component
Business code
Server
/ input
Client
/ output
10
What are Components?
Composite component
Primitive component
Business code
Primitive component
Business code
 Grid Component Model (GCM)
An extension of Fractal for Distributed computing
11
But what is a Good size for a
(primitive) Component?
Not a strict requirement, but somehow imposed by the
model design
• According to CCA or SCA, a service (a component
contains a provided business function)
• According to Fractal, a few objects
• According to GCM, a process
 In GCM/ProActive,
1 Component (data/code unit)
= 1 Active object (1 thread = unit of concurrency)
= 1 Location (unit of distribution)
GCM: A Grid Extension to Fractal for Autonomous Distributed Components - F. Baude, D.
12
Caromel, C. Dalmasso, M. Danelutto, V. Getov, L. Henrio, C. Pérez - Annals of Telecom. - 2008
A Primitive GCM Component
CI
CI.foo(p)
In ProActive/GCM a primitive component is an active object
 Primitive components communicating by asynchronous
requests on interfaces
 Components abstract away distribution and concurrency
13
Futures for Components
1
f=CI.foo(p)
……….
g=f+3
2
3
Component are independent entities
(threads are isolated in a component)
+
Asynchronous requests with results

Futures are necessary
14
First-class Futures
…
…
f=CI.foo(p)
…
CI.foo(f)
Only strict operations are blocking (access to a future)
Communicating a future is not a strict operation
In ProActive and ASP, futures are created and
accessed implicitly (no explicit type “future”)
IN contrast with Creol, Jcobox, ...
15
First-class Futures and Hierarchy
return C1.foo(x)
… …
…
Without first-class futures, one thread is systematically
blocked in the composite component.
A lot of blocked threads
In GCM/ProActive  systematic deadlock
16
Back to Formal Methods:
a Framework for Reasoning on Components
• Formalise GCM in a theorem prover (Isabelle/HOL )
Component hierarchical Structure
Composite component
Primitive component
• Bindings, etc…
• Design Choices
 Suitable abstraction level
 Suitable representation (List / Finite Set, etc …)
• Basic lemmas on component structure
Business code
Primitive component
Business code
17
A semantics of Primitive Components
• Primitive components are defined by interfaces plus an
internal behaviour, they can:
 emit requests
 serve requests
 send results
 receive results (at any time)
 do internal actions
some rules define a
correct behaviour,
e.g. one can only send result for a served request
18
Communication inside Composites
• Composites only delegate calls between components
• Use the bindings to know where to transmit requests
• Component system behaviour is expressed as a small step
semantics, and specified on paper and in Isabelle/HOL
A Framework for Reasoning on Component Composition
Ludovic Henrio, Florian Kammüller, and Muhammad Uzair Khan - FMCO 2009, Springer
19
Future Update Strategies (Muhammad Khan)
• How to bring future values to components that need them?
• A “naive” approach: Any component can receive a value for
a future reference it holds.
• More operational is the lazy approach:
require future value
20
Eager home-based future update
• avoids to store future values indefinitely
• Relies on future registration
register future
Results sent as soon as available
Every component with future reference is registered
Un-necessary transfers
Garbage collection of computed results possible
register future
Formalised in Isabelle
First Class Futures: Specification and Implementation of Update Strategies
L. Henrio, Muhammad U. Khan, Nadia Ranaldo, Eugenio Zimeo CoreGRID@Europar 2010.
21
Properties on Future updates
• Future updates remove all references to a given future
Garbage
collectable
• All Future references are registered during reduction
Complete
register future
registration
Ludovic Henrio and Muhammad Uzair Khan “Asynchronous Components with
Futures: Semantics and Proofs in Isabelle/HOL” - FESCA 2010 - ENTCS
22
A refined GCM model in Isabelle/HOL
• More precise than GCM, give a semantics to the model:

asynchronous communications: future / requests
 request queues
 no shared memory between components
 notion of request service
• More abstract than ProActive/GCM

can be multithreaded
 no active object, not particularly object-oriented
A guide
for implementing
andand
proving
properties
of
Similarities
with: SCA
Fractal
(structure),
component
middlewares
Creol
(futures)
23
Agenda
III. Behavioural Specification
IV. Dynamicity
V. A Few Hot Topics
24
How to ensure the
correct behaviour of a given program?
• Theorem proving too complicated for the ProActive
programmer
• Our approach: behavioural specification
Service methods
Service methods
pNets:
 Trust
the implementation step
 Or static analysis
 Generate correct (skeletons of) components
(+static and/or runtime checks)
Behavioural Models for Distributed Fractal Components Antonio Cansado, Ludovic
Henrio, and Eric Madelaine - Annals of Telecommunications - 2008
25
Use-case: Fault-tolerant storage
• 1 composite
component with 2
external services
Read/Write.
• The service requests
are delegated to the
Master.
•
1 multicast interface sending write/read/commit requests
to all slaves.
• the slaves reply asynchronously, the master only needs
enough coherent answers to terminate
Verifying Safety of Fault-Tolerant Distributed Components
Rabéa Ameur-Boulifa, Raluca Halalai, Ludovic Henrio, and Eric Madelaine - FACS 2011
26
Full picture: a pNet
?Q_Write(x)
!Q_Write(b)
27
Basic pNets: parameterized LTS
Labelled
transition
systems, with:
•Value passing
•Local variables
•Guards….
Can be written
as a UML
diagram
Eric MADELAINE
28
Properties proved
• Reachability(*):
1- The Read service can terminate
fid:nat among {0...2}. ∃ b:bool.
<true* . {!R_Read !fid !b}> true
2- Is the BFT hypothesis respected by the model ?
< true* . 'Error (NotBFT)'> true
•
Termination:
After receiving a Q_Write(f,x) request, it is (fairly) inevitable that the Write
services terminates with a R_Write(f) answer, or an Error is raised.
•
Functional correctness:
After receiving a ?Q_Write(f1,x), Prove
and before the next ?Q_Write, a ?Q_Read
requests
raises a !R_Read(y)
response,
with y=x of deadlock
 generic
properties
like absence
 or properties specific to the application logic
(*) Model Checking Language (MCL), Mateescu et al, FM’08
29
Recent advances in
behavioural specification for GCM
• Scaling-up : gained orders of magnitude by a combination of:
 data abstraction,
 compositional and contextual minimization,
 distributed state-space generation.
• Specified formally the whole generation process (in progress)
30
Agenda
IV. Dynamicity
V. A Few Hot Topics
31
Adaptation in the GCM
• Functional adaptation: adapt the architecture
+ behaviour of the application to new
requirements/objectives
• Non-functional adaptation(Paul Naoumenko):
adapt the architecture of the container+middleware to
changing environment/NF requirements (QoS …)
Both functional and non-functional adaptation are expressed
as reconfigurations
Additional support for reconfiguration
(Marcela
Rivera):
Language
support for distributed reconfiguration:
• A stopping algorithm for
GCM
GCM-script
components
• A Scripting language for reconfiguring
A platform for designing and running autonomic components
distributed components
A Component Platform for Experimenting with Autonomic Composition
Françoise Baude, Ludovic Henrio, and Paul Naoumenko. Autonomics 2007.
32
Formalising Reconfiguration (preliminary)
• In our Isabelle/HOL model component structure known at
runtime
 Two reconfiguration primitives formalised (remove
and replace)
 Illustrates the flexibility of the approach
 Basic proofs
• In our pNets model
 Old results (Tomas): start/stop/bind for Fractal
components
 Concerning GCM: formalisation and experiments in
progress
33
Agenda
V. A Few Hot Topics
34
Correct component reconfiguration
Towards safety and autonomicity
• Verify reconfiguration
procedures (Nuno Gaspar)
• Safe adaptation procedures
as a solid ground for
autonomic applications
• Some directions:
 Parameterized topologies: ADL[N] ; behavioural
specification (pNets) ; reconfiguration primitives
(Alexandra Savu)
 Use of theorem proving + prove equivalence between the
Isabelle GCM model and the behavioural specification
prove and use generic properties of
reconfiguration procedures
35
Correct component reconfiguration
Towards safety and autonomicity
• Verify reconfiguration
procedures (Nuno Gaspar)
• Safe adaptation procedures
[N]
as a solid ground for
autonomic applications
• Some directions:
 Parameterized topologies: ADL[N] ; behavioural
specification (pNets) ; reconfiguration primitives
(Alexandra Savu)
 Use of theorem proving + prove equivalence between
the Isabelle GCM model and the behavioural
specification
prove and use generic properties of
reconfiguration procedures
36
Multi-active objects
• Mono-threaded active objects have limitations:
 Deadlocks
 Inadapted to multicore architecture (no shared
memory)
• Solutions in the active-object community:
 Jcobox: « cooperative multithreading », only one
thread active at a time (release points)
 JAC: Java annotations for Concurrency – real
multithreading, not distributed
• Our proposal, a programming model that mixes local
parallelism and distribution with high-level programming
constructs
Adapting Active Objects to Multicore Architectures Ludovic Henrio, Fabrice Huet, Zsolt István, and Gheorghen Sebestyén - ISPDC 2011
37
Primitive GCM Component
foo() {
…
CI.foo(p)
}
38
Primitive Multi-Active GCM Component
Provided add, add and monitor are compatible
add() {
CI.foo(p)
}
add() {
…
…}
monitor()
{…
…}
39
Proposal – Annotation Example
Groups
(Collection of related
methods)
Rules
(Compatibility relationships
between groups)
Memberships
(To which group each
method belongs)
40
Results / Status
•
•
•
•
•
Implemented multi-active objects above ProActive
Added dynamic compatibility rules
Used on case studies (NAS, CAN)
Specified the semantics of Multi-ASP
Proved first properties, i.e., the semantics guarantees
that two requests executed in parallel are compatible
• Next steps:
 Publish the model
 Formalisation in Isabelle/HOL
 Use the new model
 Prove stronger properties (confluence?)
41
CAN dissemination algorithm
(Francesco Bongiovani)
• CANs are P2P networks organised in a cartesian space of
N-dimensions (used for RDF data-storage)
• Objective: disseminate efficiently information (no duplicate)
• Designed an efficient algorithm (tested)
• Proved the existence of an
K
E
G
efficient broadcast in Isabelle
Next steps:
D
C
• Prove the designed algorithm
F
H
is efficient
A
• Conduct large-scale
experiments
B
I
J
• Study churns
Mechanical Support for Efficient Dissemination
on the CAN Overlay Network - Francesco Bongiovanni, and Ludovic Henrio - CFSE 2011
42
What I could not fit in this talk
• ASP: Active object calculus
• ASPfun a functional variant formalised in Isabelle (typing)
• Fault tolerance (Christian Delbé) and garbage collection
(Guillame Chazarain) for active objects
• Work on behavioural skeletons (typing and exceptions)
(Mario Leyton)
• JDC: a language for specifying behaviour of components
(Antonio Cansado)
• Details on the behavioural specification of components
and active objects (first-class futures, …)
And of course, a lot of inference rules and greek letters …
43
THANK YOU !
Special thanks to the people I worked with, mainly:
Florian Kammueller
Marcela Rivera
Zsolt Istvan
Boutheina Bannour
Tomas Barros
Fabrice Huet
Muhammad Khan
Christian Delbé
Francesco Bongiovani
Françoise Baude
Guillaume Chazarain
Bernard Serpette
Mario Leyton
Denis Caromel
Paul Naoumenko
Antonio Cansado
Rabéa Boulifa
Eric Madelaine
CoreGrid partners
And others !!!
44
45
Primitive Components in Isabelle
• Primitive components are defined by interfaces plus an
internal behaviour, they can:
 emit requests
 serve requests
 send results
 receive results (at any time)
 do internal actions
some rules define a
correct behaviour,
e.g. one can only send result for a served request
• We define the behaviour of the whole components as
small-step operational semantics
A Framework for Reasoning on Component Composition
Ludovic Henrio, Florian Kammüller, and Muhammad Uzair Khan - FMCO 2009, Springer
46
Non-functional Component Structure
• Non-functional aspects as a composition of components
(inside a membrane)
 A component structure for the membrane
 New kind of interfaces and bindings
 An API for reconfiguring
the membrane
 Non-functional code is


components or objects
distributed or not
• Towards autonomic
components
A Component Platform for Experimenting with Autonomic Composition
Françoise Baude, Ludovic Henrio, and Paul Naoumenko. Autonomics 2007.
47
Triggering Distributed Reconfigurations in the
Scripting Language
• Fscript is a language to reconfigure Fractal components
• A primitive for the distributed script interpretation
remote_call(target_component, action_name, parameters, ...);
• + other minor extensions
Reconfiguration interface
target_component
Interpreter
action(arguments)
48
Example
RC 2
definition action1
Reconfiguration
interface
...
remote_call(C2,’action2’)
remote_call(C11,’action11’)
remote_call(C12,’action12’)
Reconfiguration scripts
C2
...
definition action12
...
RC 1
remote_call(C121,’action121’)
...
Interpreter
RC 11
Membrane
RC 12
C11
RC 121
49
Example
RC 2
definition action1
Reconfiguration
interface
...
remote_call(C2,’action2’)
remote_call(C11,’action11’)
remote_call(C12,’action12’)
Reconfiguration scripts
C2
...
action1( )
definition action12
...
RC 1
remote_call(C121,’action121’)
...
Interpreter
RC 11
Membrane
RC 12
C11
RC 121
C121
C12
50
Example
RC 2
definition action1
Reconfiguration
interface
...
remote_call(C2,’action2’)
remote_call(C11,’action11’)
remote_call(C12,’action12’)
Reconfiguration scripts
C2
...
action1( )
action2( )
definition action12
...
RC 1
remote_call(C121,’action121’)
...
Interpreter
action11( )
Membrane
action12( )
11
The reconfiguration script is RC
executed
inRC
a 12
parallel and
distributed manner
C11
RC 121
 This language is the basis of the GCM-scriptC121
language
C12
C1
A Reconfiguration Framework for Distributed Components
Marcela Rivera, Ludovic Henrio and Boutheina Bannour. SINTER Workshop 2009
51
Can we do more dynamicity?
a
g
• YES: ProActive/ASP!
• Active objects:
 newActive
 Reference to active objects passed as request
parameters or replies
• What formal models/properties
 ASP(old): confluence and determinacy (POPL 2004, I&C)




future updates can occur at any time,
execution uniquely characterised by the order of request senders
Fault tolerance (Europar’05, PPoPP’07)
ASPfun: in Isabelle/HOL, typed, proved progress, studied
binder representations (SCP 2011)
Behavioural specification: possible but much more
restricted (need strong static analysis)
52
GCM Formalisation in Isabelle
•
> 4000 lines, mostly proofs (do not read the proofs!)
•
Almost 300 lemmas and theorems,
•
~ 500 lines definitions: component model and semantics
•
1800 lines for future update specific properties
• A few tricky design choices (lists vs sets, how to store
names, …)
• A couple of axioms remaining (reduction correctness)
short-term goal: correctness of various strategies
Longer term: reconfiguration and execution
53
Support Constructs and Lemmas
• Operators to manipulate components inside
hierarchies

E.g., Traverse hierarchy: find/replace,
(recursive) set of subcomponents: cpSet
• To manipulate states

Retrieve referenced futures, all computed results, etc
• Properties on component structure

“Well-defined” and “correct” Components
• Support lemmas, e.g.
54
Component re-configuration
• Transformation of component structure or
content at runtime



Two reconfiguration primitives formalised (remove
and replace)
Illustrates the flexibility of the approach
Basic properties on reconfiguration primitives
Ludovic Henrio, Florian Kammüller, and Muhammad Uzair Khan
A Framework for Reasoning on Component Composition - FMCO 2009, Springer (2010)
55
Eager forward-based strategy
• A strategy avoiding to store future values indefinitely
• Future updates follow the same path as future flow
• Each component remembers only the components to
which it forwarded the future
Results sent as soon as available
No additional message
Future updates form a chain  intermediate components
Easy to garbage collect computed results
56
GCM-like Component with Eager-home
57
Composite Component Semantics –
CommChild
58
What is a Future?
• Future = Placeholder for an awaited result
• Creation of a future
 How and when are futures created?


Implicit creation = automatic upon asynchronous
invocation (on a remote object)
Explicit creation = there is a future construct
• Manipulation and access
 How to manipulate the futures?


Explicit access = get operation (+ future type)
Implicit (transparent) access = any variable can
contain a future
59