The decision engine of MassWare is similar with that of AwareWare. It contains two major function components: a hierarchical event model and a XML script parser.

The hierarchical event model can build a comprehensive event tree that organizes the awareness data in a hierarchical way. To improve the efficience of MassWare events, we designed a MDAG (Modified Directed Acyclic Graph) based event model.

The XML script parser is used to parse the application developer defined script file. The script file contains all the component information and adaptation rules. Because MassWare supports application-aware adaptation, application developer can easily change the adaptation rules to suffice their requirements.

AwareWare use a composite event model. Although this event model can organize awareness data in a hierarchical tree, it prevents the event model from supporting complex event expressions, i.e. the operation of multiple event sources, because it constrains that the simple event must contain one and only one event source.

In MassWare, we use hierarchical event model, each event node in the event tree has a left hand side (LHS) and a right hand side (RHS). Either side can be an event source, a compare conditioner, or a boolean conditioner. The event source can be a number, a single awareness, or an awareness expression.

To improve the efficiency of sensors, the hierarchical event tree is constructed according a Modified Directed Acyclic Graph (MDAG). That is, before creating a new event node, check whether an identical node or an inverse node already exists. If such a node already exists, the higher level event or actuator can subscribe to the existing one instead of creating a new one. Event node a is defined as the inverse node of node b if a and b have the same event source and comparison value, but inverse comparison operator. For example, the inverse event of ¡°Min(AVI_CPU, 10) < 1.0¡± is ¡°Min(AVI_CPU, 10) > 1.0¡±. 

To use MassWare to build an adaptive distributed application, developer(s) need to provide a script file that can be divided into a declaration part and an adaptation-rule part as shown in the figure. The declaration part declares all required components. Based on the declaration, the MassWare agent loads and instantiates the components, and initializes them with the provided parameters. The adaptation rule part contains adaptation rules and each rule can be further separated into three sections: a sensor, a proactive actuator, and an optional reactive actuator.

The sensor section can be parsed by the event interpreter to build a hierarchical event tree (sensor) that accepts the subscription of the proactive actuator declared in the proactive actuator section. Each proactive actuator consists of a list of marchlets declared in the marchlets segment and a list of marchlet parameters. The reactive actuator section describes the corresponding reactive actuator that will be constructed in peer agents through synchronization to process the received data sent from this proactive actuator. Based on contextual information, users can define different rules for architecture reconfiguration and parameter turning based on their requirements. For instance, the first rule means when the average available bandwidth in last 5 seconds is less than 10 Mbps and the average available CPU in last 10 seconds is greater than 1.0 GHz, the proactive actuator (also the application architecture) in the sender side consists of image Grab component and image Compress component. The reactive actuator in the receiver side use Decompress component and Display component to process the received data correspondingly.

The XML file and XML Scheme file can be downloaded by clicking the link. 

MobiPADS: A Reflective Middleware for Context-Aware Mobile Computing

CARISMA: Context-Aware Reflective mIddleware System for Mobile Applications

SATIN: A Metamodel for Engineering Adaptable Mobile Systems