Refining middleware functions for verification purpose Jérôme Hugues, Laurent Pautet {hugues, pautet}@enst.fr École Nationale Supérieure des Télécommunications CS & Networks Department 46, rue Barrault F-75634 Paris CEDEX 13, France Fabrice Kordon Fabrice.Kordon@lip6.fr Laboratoire d’Informatique de Paris 6/SRC Université Pierre & Marie Curie 4, place Jussieu F-75252 Paris CEDEX 05, France Abstract— The development of real-time, dependable or scal- able distributed applications requires specific middleware that enables the formal verification of domain-specific properties. So far, typical middleware implementations do not directly address these issues. They focus on patterns and frameworks to meet application-specific requirements. Patterns propose a high-level methodology adapted to the description of software components. However, their semantics does not clearly address verification of static or run-time properties. Such issues can be addressed by other formalisms, at the cost of a more refined description. In this paper, we present our current effort to combine both patterns and Petri Nets to refine and then to verify middleware. Our contribution details steps to build Petri Net models from the Broker architectural pattern. This provides a model of middleware and is a first step towards formal middleware verification. I. I SSUES IN MIDDLEWARE DEVELOPMENT Distribution middleware provides description methods, ser- vices and guidelines to ease the development of distributed applications. Middleware specifications describe the seman- tics and runtime supports for distribution. Successful implementations of solutions such as CORBA, Java Message Service (JMS) or SOAP demonstrate that distributed applications require very different distribution models: Remote Procedure Call (RPC), Distributed Objects Computing (DOC), Message Passing (MP) or Distributed Shared Memory (DSM). Besides, there is a rising demand for a wider range of runtime and platform support: embedded, mobile, real-time, multimedia, etc. These new criteria increase complexity in both middleware development and use. Middleware imple- mentations should be versatile enough to handle different (and potentially antagonist) platform requirements; applica- tion must abide to complex middleware semantics. Current middleware implementations rely on patterns to enable configurability and then to meet user requirements for one specific distribution model. Architectural and design pat- terns are introduced to describe specific solution to recurrent design problems (request demultiplexing, buffers allocations, concurrent execution, etc). Middleware is described by means of a language pattern that weaves together a set of related pat- terns. This approach proved its efficiency in various industrial projects [SB03]. Hence, the combination of patterns provides a high-level description of middleware. Yet, weak pattern descriptions may lead to slightly different implementations or implementations that interleave different patterns concerns. This impedes implementations verification. Moreover, patterns are only descriptive. They do not provide any verification guidelines. Thus, implementations rely only on simple verification methods to verify behavioral- only properties: the use of some middleware functions and the execution of predefined test cases. But this approach lacks generality: it can only test a restricted subset of the infrastructure properties. As middleware use evolves toward real-time and de- pendable applications, there is a strong need for formal verification of middleware with respect to explicitly defined properties. Yet, verification process is a complex task. The choice of a verification mechanisms is thus significant. In the remainder of this paper, we detail our current effort on middleware verification. We focus on remote invocation models (RPC, DOC or MP) and exclude DSM. We present a middleware typical architecture, built around the Broker architectural pattern and show limits that prevent verification. Then we introduce our work to fill this gap and detail the modeling notations and process we use to verify the Broker. We also detail our specific middleware architecture, implemented by PolyORB 1 and demonstrate how separation of concerns eases verification. Then we explain how we refine the Broker and detail how to formally verify it. II. BROKER: A KEY MIDDLEWARE PATTERN Basically, middleware provides mechanisms to enable transparent interaction between application nodes using mes- sages. Reception of a message triggers: 1) resources alloca- tion, 2) specific processing for the distribution model and then 3) execution of application-specific code. A response may be sent back to the message initiator, following the same path. The architectural pattern Broker provides a view of the components involved in this process. 1 http://libre.act-europe.fr/polyorb