Modelling Dynamic Component Dependencies

0 downloads 0 Views 142KB Size Report
This paper is about modelling dynamic dependencies of com- ponents as ... with ∀〈a,b〉∈M ul(b = ∗ ∨ a ≤ b) ... In the following, we will model dependencies ... Dependency Precedence (preexp : Dep Exp): If the number of components.
Modelling Dynamic Component Dependencies Siamak Haschemi and Daniel A. Sadilek Humboldt-Universit¨ at zu Berlin, Institut f¨ ur Informatik Unter den Linden 6, 10099 Berlin, Germany {haschemi|sadilek}@informatik.hu-berlin.de

Abstract. This paper is about modelling dynamic dependencies of components as required in dynamic environments. We sketch a formal model for describing the dependencies of software components on hardware and other software components. In a unified way, we represent software components and hardware components with their properties. The properties can be changed during runtime. Expressions over properties define component dependencies, which are steadily resolved to deal with dynamics.

1

Introduction

This paper is concerned with software components that operate in dynamic environments. Such a dynamic environment is, for example, a wireless mesh network where the topology fluctuates and hardware can fail [1]. A software component can depend on hardware and other software components. Consider, for example, a software component that should only run at a certain minimum current of a battery. If such a dependency fails, the software component should be stopped. This may trigger to stop further software components. If the battery gets recharged, the software components should be started again. Dynamic dependencies like these cannot be explicitly described in the “standard” component models, such as JavaBeans, J2EE, COM, or CCM. Instead, they must be handled programatically. In the OSGi community, there are a couple of frameworks with a declarative language for dynamic dependency description and runtime composition [2, 3]. But they are tightly coupled to the OSGi specification. In this paper, we present a simple, formal, platform independent model for explicitly describing dynamic component dependencies. The model’s purpose is to decide at runtime which software components can be started. We regard as components both software components and hardware components, such as the battery. To describe dependencies, we assign properties to components and use them in dependency expressions. If all dependencies of a component can be resolved, it can be started. The properties can be changed during runtime. Therefore, in an implementation of our model, the dependencies must be continuously resolved.

A = unicode characters Identif ier = [A-Za-z][A-Za-z0-9]∗ K = Identif ier V = A∗ ∪ Z M ul = Z+ × (Z+ ∪ {∗}) lowerbound : M ul → Z+ upperbound : M ul → Z+ ∪ {∗} with ∀ha,bi∈M ul (b = ∗ ∨ a ≤ b)

(characters) (identifiers) (property keys) (property values) (dependency multiplicities) (multiplicity lower bound) (multiplicity upper bound)

N ame = Identif ier Exp evale : Exp × C × C → {true, f alse} Dep = N ames × M ul × Exp × Exp name : Dep → N ame mul : Dep → M ul depexp : Dep → Exp preexp : Dep → Exp C φ:C×K →V δ ⊆ C × Dep

(component names) (expressions, cf. Fig. 2) (expression evaluation, cf. Fig. 3) (dependencies) (dependency name) (dependency multiplicity) (dependency expression) (dependency precedence expr.) (components) (component properties) (component dependencies)

Fig. 1. Mathematical framework for describing components. Exp ::= | | BoolBinOp ::= V alueBinOp ::= V alueExp ::= T hisP rop ::= OtherP rop ::=

Exp BoolBinOp Exp ‘!’ Exp | ‘(’ Exp ‘)’ V alueExp V alueBinOp V alueExp ‘&’ | ‘|’ | ‘→’ ‘=’ | ‘>’ | ‘≥’ | ‘’, ‘≥’, ‘