AwareWare middleware consists of following modules: Awareness measurement tools, Awareness manger, Adaptation decision, and Reconfiguration. Awareness measurement tools measure networks, devices, end-users, applications, and environments. Awareness manger organizes these tools and provides query interface for adaptive applications. Decision engine takes awareness and adaptation tactics as input and initiates dynamic reconfiguration commands to the application. The adaptation decision is driven by a XML script file written by application developers or end-users in an adaptation policy language. The adaptation policy defines the rules that the adaptation decision module could initiate adaptation, by changing the application¡¯s component inter-connections or parameters.

Network-awareness: In heterogeneous environments, multiple devices may connect to each other via different network links, varying from high-speed LAN, dial-up, to wireless connection, where the characteristics of the network are different from each other. Even with a known network connection, dramatic network performance changes are often experienced during a particular communication session, especially in wireless networks. Bandwidth, latency, jitter etc. are commonly used to specify the network characteristics.

Device-awareness: The need for device-awareness lies in the fact that computing devices (e.g. PC, Palm) that host applications in heterogeneous environments may vary significantly in their device capacity parameters, namely CPU power, display size, memory size, display refresh rate etc. Devices are more diversified in pervasive computing, where different types of devices are interconnected.

User awareness: End user is one of the most dynamic factors in a computing environment, since they may have very different preferences for a single application.

Application awareness: Internal states of the local and remote applications can also affect the adaptation. Adaptation middleware needs to exchange the shared internal states across the network.

Environment awareness: Physical environment can be measured by sensor networks. For example, a sensor network consists of many sensor devices that measure the environment, and communicate with each other through wireless link. Adaptation can then be triggered by external environmental events.

 Measurement tool selection module can select the user-required measurement tools based on the user-defined script file. Awareness manger organizes these tools, evaluates the awareness results based on composite events, and provides query interface for adaptive applications.

A composite event is a combination of multiple simple events. A simple event is specified as a triple: an awareness value collected from the measurement tool, a comparison operator, and condition value. A composite event is organized in a tree structure, as shown in the figures below.

AwareWare uses an adaptation policy language (XML) to describe adaptation tactics. The adaptation tactics are specific to the application. Thus the developer decides what awareness to use, when reconfiguration should be invoked, and how an adaptation tactic is expressed in terms of reconfiguration primitives.

The decision module is a virtual machine that interprets the adaptation tactic at run time. The reconfiguration primitives are used by the decision module to interact with components when making a configuration change; and these are standard primitives, not defined by system developers.

From an architectural view, adaptation can be seen as the reconfiguration of the system architecture with respect to environment changes. Dynamic reconfiguration is used in AwareWare as the basis of the adaptation. AwareWare controls applications which are configurations of components where the configuration adapts at runtime. Therefore an application consists of multiple reconfigurable components interacting with each other through connections.

An Architecture Description Language (ADL) contains the specification of required and provided interfaces for each component, and the interaction protocol between components. Several tools are also proposed to analyze the specification for correctness and automatically generate the configuration infrastructure. The configuration infrastructure manages instantiation and connection of components and enforces the specified configuration behavior at runtime.

We have implemented three different reconfiguration mechanisms, in C++, Java, and NesC:

(1) Dynamic reconfiguration for C/C++ DLL components

(2) Dynamic reconfiguration for CORBA component based applications

(3) Dynamic reconfiguration for Wireless Sensor Networks

(1) Local tree based geometric routing

(2) Efficent data compression in wireless sensor networks

(3) Firefighting applications using ad-hoc and wireless senor networks