MassWare (Mobile Ad-hoc and Sensor Systems' Middleware) is an extension of AwareWare to wireless mobile networks and sensor networks, where network and hardware resources are extremely constraint and dynamic. The MassWare mobile system can reduce the reconfiguration time in context-aware mobile environments. It is located between the lower hardware and network layer and the upper application layer to monitor environments and support application adaptation. MassWare is peer-to-peer middleware and there is one middleware agent per application in each host. There are five parts in each MARCHES agent: measurement tools, event sensors based on a hierarchical event model, a script parser based on XML, a decision engine, and a dynamic reconfigurator.

Measurement tools are the lowest building blocks that monitor the heterogeneous environments and report the environment awareness results as the contextual information to be processed by the event sensors.  The sensors and actuators, in addition to adaptation rules, are defined by application developers in a XML script file. There are two types of actuators, proactive and reactive ones. The XML script parser parses the script file and constructs the sensors and proactive actuators to process local data. The reactive actuators are constructed through a synchronization process with peer agents to process the received data. Once a context triggers an event sensor, a corresponding proactive actuator will be activated.

Components in MassWare are function independent composable units. The MassWare component is self-describing similar with the COM component. It contains a manifest of its metadata that describes what is in the component: identification information (name, version, etc.), a list of the types and resources, a list of classes and interfaces, and a map to connect public types with the implementing code. Therefore, MARCHES can runtime create component types and dynamically invoke component functions through reflection.

There are two types of MassWare components: reconfigurable computing components (named as masslets) and extensible measurement tool components (named as masstools). Both they provides some communication interfaces. 

Adaptation middleware uses the component-based metamodel to build adaptive applications; and thus the applications consist of a set of function-independent interacting components, which form a component chain (actuator). Existing adaptation middleware supports only one actuator(a). The actuator can be dynamically reconfigured via chain-structure modifications by the middleware according to the run-time contextual information so that the application can be adaptive to environment changes. However, applications requiring real-time services are intolerant of the long reconfiguration time of the existing adaptation middleware since each reconfiguration process includes operation suspension, buffer clearance, and chain-structure modifications that take seconds or even tens of seconds in total.

Differentiating from any existing middleware, MassWare supports multiple actuators in each distributed program of an application (b). Thus modifying the actuator in traditional middleware is replaced by switching active and inactive actuators in MassWare based on the active messages. This results in a dramatic reduction of the reconfiguration time by eliminating the operation suspension time and buffer clearance time.

Context awareness and measurement tools for adaptive applications has been studied in AwareWare. In MassWare, we facilitate the reuse and extension of existing measurement tools, and integrate them with MassWare by designing an masstool component metamodel that accepts the registration of event sensors as listeners and notifies them through a masstool interface. Measurement tools can be implemented as independent components (masstools) that can be used and extended in MassWare.

MassWare support application-aware adaptation, in which applications make the adaptation decisions by providing adaptation rules in a script file described by an adaptation policy language (XML). The adaptation rules 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 engine can run-time interpret the adaptation rules, build corresponding hierarchical events (sensors) and component chains (actuators), and subscribe the actuators with corresponding sensors. Once the conditions of a sensor is sufficed, it will notify the engine and active the subscribed actuator.

In MassWare, modifying the actuator in traditional middleware is replaced by switching active and inactive actuators in MARCHES based on the active messages. It successfully eliminates the operation suspension time and buffer clearance time. Furthermore, the robustness of the distributed application is improved since there is no communication and system halting in the distributed actuator-synchronization process by using the active messages.

We have implemented the active message based reconfiguration mechanism and a supported E-learning application in C#. We have evaluated its performance based on our testbed in both laptop and PDA platforms

(1) The MassWare and E-learning application

(2) The testbed and evaluation result

(3) Source codes download (laptop and PDA) 

(1) The component based metamodel in sensor nodes (SOS);

(2) A simple file system in sensor nodes (ELF); and

(3) The coexistence of reconfiguration processes and other sensor activities.