Behavioural Models for Distributed Hierarchical Components Tomás Barros, Ludovic Henrio and Eric Madelaine INRIA Sophia Antipolis OASIS project Monday, September 26th, 2005 FIACRE Grenoble

Plan Components/Fractal Fractive Behavioural models ProActive based Fractal Behavioural models Properties verification Monday, September 26th, 2005 FIACRE Grenoble

Component base programming Component = software unit, deployment unit Industrial acceptance : EJBs, CCM, COM … 3 key concepts : 1. Encapsulation Black boxes, offered and required services, configuration 2. Composition Design of complex systems Hierarchical organization into sub-systems 3. Separate administration ADL Tools HIGH ABSTRACTION LEVEL COMPLEXITY HANDLING REUSABILITY CUSTOMIZATION Monday, September 26th, 2005 FIACRE Grenoble

Fractal’s Components Primitive/Composite LIFE CYCLE BINDING CONTENT ATTRIBUTE Content Primitive/Composite Optional non-functional interfaces Membrane, internal and external interfaces Fractal semantics (e.g binding only when stopped) Monday, September 26th, 2005 FIACRE Grenoble

Component Behaviour Temporal Phases Deployment Definition of its content and initial binds Usually defined in an ADL Running Only functional operations Reconfiguration Structural and non-structural changes Monday, September 26th, 2005 FIACRE Grenoble

Fractal example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE .... > <definition name="components.System"> <component name="BufferSystem" definition="components.BufferSystem(3)"> <interface name="alarm" role="client" signature="components.AlarmInterface"/> </component> <component name="Alarm"> <interface name="alarm" role="server" <content class="components.Alarm"> <behaviour file="AlarmBehav" format="FC2Param"/> </content> <binding client="BufferSystem.alarm" server="Alarm.alarm"/> </definition> Monday, September 26th, 2005 FIACRE Grenoble

Fractive’s components Fractal Implementation using ProActive Fractal features: Hierarchical components ADL description (Fractal’s XML Schema/DTD) Proactive features: Distributed components (from distributed objects) Asynchronous communication Monday, September 26th, 2005 FIACRE Grenoble

ProActive’s middleware Provides active and passive (standard) Java objects Remote (transparent) references to active objects Deep copy of parameters in method’s calls and responses. No shared objects Only Active objects may be references Monday, September 26th, 2005 FIACRE Grenoble

Active Objects Have their own and unique thread Have request queue, where method’s calls are dropped (rendez-vous phase) User define policies for serving methods from the queue by overloading the method RunActive (default FIFO) Non blocking responses by giving a “future” reference. Synchronisation wait-by-necessity Monday, September 26th, 2005 FIACRE Grenoble

Active Objects communications Monday, September 26th, 2005 FIACRE Grenoble

Active Objects communications Blocking of access f Monday, September 26th, 2005 FIACRE Grenoble

Active Objects communications Monday, September 26th, 2005 FIACRE Grenoble

Active Objects communications Monday, September 26th, 2005 FIACRE Grenoble

Fractive implementation Primitive component => Active object Composite membrane => Active object Primitive’s active object are reify Forwarder for functional calls Monday, September 26th, 2005 FIACRE Grenoble

Fractive’s implementation choices Hierarchical start/stop While stopped only non-functional request are served. No path between functional and non-functional interfaces Monday, September 26th, 2005 FIACRE Grenoble

Behaviour: Parameterized Networks Parameterized LTS (pLTS) & Synchronisation Network (pNet) Guarded actions with parameters Parameters encoding value and process reference passing Parameters encoding family of processes parameterized synchronisation vectors pAg <- [*, *, a3(k3), *, a4(k4), *] Instantiation : for a finite abstraction of the parameters domains Dv Finite Network pLTS x Dv  LTS pNet x Dv  Net T. Barros, R. Boulifa, E. Madelaine: Parameterized Models for Distributed Java Objects, Forte'2004 Conference, Madrid, Sep. 2004, LNCS 3235, © Springer-Verlag Monday, September 26th, 2005 FIACRE Grenoble

Fractive Behavioural Models Functional behaviour is known Given by the user Obtained by static analysis Non functional behaviour is automatically added from the component’s ADL Automata within a synchronisation network, named controller Component’s behaviour is the controller’s synchronisation product Monday, September 26th, 2005 FIACRE Grenoble

Fractive Behavioural Models Visible actions and errors Monday, September 26th, 2005 FIACRE Grenoble

Previous work: ProActive behavioural models (presented at Forte 2002) T. Barros, R. Boulifa, E. Madelaine: Parameterized Models for Distributed Java Objects, Forte'2004 Conference, Madrid, Sep. 2004, LNCS 3235, © Springer-Verlag Monday, September 26th, 2005 FIACRE Grenoble

Fractive primitives Body is the functional behaviour Monday, September 26th, 2005 FIACRE Grenoble

Fractive composites Automatically generated Future update in chain Monday, September 26th, 2005 FIACRE Grenoble

Static Automaton Deployment Automaton Static is also the sub-component’s behaviour for the next level of the hierarchy Static = ( Controller || Deployment ) + hiding & minimisation Monday, September 26th, 2005 FIACRE Grenoble

Behaviour correctness (from the user point of view) Initial Composition Requirements expressed as temporal formulas Respect a SPEC Reconfiguration New properties (features) Preservation Monday, September 26th, 2005 FIACRE Grenoble

Properties Verification (ACTL) Deployment (on controller||deployment with successful synchronisation visible) The deployment is always successful Error absence during deployment e.g. to start Buffer without linking alarm Monday, September 26th, 2005 FIACRE Grenoble

Properties Verification (regular -calculus) Effective start (due to asynchronisms) [ true*.Sig(start(System))] true  [ true*. Sig(start(BufferSystem))] true  [ true*.Sig(start(Alarm))] true  [ true*.Sig(start(Buffer))] true  [ true*.Sig(start(Consumer))] true  [ true*.Sig(start(Producer))] true Monday, September 26th, 2005 FIACRE Grenoble

Properties Verification (regular -calculus) Funtional behaviour (on the static automaton) Get from the buffer eventually gives an answer [ true*.get_req() ] X. (< true > true  [get_rep() ] X ) Monday, September 26th, 2005 FIACRE Grenoble

Properties Verification (regular -calculus) Functional under reconfiguration reconfiguration actions are allowed after deployment Monday, September 26th, 2005 FIACRE Grenoble

Properties Verification (regular -calculus) Functional under reconfiguration Future update (once the method served) independent of life-cicle or bindins reconfigurations E.g: Enabling: [ true*.get_req() ] X. (< true > true  [get_rep() ] X ) Monday, September 26th, 2005 FIACRE Grenoble

Structural Transformations Controller of the new structure Action mapping Identify states in the original controller where transformation is possible (set T) “Connect” both controllers from T through the transformation  (T’ is the image of ) The new behaviour is the reachable parts from T’ (using the action mapping) Monday, September 26th, 2005 FIACRE Grenoble

Synchronous former example B2 Structural transformations No errors during functional phase Monday, September 26th, 2005 FIACRE Grenoble

Conclusions Automatic construction of behaviour for distributed hierarchical models (including errors) Taking into account functional and no-functional aspects Reconfigurations and asynchronism Verification of properties in different phases Implementation of a prototype tool (Java) for model construction. CADP toolset for composition and verification of properties Monday, September 26th, 2005 FIACRE Grenoble

Related Work Wright Darwin Sofa Behavioural Contracts (Carrez et al.) Connectors specified using CSP Compatibility relation (modify CSP refinement) Darwin LTS specifications, construction by parallel composition, hiding and weak bisimulation reduction Properties expressed through LTS and Büchi automata Sofa Frame (spec) vs. Architecture (implementation) compliance relation based on traces Hierarchical construction through parallel composition detection of errors: bad activity, no activity and divergence Behavioural Contracts (Carrez et al.) Behavioural typing (CSP like specification) Interface behavioural-type compatibility (decidable) and components contract compliance (non decidable). Monday, September 26th, 2005 FIACRE Grenoble