A Specification Language for Distributed Components Implemented in GCM/ProActive

Abstract

This technical report is based on a component model for distributed components called GCM for Grid Component Model. We present here this component model, its reference implementation based on the Java middleware ProActive, our specification language JDC adapted to distributed components, and the associated specification platform: Vercors. Our aim is, from the specification of components and their behaviour, to be able to both verify properties of this behaviour and generate real GCM components.The OASIS team works in the area of distributed systems, with a stress on programming methodology and tools for computing grids. Analysing the behaviour of distributed systems always has been more difficult than for traditional systems, because of the complexity of temporal interactions between remote parts of the application. We base our programming model on active objects: each active object has its own (and unique) thread, processing asynchronous method calls on the object. This model is intended to ease the analysis of concurrency by clearly identifying entry points for communications and limiting the concurrency aspects to remote method calls on the same object. Moreover, structuring distributed systems using components is somewhat better, because it requires that interaction points (service points, but also required interfaces) are well defined. Additionally, having well-defined components boundaries reduces the amount of information that one component needs to have of its environment.The active object paradigm together with a distributed hierarchical component model provide convenient abstractions that help programmers understand the interactions between their different pieces of codes. Indeed in GCM/ProActive communication and concurrency is provided by asynchronous method calls between well-defined interfaces, and transparent channels transmitting the results of those calls.Unfortunately, developers still have to face non-trivial runtime incompatibilities when assembling off-the-shelf components. These incompatibilities arise due to the lack of a precise dynamic specification of the component behaviour (the protocols for inter-component communication Nonetheless, a much more precise, sound static compatibility check of bound interfaces can be achieved if behavioural information is added to the components. In such effort, we proposed in [3] to attach behaviour as part of the architecture specification, defined in terms of parameterized networks of transition systems. The compatibility between these behaviours could be checked using model-checkers as we did in [4]. In the same spirit, "behavior protocols" [5] and "component-interaction automata" [6] are ongoing research projects with similar goals. They both adopt a simpler model, for example the "behavior protocols" framework uses a simple regular-language to describe traces of the component behaviour (without data), while we are able to take into account an abstraction of the data-flow. A major originality of our work is that we target distributed component syste...

Verifying Protocol Conformance Using Software Model Checking for the Model-Driven Development of Embedded Systems

“…Given the fundamental significance of the interface notion, it is not surprising that many different research communities have tried to avail themselves of the benefits of behavioral interface specifications, including systems (e.g., [2]), programming languages (e.g., [3], [4], [5]), type theory (e.g., [6]), software architecture and component-based systems (e.g., [7], [8], [9]), multi-agent systems (MAS) (e.g., [10]), and service-oriented architecture and web services (e.g., [11]). In most of these approaches, behavioral constraints are expressed using finite state machines or related formalisms.…”

“…In the context of specifying and analyzing component-based systems and software architectures, the use of, for example, state machines (e.g., [4], [32]), sequence diagrams (e.g., [33]), and process algebra specifications (e.g., [34], [35], [8], [36]) has been suggested to enrich interface specifications. Many of these works have other goals and do not consider protocol conformance in the sense of Definition 5 (e.g., [34], [4], [32], [33]). Out of the ones that do, the work on "behavior protocols" seems most related [35].…”