## 5 FamiWare Monitoring and Context-Awareness Services
### FamiWare Services Architecture and Implementation  
FamiWare follows a publish/subscribe event-based mechanism, specifically a reduced implementation of the OMG Data Distribution Service (DDS) interface [30]. Thus, all FamiWare services communicate with each other by means of this interface that is implemented by a microkernel, as shown in the FamiWare architecture in Figure 8. In this figure, three services related to the context management are represented. The movement monitoring publishes an event (called topic in DDS terminology) with the detection of movement information. The context-awareness service is subscribed to the topics published by the monitoring services. Furthermore, the context-awareness service publishes the adequate reconfiguration plan to adapt the system when a context change is detected. Finally, the reconfiguring service is subscribed to this plan. This is the generic architecture of FamiWare where the specific services also have a common structure to facilitate their reusing.  
For instance, in the monitoring services the data to monitor (_i.e._, the context source), the frequency of monitoring and the topic name are generic parameters.  
Therefore, for every specific monitoring service FamiWare implements a class for the Java-based implementations (Android and Sun SPOT) or a component for the nesC version that is inherited from an abstract monitoring service. The code of these classes and components and also the corresponding code of the context-awareness services are generated automatically by our configuration process, as will be described in the next subsection.  
In the Android version of FamiWare, the services are implemented as an Android _Service_ class. The abstract class _MonitoringService_ (see Figure 9(a)) has the following characteristics: (i) it reads data from a sensing unit or from other resource considered relevant for the context; (ii) the reading is done periodically; and (iii) the data is published under a determined topic. Then, the kind of data, the reading frequency and the topic name, are parameters that must be obtained after the configuration process. Figure 9(a) depicts the _BatMon_ class that inherits _MonitoringService_ and implements the reading of the battery level, and also specifies both the reading frequency and the topic name (e.g., _BATT_TOPIC_). The _ContextAwarenessService_ defines an interface that allows the specification of new topics to be under observation as part of the context. For example, a particular instantiation of this service could observe the battery level of a sensor and the state of its network connection but not the position of the more sensor. The context data to be observed and the situations considered as context changes (_i.e._, the context constraints) must also be obtained after the configuration process. Figure 9(b) shows the component graph for an instantiation of FamiWare with one service to monitor the battery, the context-awareness service and the reconfiguration service.  
In a similar way as in the Android version, all the monitoring services (shown as _BattMonC_ in Figure 9(b)) are defined through their monitored data, the reading frequency and the topic name of the data specified at design-time. The _ContextAwarenessC_ is a generic component that has as parameter, monitored data topics to be subscribed. Likewise in Android, this service has a checker function (_EnergyChecker_ in Figure 9(b)) to detect context changes. In the Sun SPOT version (Figure 9(c)), the _Monitoring_ services are independent MIDlets and there are specific _ContextAwareness_ instances for every context topic subscribed and this instance will have an associated specific checker (_BattChecker_ in Figure 9(c)).  
Figure 8: FamiWare autonomic services.  
Figure 9: FamiWare instantiations with monitoring and context-awareness services for three platforms: (**a**) Android; (**b**) TinyOS; and (**c**) Sun SPOT.