MACE - Adaptive Component Management Middleware forUbiquitous Systems
Department of ComputerScience, UCLMalet Place
London, WC1E 6BT, UK
Robert Ghanea-HercockBT Labs, Adastral Park
Martlesham HeathIpswich IP5 3RE, UK
Stephen HailesDepartment of Computer
Science, UCLMalet Place
London, WC1E 6BT, UK
ABSTRACTIf the hype is to be believed, we have come very close to therealisation of a ubiquitous computing environment. Thereare already a wide variety of devices, networking technolo-gies and bespoke services; and yet the vision of anywhereanytime computing is proving somewhat elusive. Softwareabstractions and metaphors that were developed for desk-top applications do not extend to ubiquitous computing.Because of the frequency of contextual changes and thepaucity of resources, new distributed applications requiremuch more flexible support for controlled reconfiguration,self-adaptation, and recovery of components.
We present a lightweight component management Mid-dleware that provides flexibility by allowing design, deploy-ment, and run-time reconfigurability. At design and deploy-ment time, the developer can design a system by structuringsoftware components according to a specific scenario. Then,at run-time, she can dynamically reconfigure the system, ad-just to new environments, or dynamically add mechanismsthat enables self-adaptation.
1. INTRODUCTIONIn many ways, we have come very close to the realisa-
tion of ubiquitous computing. In developed societies, in-dividuals often own several ubiquitous devices from PDAsand laptops, to mobile phones and GPS systems. There area growing number of ubiquitous networks: (W)LAN/MAN(Ethernet & IEEE 802.11), GSM/GPRS/3G WANs, and,more recently, a growing set of PANs (Bluetooth, Zigbee,AudioNet etc.). A few ubiquitous services have been alreadybeen developed and deployed (for example, location-basedservices). In spite of this, the reality of development anddeployment of ubiquitous computing applications is not in
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.MPAC 06, November 27-December 1, 2006 Melbourne, AustraliaCopyright 2006 ACM 1-59593-421-9/06/11 ...$5.00.
such good shape. Abstractions and metaphors of multiple-users/single-machine and single-user/single-machine scenar-ios do not extend to multi-user/multi-machine situationswith a much stronger emphasis on autonomic machine-to-machine interaction. It is expected that, within the nextten years, the number of devices per person will increase byanything up to two orders of magnitude, but that the major-ity of such devices will be embedded and devoted to singlepurpose applications. However, such approaches miss outon a major revenue stream, in which a number of devicesworking together may provide services that cannot easily beprovided by individual devices.
From the era of complex devices and simple networkingwe are moving to an era of simple devices and complexnetworking. For us, ubiquitous computing environmentsimply the following:
Heterogeneity within (i) the capability of systems anddevices, (ii) the structure of systems with regard totheir composition. Proposed systems are typically aloose coupling of traditional centralised networks pro-viding the backbone infrastructure to support numer-ous small, lightweight, and often mobile componentsthat provide sensory input, perform actuation and mayinteract in an ad-hoc manner.
Behavioural heterogeneity in the operation of compo-nents and systems. This includes differences in theirtask, scope, autonomy, policies of interaction and theutilities gained from interacting.
A variety of systems/devices with different scales andcapabilities that must interact to support the requiredubiquity. This raises two issues: (i) to realise theinvisibility criteria, devices must necessarily becomesmaller and more tightly embedded in their environ-ments. While current trends continue to forecast ever-increasing capacity in ever-shrinking devices, we canstill safely assume that size will limit capacity . (ii)The increase in the number and heterogeneity of com-ponents in an environment leads to a dramatic increasein the complexity of managing the environment. Cen-tralised methods do not scale well and hinder the dy-namism of systems .
Further, constraints such as battery, computation power,memory, and sensing capabilities limit the amount of
useful work that a device is able to perform locally,thereby severely affecting the scope of solutions en-abling software subsystems such as security . Withrespect to this, Estrin et. al. remark: Fidelity andavailability will come from the quantity of partially re-dundant measurements and their correlation, not theindividual components quality and precision .
The embodiment of components in their environmentis among the main requirements to achieve ubiquity.Embodiment means that components are embedded intheir operational environment, and therefore physicalaccess is limited. Issues such as the update of func-tionality or management policies cannot be performedeasily, further highlighting the need for autonomic andself-regulating capabilities.
In the following sections we outline MACE (Middlewarefor Adaptive Component managEment). MACE is aimedat addressing the challenges listed, through a hybrid agent-component approach. This approach is taken in due recogni-tion of the inherent trade-offs between flexibility and fault-tolerance. For example, though increased flexibility is re-flected in the capacity to reconfigure a system, it makesit more difficult to reason about its performance and con-trol, particularly when the likelihood of failure is non-trivial.Therefore, our aims for MACE are to support the design,deployment, and run-time (re)reconfigurability of systems,while still maintaining fault-tolerance.
MACE implements a distributed component model in whichcomponents may be local or remote and supports synchronousand asynchronous communication. This is used to providea high-level of modularity and flexibility that enables fine-grained control over the behaviour of MACE-based systemat the interface level. For example, components can eas-ily monitor how their functionality is being used and whois using it, paving the way for fine-grained policy-managedcontext adaptation and security.
The remainder of the paper is organised as follows: sec-tion 2 presents an overview of the system architecture. Sec-tion 3 discusses the usage of the system, provides additionaldetails of its functionality and discusses potential securityissues. Section 4 reviews related work and finally, section 5concludes this paper.
2. SYSTEM ARCHITECTURE
MACE is a component framework and methodology aimedat supporting flexibility and fault tolerance. At the mostabstract level, MACE simply enforces that components pro-vide interfaces and receptacles that are respectively used tospecify their functionalities and dependencies, and that arechained to compose systems.
Given the requirements listed for ubiquitous environments,software must be capable of being both robust and extremelyflexible in order to realise the functionality envisioned. Insupport of this, MACE inherently modularises software de-sign, allowing software developers to construct application-level software from distinct components that each provide asubset of the functionality required by an application. Todo so, MACE employs four component profiles, in whichhigher-level profiles extend the functionality provided by oflower-level profiles, as depicted in Figure 1.
Figure 1: The hierarchical arrangement of MACE compo-nent profiles.
The component profiles that MACE implements are asfollows:
1. The Basic Component profile consists of the compo-nent payload, which provides the real functionality andthe MACE wrapper. This profile simply requires thatcomponents supply their dependencies and functional-ities (for the resolution and execution of services), andincurs a minimal overhead.
The profile is primarily used to enable components toparticipate within an application and it is catered to-wards the lowest level devices. As such, within a com-ponent system, this profiles function is simply to pro-cess services and make use of higher profiles to supportextended functionality.
2. The Policy-Managed Component profile adds sup-port for adaptive/autonomous behaviour through apolicy enforcement module. With regard to securityconsiderations, policies dictate the runtime behaviourof a component by dynamically hiding and revealingthe functionalities (and associated dependencies) of acomponent, based on the context or condition, or byimposing constraints on execution flows.
Policies are also used to perform context adaptation.In this role, the rules in the policy dictate the condi-tions for adaptation; for example, when to migrate acomponent from one host to another or initiate servicediscovery.
Policies are defined outside of the component and stat-ically compiled to check that they are well-formed. Inour case we focus on detecting cycles and violationsof non-monotonic constraints. A detailed discussion ofthis part of the work can be found in .
3. The Mobile Component profile adds the supportfor physical mobility to the basic component profile.Because there is no specific runtime environment forMACE, mobile components also pr