Metadata-Based Middleware

To support context awareness and to perform context-aware application adapta-tion, the emerging research direction is the adoption of metadata for representing both the context characteristics and the choices in service behavior at a high-level of abstraction, with a clean separation between service management and service logic. Section 2.3.1 has provided an overview of emerging models for metadata definition. This section presents sig-nificant examples of middleware infrastructures supporting context-aware applications by exploiting metadata. In particular, special attention is devoted to semantic metadata-based middleware.

The GAIA project is a middleware infrastructure that enhances operating system features to include context-awareness [83]. GAIA is built on a CORBA distributed sup-port, but it provides additional features to enable context-awareness. In particular, GAIA defines a common model of context, which all agents can use in dealing with context. This model is based on a predicate model of context and has been supplemented with ontolo-gies to define the semantics of various contexts. It also supports acquisition of contextual information, reasoning about context and modifying agents behavior based on the current context. The model of context and the middleware support the use of different reasoning mechanisms, such as first order logic and temporal logic, to reason about context and decide how to behave in different contexts. Agents can alternatively employ learning mechanisms like Bayesian learning and reinforcement learning to learn different behaviors in different contexts.

The Context Broker Architecture (CoBrA) is an agent-based architecture for sup-porting context-aware computing in so-called smart spaces. Smart spaces are distributed system that consist of communities of intelligent agents, services, devices, and sensors shar-ing a common goal. For example, in the EasyMeetshar-ing application, a smart meetshar-ing room is set up to provide relevant services and information to the meeting participants (e.g., speakers, audiences, and organizers) based on their situational conditions (or contexts) [34]. CoBrA uses Semantic Web languages for representing context ontologies and for sup-porting context reasoning, thus facilitating independently developed agents to share context knowledge and minimizing the cost of context sensing. Central to CoBrA architecture is the presence of a Context Broker, an intelligent agent that runs on a resource-rich stationary computer in the space and gathers raw context data from sensors deployed in the envi-ronment. The context broker is also responsible for reasoning about the information that cannot be directly acquired from sensors, detecting and resolving inconsistent knowledge that is stored in the shared model of context, and protecting user privacy by enforcing policies (specified in the Rei language [60]).

Agostini et al. proposed the Context Aggregation and REasoning (CARE) mid-dleware to support a set of requirements for context-awareness in distributed environments.

CARE has three major goals, namely: supporting the fusion and reconciliation of context data obtained from distributed sources, supporting context dynamics through an efficient form of reasoning, and capturing complex context data that go beyond simple attribute-value pairs. CARE adopts profiles and policies to perform context-based tailoring of service provision to mobile users. In particular, as described in Section 2.3.1, profiles are repre-sented by using Composite Capability/Preference Profiles (CC/PP) [67]. Profiles include both shallow context data and ontology-based context data which are expressed by means of references to ontological classes and relations inserted in the CC/PP profile. The choice

of defining two different kinds of profiles is motivated by performance issues reported by the authors in [15]. Each entity has a dedicated Profile Manager for handling its own context data. Both the user and the service provider can declare policies in the form of rules over profile data which guide the adaptation and final personalization of the service. The Con-text Provider module is in charge of building the aggregated conCon-text information for the application logic. In particular, it evaluates adaptation policies and solves possible conflicts arising among context data and/or policies provided by different entities.

CARMEN is a middleware for context-aware resource management that supports and facilitates the design, development, and deployment of context-dependent services for the wireless Internet [22]. CARMEN allows service providers, system administrators, and final users to specify different kinds of metadata in a declarative way at a high level of abstraction. CARMEN metadata influence the dynamic determination of context and, consequently, the context-based service provisioning, without any intervention on the appli-cation logic, according to the design principle of separation of concerns. CARMEN exploits two types of metadata: profiles to describe the characteristics of any resource modeled in the system, and policies to manage migration, binding and access control. CARMEN adopts XML-based standard formats for profile representation to deal with the Internet openness and heterogeneity, such as CC/PP for user/device profiles [67] and WSDL for the service component interface description [35]. In addition to profiles, CARMEN expresses policies as high-level declarative directives: access control policies to ensure secure resource usage and mobility handling policies to guide the middleware decisions in response to context variations at service provision time. Policies are specified in the Ponder policy language.

The CARMEN middleware is designed according to a layered architecture, where the higher level layer is responsible for managing metadata and context, and the lower level layer is in charge of providing common features for distributed service provisioning, e.g., support for

naming, event management and distributed communication. A peculiar feature of CAR-MEN is the way it handles dynamic variations in service provisioning due to user mobility, i.e, by exploiting mobile agents, called shadow proxies, that migrate across nodes on the fixed network and act on behalf of mobile users.

2.4 Alternative Design Guidelines for Context-Aware