1 / 18

Refining middleware functions for verification purpose

Refining middleware functions for verification purpose. Jérôme Hugues (hugues@enst.fr) Laurent Pautet (pautet@enst.fr) Fabrice Kordon (Fabrice.Kordon@lip6.fr). Distribution middleware (MW). Multiple dimensions Domains: avionics, space, transportation Families: reliability, integrity

britanni-lowe
Download Presentation

Refining middleware functions for verification purpose

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Refining middleware functions for verification purpose Jérôme Hugues(hugues@enst.fr) Laurent Pautet(pautet@enst.fr) Fabrice Kordon(Fabrice.Kordon@lip6.fr)

  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 Refining 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) ? • Reduce MW components scope • Define MW component connectors • Define a MW architecture to ease verification Refining 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 Refining 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%) Refining 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 Refining 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) Refining middleware functions for verification purpose

  8. AWS (WEB) Application personalities CORBA (DOC) DSA (RPC) MOMA (MOM) Neutral Core Middleware Key MW mechanisms DIOP (UDP) Protocol personalities SOAP (XML) IIOP (TCP) MIOP (multicast) Schizophrenic MW: collocating and interacting personalities • Neutral core MW: • MW mechanisms as generic components • ensures high code reuse ratio Refining 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 Transport Addressing Binding Protocol Representation Activation Execution Broker Refining middleware functions for verification purpose

  10. How to model the broker ? • Combination of 2 “modeling facilities” • To catch broker behavior • and then to detail it for verification • One high-level model • Descriptive & easy to manipulate • One lower-level model • Enable formal verification Refining 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 !! Refining middleware functions for verification purpose

  12. Refining broker: mBroker (1/2) • Reduce broker to generic abstractions • Express interactions with core services Addressing Activation mBroker Binding Protocol Refining middleware functions for verification purpose

  13. Refining broker: mBroker (2/2) • Introduce simpler abstractions • Notionally equivalent to broker pattern Addressing Activation mBroker Job Queues Binding Protocol Async. I/O Async. I/O Scheduler Refining middleware functions for verification purpose

  14. How to verify the mBroker ? • Specification of the mBroker • 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 <C, C>; Var x, y in C; Refining 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 Refining 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 Refining 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 Neutral Core MW Instances Not verified Not verified Genericity Verified Verified Configurability Refining 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 enableverification • 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 ? Refining middleware functions for verification purpose

More Related