Refining middleware functions for verification purpose Jérôme Hugues Laurent Pautet Fabrice Kordon

Jérôme HuguesRefining middleware functions for verification purpose 2 Distribution middleware (MW)  Multiple dimensions Domains: avionics, space, transportation Families: reliability, integrity  Application = f (Domains, Families) Different distribution requirements or needs Various facilities: DOC, RPC, MP, (D)SM Different models: CORBA, DSA, JMS  Middleware architectures that enable Customization Verification

Jérôme HuguesRefining middleware functions for verification purpose 3 Goal: build proof-based middleware  A priori: engineering process Guidelines for certification Restricted profiles: e.g. Ravenscar Modeling: MetaH, AADL  A posteriori: verification Modeling + formal methods and tools  How to handle variations (DxF space) ? 1.Reduce MW components scope 2.Define MW component connectors 3.Define a MW architecture to ease verification

Jérôme HuguesRefining middleware functions for verification purpose 4 Variations: configurability  Minor variations at deployment Communication channels OS, runtime or hardware capabilities Implementation of software components  Design patterns and frameworks are appropriate solutions at this level: one can choose the most adequate implementation for a specific component

Jérôme HuguesRefining middleware functions for verification purpose 5 Variations: genericity  Major variations in distribution facilities  Generic middleware: Single architecture Generic components + abstract interfaces  Personality: Instance of generic middleware for a given distribution model Built from a restricted set of general and specific components  Jonathan/Quarterware/ACT Increases code reusability, but limited (10-25%)

Jérôme HuguesRefining middleware functions for verification purpose 6 Beyond configurability & genericity  Several domains/families in one application Integrity, reliability,..  Heterogeneous distribution models in one application Redundant components => Large footprint Interacting components => Support for heterogeneity  Strong architecture and component requirements Aggressive code reuse Interoperable components => Neutral from distribution model  “Schizophrenic middleware” (extreme genericity) Collocating and interacting personalities

Jérôme HuguesRefining middleware functions for verification purpose 7 PolyORB: schizophrenic middleware  Developed in Ada, approx. 110 klocs  Configurability: component-level Well-known or new patterns Tasking profiles: no tasking, full tasking, Ravenscar  Genericity: architecture Separation of key middleware functions Functional implementation of CORBA, MOMA, DSA, AWS, SOAP, IIOP, MIOP Instantiations: 75% code from generic layer  Performance Compete with traditional middleware for similar setups Greater code reuse than generic middleware  Entered industrialization process Supported free software (Ada Core Technologies)

Jérôme HuguesRefining middleware functions for verification purpose 8 Neutral Core Middleware Key MW mechanisms Schizophrenic MW: collocating and interacting personalities  Neutral core MW: MW mechanisms as generic components ensures high code reuse ratio CORBA (DOC)DSA (RPC) AWS (WEB) MOMA (MOM) Application personalities SOAP (XML)IIOP (TCP) DIOP (UDP) MIOP (multicast) Protocol personalities

Jérôme HuguesRefining middleware functions for verification purpose 9 Refining MW functions for verification purpose  Neutral Core Middleware: 7 core functions Simple: finite state machines, data manipulators  Coordinated by a broker architectural component To be verified first ExecutionActivation BindingAddressing RepresentationProtocol Broker Transport

Jérôme HuguesRefining middleware functions for verification purpose 10 How to model the broker ?  Combination of 2 “modeling facilities” 1.To catch broker behavior 2.and then to detail it for verification  One high-level model Descriptive & easy to manipulate  One lower-level model Enable formal verification

Jérôme HuguesRefining middleware functions for verification purpose 11 How to describe the broker ?  Design patterns “Solutions for recurrent problems” Many patterns documented Typical solutions to design middleware  Well-known “broker” patterns Coordinate entities in distributed application Covers client, server, communication,.. Too large !!

Jérôme HuguesRefining middleware functions for verification purpose 12  Reduce broker to generic abstractions Express interactions with core services Refining broker: Broker (1/2)  Broker Addressing Binding Activation Protocol

Jérôme HuguesRefining middleware functions for verification purpose 13 Refining broker: Broker (2/2) Addressing Binding Activation Protocol Job Queues Async. I/O Scheduler  Introduce simpler abstractions  Notionally equivalent to broker pattern  Broker

Jérôme HuguesRefining middleware functions for verification purpose 14 How to verify the Broker ?  Specification of the Broker Driven by external events + parallelism  Modeled using Petri nets Structural methods Model checking CASE tools available Assembly-like Computable properties  Deadlocks, bounds  Execution paths class C is 1.. 2; Domain D is ; Var x, y in C;

Jérôme HuguesRefining middleware functions for verification purpose 15 Modeling steps  Define sub-models One per modeled function/entity Can be tested separately  Build complete model Composition of sub-models  Inherit some properties from sub-models Support for Broker verification  Scenarios Specific Petri nets to model external interactions  Incoming data, local user code

Jérôme HuguesRefining middleware functions for verification purpose 16 One model: Try_Check_Sources  Monitors I/O sources  #1: Poll on event sources ChckSrcB/ChckSrcE SigOut signals events  #2: Process I/O Under mutual exclusion Build jobs “event on s” Queue jobs for processing

Jérôme HuguesRefining middleware functions for verification purpose 17 Properties inheritance benefit  Instances inherit some properties from Neutral Core MW Enable verification of multiple instances.. at reduced cost Genericity Configurability Instances Neutral Core MW Verified Not verified

Jérôme HuguesRefining middleware functions for verification purpose 18 Conclusion  Requirements for new middleware Domain x Family space  Middleware personalization & verification  Flexible architecture that separate concerns Aggressive code configurability and genericity to enable verification  Are “schizophrenic” middleware one step forward in the good direction ? Configurability, genericity Prototyping of distribution middleware Formal verification of core components  Requirements from para-functional elements ?