formalism and platform for autonomous distributed components bio-inspired networks and services a...
TRANSCRIPT
Formalism and Platform for Autonomous Distributed Components
• Bio-inspired Networks and Services• A Distributed Component Model• Formalisation in Isabelle• Autonomous components:
Componentise component management and distributed reconfiguration
BioNets project - Ludovic Henrio
FMCO 20091
• Autonomic Composition of Services in the context of autonomic communications: Discovery space fully open, Runtime support only locally on the device
• Which software component model: structured, hierarchical, and distributed Strong encapsulation, raising the level of abstraction clear separation between functional and non-functional concerns strong support for autonomic programming
We chose the Grid Component Model
Autonomicity in Communication systems
Autonomicity in Distributed Components
Autonomic composition Structured programming
2
ReQuest
ReQuest
ReQuest
ReQuest
ReQuest
ReQuest Reply
ReQuest
BIONETS Service Discovery, Execution, Evaluation, Evolution, Depreciation
Global behaviour:comes from the
large number of mobile
devices(statistical behavior)
Bio-inspired (genetic, chemical computing) evolutionBut also socio-economic model,evolutionary multi-players game theory, swarm intelligence
3
ReQuest
ReQuest
ReQuest
Reply
Reply
ReQuest
ReQuest
ReQuest Reply
Reply
ReQuest
ReQuest
BIONETS Service Discovery, Execution, Evaluation, Evolution, Depreciation
Global behaviour:comes from the
large number of mobile
devices(statistical behavior)
Bio-inspired (genetic, chemical computing) evolutionBut also socio-economic model,evolutionary multi-players game theory, swarm intelligence
4
ReQuest
Repl
ReQuest
ReQuest
Reply
Reply
ReQuest
ReQuest
ReQuest Reply
Reply
ReQuest
ReQuest
BIONETS Service Discovery, Execution, Evaluation, Evolution, Depreciation
Rewardmark
Fitness
Global behaviour:comes from the
large number of mobile
devices(statistical behavior)
Bio-inspired (genetic, chemical computing) evolutionBut also socio-economic model,evolutionary multi-players game theory, swarm intelligence
5
A DISTRIBUTED COMPONENT MODEL
6
What are (GCM) Components?
Bindings
Business code
Business code
Server interfaces
ClientinterfacesPrimitive component
Primitive component
Composite component
NF (server) interfaces
7
NB: interface = port
A Primitive GCM Component
CI.foo(p)
Primitive components communicating by asynchronous remote method invocations on interfaces (requests)
Components abstract away distribution and concurrency
in ProActive components are mono-threaded simplifies concurrency but can create deadlocks
Primitive components communicating by asynchronous remote method invocations on interfaces (requests)
Components abstract away distribution and concurrency
in ProActive components are mono-threaded simplifies concurrency but can create deadlocks
8
CI
Composition in GCM
Bindings:Requests = Asynchronous method invocations
9
Futures for Components
f=CI.foo(p)……….f.bar()f.bar()
Component are independent entities (threads are isolated in a component)
+Asynchronous method invocations with results
Futures are necessary
Component are independent entities (threads are isolated in a component)
+Asynchronous method invocations with results
Futures are necessary
10
Approach: a refined GCM model
• A model: more precise than GCM, give a semantics to the model:
future / requests request queues no shared memory between components notion of request service
less precise than ProActive/GCM can be multithreaded no “active object” model
12
FORMALISATION
13
Objectives
• A model general enough to study GCM, but also other component models interacting by requests
• In a theorem prover (Isabelle)• To study
the GCM component model, its implementation(s), interaction between futures and components, component reconfiguration and management
14
Principles
• component architecture: bindings interfaces (only functional) component composition
• communications by requests and futures request queues future references
• abstraction of the business code by a behaviour (~LTS)• values abstracted away: we just keep track of future
references
15
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• We define the behaviour of the whole components as small-
step operational semantics
16
Composite Components
• Composite components are defined by their interfaces + content + bindings
• Semantics Composites also have request queues (futures) Only delegate calls to inner or outer components Use the bindings to know
where to transmit requests Plus receive futures
(like primitives)
17
Future Update Strategies
• How to bring future values to components that need them• Different strategies can be envisioned• A “naive” approach: Any component can receive a value for
a future reference it holds. Not much operational.• More operational is the lazy approach:
18
require future value
Eager home future update
• A strategy avoiding to store future values indefinitely• Relies on future registration and sends the value as soon
as it is calculated
19
register future
register future
First Proofs (ongoing)
• Future update remove all references to a given future
• All Future references are registered during reduction
20
A formalisation in Isabelle of Component structure + request / futures
Middle-term goal: correctness of various strategies
A PLATFORM FOR AUTONOMOUS COMPONENTS
21
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
22
Adaptation in the GCM
• Functional adaptation: adapt the architecture + behaviour of the application to new requirements/objectives add a new functionality
• Non-functional adaptation: adapt the architecture of the container+middleware to changing environment/NF requirements (QoS …) Change communication protocol Update security policy …
23
Both functional and non-functional adaptation are expressed as reconfigurations
How to express reconfigurations?
We start from FScript:
• A Scripting reconfiguration language
• Dedicated to Fractal components
• FPath expressions: navigate and select elements in the components architecture
• Centralized execution
24
A Controller for Reconfigurations
• Manages and allows the invocation of the script interpreter
• Is collocated with the component
• Exposes methods for reconfiguration setInterpreter(interpreterClassName)
loadScript(scriptFileName)
executeAction(actionName, arguments...)
Reconfiguration interface
Interpreter
Membrane
25
Triggering Distributed Reconfigurations in the Scripting Language
A primitive for the distributed script interpretation
Triggers the action action_name by the interpreter located in target_component
Receives action arguments as parameterReconfiguration interface
action(arguments)
Inte
rpre
ter
target_component
remote_call(target_component, action_name, parameters, ...);
26
definition action1
...
remote_call(C2,’action2’)
remote_call(C11,’action11’)
remote_call(C12,’action12’)
...
definition action12
...
remote_call(C121,’action121’)
... Interpreter Membrane
C2
RC 1
RC 12
RC 121
RC 2
RC 11
Reconfiguration scripts
C11
ExampleReconfiguration interface
27
definition action1
...
remote_call(C2,’action2’)
remote_call(C11,’action11’)
remote_call(C12,’action12’)
...
definition action12
...
remote_call(C121,’action121’)
... Interpreter
RC 1
RC 12
RC 121
RC 2
RC 11
C121
C11
C12
Example
action1( )
Reconfiguration interface
Membrane
C2Reconfiguration scripts
28
definition action1
...
remote_call(C2,’action2’)
remote_call(C11,’action11’)
remote_call(C12,’action12’)
...
definition action12
...
remote_call(C121,’action121’)
... Interpreter
RC 1
RC 12
RC 121
RC 2
RC 11
C121
C11
C1
C12
Example
action1( )
action11( )
action2( )
action12( )
Reconfiguration interface
Membrane
C2Reconfiguration scripts
29
definition action1
...
remote_call(C2,’action2’)
remote_call(C11,’action11’)
remote_call(C12,’action12’)
...
definition action12
...
remote_call(C121,’action121’)
... Interpreter
RC 1
RC 12
RC 121
RC 2
RC 11
C121
C11
C1
C12
Example
action1( )
action11( )
action2( )
action12( )
action121( )
Reconfiguration interface
Membrane
C2Reconfiguration scripts
30
definition action1
...
remote_call(C2,’action2’)
remote_call(C11,’action11’)
remote_call(C12,’action12’)
...
definition action12
...
remote_call(C121,’action121’)
... Interpreter
RC 1
RC 12
RC 121
RC 2
RC 11
C121
C11
C12
Example
action1( )
action11( )
action2( )
action12( )
action121( )
The interpretation is parallel and distributed
Reconfiguration interface
Membrane
C2Reconfiguration scripts
31
Conclusion
• A component model for adaptive autonomous components structured membrane distributed reconfiguration
• A platform supporting adaptation and distribution based on ProActive (active objects, distribution) ADL (membrane and business code composition)
• A formalisation to study the component model and its implementation toward verification of component management
procedures
32
Ongoing and Future Works
• Formalisation is a long process:
For the moment, more a formal specification + a few proofs than a complete verification environment
• Verification of (re)configuration procedures by model checking Complementary with Theorem proving approach
application specific vs. model properties Already model generation relies on ASP properties
33
34
35
The deployment is always successful
[ (not √ )* ] < true * .√ > true
But Error during deployment
[ (not √ ) * . OE ] false
Verification of Properties: Deployment
start Buffer without linking the alarm interface
Eric MADELAINE ---- OASIS
36
• Deployment • (on the Static Automaton with successful
synchronisation visible) The deployment is always successful
[ (not √ )* ] < true * .√ > true No Error during deployment
[ (not √ ) * . OE ] false
Verification of Properties regular μ-calculus (Mateescu’2004)
e.g. start Buffer without linking the alarm interface
Eric MADELAINE ---- OASIS
37
• Functional properties under reconfiguration (respecting the topology) Future update (asynchronous result messages)
independent of life-cycle or binding reconfigurations Build a model including life-cycle controllers,
with the reconfiguration actions visible:
Then we can prove:
Verification of Properties
[ true*.Req_Get() ] X. (< true > true [Resp_Get() ] X )
Example
• Add the component given_child to the composite given_parent
given_parent
given_child
given_parent
remote_call($given_parent, ‘add’, ‘$given_parent’, ‘given_child’);
38
GCM API for Reconfiguration
• Life-cycle controller
• Binding controller
• Content Controller
string getFcState ();void startFc () throws IllegalLifeCycleException;void stopFc () throws IllegalLifeCycleException;
string[] listFc ();any lookupFc (string clientItfName) throws NoSuchInterfaceException;void bindFc (string clientItfName, any serverItf) throws . . .void unbindFc (string clientItfName) throws. . .
any[] getFcInternalInterfaces ();any getFcInternalInterface (string itfName) throws . . . Component[] getFcSubComponents ();void addFcSubComponent (Component c) throws . . .void removeFcSubComponent (Component c) throws . . .
39