Formal Modeling of a Generic Middleware to Ensure Invariant Properties * Xavier Renault 1 , J´ erˆ ome Hugues 2 , and Fabrice Kordon 1 1 Universit´ e Pierre & Marie Curie, Laboratoire d’Informatique de Paris 6/MoVe 4, place Jussieu, F-75252 Paris CEDEX 05, France xavier.renault@lip6.fr,fabrice.kordon@lip6.fr 2 GET-T´ el´ ecom Paris – LTCI-UMR 5141 CNRS 46, rue Barrault, F-75634 Paris CEDEX 13, France jerome.hugues@enst.fr Abstract. The complexity of middleware leads to complex Applica- tion Programming Interfaces (APIs) and semantics, supported by con- figurable components in the middleware. Those components are selected to provide the desired semantics. Yet, incorrect configuration can lead to faulty middleware executions, detected late in the development cycle. We use formals methods to tackle this problem. They allow us to find appropriate composition of middleware components and the use of their APIs, and to detect valid or faulty sequences. To provide reusable results, we modeled a canonical middleware architecture using Z. We propose a validation scenario to verify middleware’s invariants. We define invariants to exhibit inconsistent usage of these APIs. The speci- fication has been checked with the Z/EVES [13] theorem prover. 1 Introduction Middleware is now a central piece of many applications. Therefore, expectations about middleware reliability increase. To meet this goal, their architecture is being revisited, cleaned to exhibit structuring patterns. For example, TAO [12] or Zen [10] take advantage of Design Patterns to provide a safer design. Based on this architecture, the middleware can be tuned to operate dedicated policies (tasking management, memory allocation, etc.). Yet, these complex assemblies of design patterns has never been formally proved in an easy and efficient way. Thus, components interactions may lead to faulty configurations lately detected. A way to tackle this problem is to define and check invariants [5]. This is a way to express stability conditions on software components. For example, one can use OCL [9] to declare such invariants. Should the middleware architecture be formally specified and its invariants formally expressed, one can define use case scenarios to verify the system. We aim to model middleware’s components to ensure their composition. We specify invariants (e.g. array size of some internal structures, unicity of identifiers) for each component and check if they are verified for the selected assembly. * This work is funded in part by the ANR/RNTL Flex-eWare project.