| April 2006 (Vol. 7, No. 4) 1541-4922/06/$26.00 © 2006 IEEE Published by the IEEE Computer Society Middleware: Context Management in Heterogeneous, Evolving Ubiquitous Environments
Design strategies and a flexible, adaptable middleware architecture for resource-limited, evolving systems. Mobile computing environments are characterized by heterogeneity—systems consisting of different device types, operating systems, network interfaces, and communication protocols. Such heterogeneity calls for middleware that can adapt to different execution contexts, hide heterogeneity from applications, and transparently and dynamically switch between network and sensor technologies. Additionally, middleware for context-aware systems must keep a context model (a model of their environment), taking into account several aspects of the environment. The more complex and heterogeneous an execution environment is, the more complicated its underlying context model. Moreover, because systems can evolve, context management must also support model evolution without restarting, reconfiguring, or redeploying applications and services. We describe a context management middleware that can efficiently handle context despite the execution environment's heterogeneity and evolution. It uses context meta-information to improve a context-aware system's overall performance. Heterogeneous environments In pervasive environments, heterogeneity has hardware, software, and network aspects. Hardware heterogeneity refers to the presence of different computing devices, such as desktop computers, palmtops, and mobile phones. This type of heterogeneity demands middleware infrastructures that are deployable on servers, workstations, and portable mobile devices. Software heterogeneity means the environment is executing different operating systems and applications, requiring software interoperability and the adoption of context models that address specific application requirements. Network heterogeneity means that network interconnections among the system's devices don't conform to a single architecture or technology. This heterogeneity demands adaptable, scalable middleware that supports seamless communication. It also implies that you should limit context models to specific network domains because some context information might pertain to only a subset of applications or devices. We call this context domain, a logical boundary that establishes the context information's scope. Each of these aspects also has an evolutionary component: when a new device type, application, or context type is introduced, context models and the software infrastructure should evolve to accommodate the extended environment's properties and requirements. The infrastructure should efficiently support this evolution. Developers should work on context models and middleware in tandem to cope with heterogeneity and efficiency. Notably, a context model's complexity determines the computational complexity of the middleware's context-handling capability. For example, adopting a certain context model might require adopting more complex context management and storage mechanisms as well. Joëlle Coutaz and her colleagues present this relationship as a conceptual framework that interconnects an ontological foundation for context modeling with a runtime infrastructure (middleware). 1 Most middleware projects (see the related sidebar ) have not explored such an interdependence. Consequently, most middleware have adopted context models restricted to a single context domain (for example, a device's local execution context 2 , 3 or location 4 ), or the context-processing complexity has hindered the middleware's deployment to resource-limited devices. Our approach uses context meta-information to make middleware-level decisions that improve the provision, dissemination, and access to context information. Other work, such as CoCo, 5 handles heterogeneity of context information services by adopting different context models and services in different network domains. For example, CoCo provides an infrastructure and language to describe context models in order to achieve interoperability among context information services. However, our work doesn't specifically focus on context service heterogeneity, so we assume that any context service and infrastructure are built on the same middleware. Designing context management middleware We extended MoCA's ( mobile collaboration architecture) context information service 6 to support hardware and software heterogeneity, context evolution, and deployment at devices with different resource profiles. This new service provides a uniform view of context types and data so that the system can retrieve context information published by different sources and at different locations using a single primitive. It also permits the inclusion of new context-aware services without adapting (and redeploying) the middleware to support the new context types. In our approach, two basic components interact with the context management infrastructure to create, disseminate, and use context: context providers and context consumers. A context provider is an entity responsible for publishing a certain kind of context information; for example, it can probe raw data or it can (as an inference agent) aggregate or interpret basic context information into more complex context information. For example, MoCA's monitor is a context provider that publishes information about a device's local execution context such as its memory usage, energy consumption, or IEEE 802.11 RSSI (received signal strength indication). MoCA's location inference service (LIS), 7 another of its context providers, transforms IEEE 802.11 RSSI values published by the monitor into symbolic positioning information. A context consumer is an entity interested in certain context information, including context-aware applications or context-processing services. An entity can act simultaneously as a context provider and as a context consumer. For example, LIS is both a consumer of wireless connectivity context and a publisher of location context. And MoCA's context information service (CIS) interconnects context providers and consumers, receiving and storing context information and disseminating it to consumers. We provide a generic context access API for context providers and consumers, keeping the heterogeneity management at the middleware implementation level. To do this, we follow three design strategies: Architecture The CIS consists of the basic elements shown in figure 1 . This organization is logical—that is, it doesn't describe each component's actual location or distribution. However, it establishes well-defined responsibilities for the following components: Figure Figure 1. The context service architecture. These components hide the complexity required to manage context in a heterogeneous environment. Each service's behavior and distribution can vary according to the target device where the middleware will be deployed. The middleware implementation comes in two flavors: heavyweight and lightweight, the latter targeting resource-limited devices. The lightweight instance defines more restrictive policies for each component and typically distributes some context-related tasks to other remote components. For example, with a lightweight instance, the context repository doesn't maintain a history of context data. Moreover, the context repository would store only context published locally, delegating requests for nonlocal context to remote repositories, say, at workstations or servers. Also, the subservices available at each device depends on the type of middleware implementation—for example, a lightweight instance will likely have a caching service to cope with intermittent connectivity. The external services implement services that either depend on or complement context management. For example, we implemented our privacy service 8 as an orthogonal service of MoCA's architecture. Adopting these complementary services helps simplify the interaction between the context management service and a client. Deploying context types When introducing a new type of context information into a context-aware system, a process that we call deployment of context types, you must model and make it available to all interested parts: sensors, inference agents, applications, and the middleware itself. A fundamental principle of our approach is to use a strongly typed model for context data. That is, we define and resolve the context type system at development time and describe the context type through an XML-based model that contains: Figure 2 shows the steps involved in deploying a new context type. First, we validate the context model: the context tool (CT) checks for inconsistencies between the new and existing context types, such as name conflicts or incorrect type dependency relationships. Next, the CT updates the context type system through the type system manager, which in turn initializes the repository for storing the new context information. Finally, the CT generates a library containing stubs that implement the interface for context access. This approach allows efficient context handling and interoperability among languages. Figure Figure 2. Context deployment steps. Currently, we've only implemented a Java language binding for MoCA's context model. The generated library maps the XML-based context model to object-oriented language constructs that the applications use to access context information. We've decided to adopt an OO model for context handling instead of an ontology-based model because the latter requires resource-hungry ontology engines. The context deployment task integrates context modeling with the development of the context-aware application. The library and the middleware keep context access transparent to the application, thus easing application development. We argue that context models should maintain the aforementioned information to help the infrastructure (middleware) make the right decisions about how to use context information efficiently. Finally, the context model helps developers better understand context usage semantics. Configuring context access To access and evaluate context information efficiently, we employ a middleware configuration comprised of static and dynamic parts, which adapt context evaluation and dissemination to the modeled context's characteristics and to the application's runtime requirements, respectively. For each configuration, the middleware selects the most appropriate policy for making the context available, according to policies we discuss elsewhere. 9 Static configuration To explore each context type's particularities and improve its access performance, a middleware should handle different types differently. The context meta-information, obtained from the context model, lets the middleware choose the most suitable mechanisms to handle certain context information. When a CT processes a context model, it uses this meta-information to produce an efficient stub implementation for context access. Additionally, the middleware uses such meta-information to adapt its runtime behavior. For example, consider a static context attribute—that is, an attribute that has a constant value (for example, the OS type and version running on a device). When deploying this context, we configure the context management infrastructure to disseminate and update this attribute only the first time an application requests the context. Context information management of local and nonlocal domains is another example of a task improved through static configuration. A local context domain comprehends context information provided by a device that describes its local execution context—CPU usage, available memory, and the operating system's type and version. On the other hand, a nonlocal context domain consists of context information provided by an external context provider. Hence, access to nonlocal context requires at least one hop on the network. The middleware stores local domain context in a local instance of the context repository, which improves the performance for context information access. Current middleware platforms usually don't distinguish between local and nonlocal context domains. Table 1 shows some parameters for static configuration and alternatives for changes in the middleware behavior. We call this configuration static because it doesn't change at runtime. Table 1. Parameters for static configuration. Dynamic configuration Besides static configuration based on context models, our middleware also supports dynamic configuration at application start-up time. When an application launches and registers itself at the middleware, it can define a specific policy for using certain context information. These policies are based on application requirements about the precision of the context information to be used. Table 2 shows some parameters for dynamic configuration (in terms of application requirements) and the corresponding influence on the middleware behavior. Freshness (how recent data must be) and lazy (on demand) evaluations are examples of access policies that applications can set. Table 2. Parameters for dynamic configuration. Several applications using the same middleware instance can select different policies for accessing the same context information. In this case, the middleware chooses the most restrictive policy that satisfies all application requirements. Using such a dynamic configuration, the middleware can choose when to best publish context information and to execute context queries. For example, an application might be interested in location context changes only in terms of a symbolic location—for example, the building name where the device is located—and thus shouldn't receive notifications about location changes at a finer granularity (for example, coordinates). In this example, if a middleware delivers the location only in the selected granularity, it could decrease the amount of disseminated information, improving the context dissemination's performance. We're investigating how quality-of-context modeling can provide a richer, dynamic middleware configuration. So far, we've decided to just implement freshness and context precision properties as parameters for setting up our middleware policies. At this point, we've developed a prototype of a context service based on our architecture. We're now integrating this with other components and services of our MoCA context-provisioning middleware architecture—in particular, our privacy service for context access. Through this integration, we aim to validate the architecture's ability to support configuration of context access and context model evolution. As part of our future work, we'll investigate extending our architecture to flexibly accommodate quality-of-context parameters. We're also planning to research how context consumers can specify and use context views —that is, selected portions or attributes of a complex context type. We believe that specifying different context views without changing the underlying context model could create new opportunities for enhancing context access efficiency. Research grants from the Brazilian National Research Funding Agency (CNPq) (project numbers 552.068/02-0 and 479824/2004-5) support this work. References Related Links
| ||||||||||||||||||||||||||||||||||||||||||||||||||
DOWNLOAD PDF 
We propose an architecture that offers a set of components that help meet common requirements of context management in different execution environments. 
