Shankar Ponnekanti

ICrafter: A Service Framework for Ubiquitous Computing Environments

In this paper, we propose ICrafter, a framework for services and their user interfaces in a class of ubiquitous computing environments. The chief objective of ICrafter is to let users flexibly interact with the services in their environment using a variety of modalities and input devices. We extend existing service frameworks in three ways. First, to offload services and user input devices, ICrafter provides infrastructure support for UI selection, generation, and adaptation. Second, ICrafter allows UIs to be associated with service patterns for on-the-fly aggregation of services. Finally, ICrafter facilitates the design of service UIs that are portable but still reflect the context of the local environment. In addition, we also focus on the system properties such as incremental deployability and robustness that are critical for ubiquitous computing environments. We describe the goals and architecture of ICrafter, a prototype implementation that validates its design, and the key lessons learnt from our experiences.

Portability, extensibility and robustness in iROS

The dynamism and heterogeneity in ubicomp environments on both short and long time scales implies that middleware platforms for these environments need to be designed ground up for portability, extensibility and robustness. In this paper, we describe how we met these requirements in iROS, a middleware platform for a class of ubicomp environments, through the use of three guiding principles - economy of mechanism, client simplicity and levels of indirection. Apart from theoretical arguments and experimental results, experience through several deployments with a variety of apps, in most cases not done by the original designers of the system, provides some validation in practice that the design decisions have in fact resulted in the intended portability, extensibility and robustness. A retrospective examination of the system leads the authors to the following lesson: A logically-centralized design and physically-centralized implementation enables the best behavior in terms of extensibility and portability along with ease of administration, and sufficient behavior in terms of scalability and robustness.

Pervasive computing: what is it good for?

The first mass;produced pervasive computing devices are starting to appear-the AutoPC, the Internetconnected ScreenFridge, and the combination Microwave Oven/Home Banking terminal. Although taken separately they appear bizarre, we believe they will play an important role in a world of pervasive computing. Specifically, these devices will accept or deliver information in the context in which it will be most useful, decoupling the information from the context in which it was originally created. We describe an extensible and modular architecture called Rome (to which all roads lead) that a.ddresses this information-routing problem while leveraging significant existing work on composable Internet services and adaptation for heterogeneous devices. Rome’s central abstraction is the concept of a trigger, a self-describing chunk of information bundled with the spatial and/or temporal constraints that define the context in which the information should be delivered. The Rome architecture manages triggers at a centralized infrastructure server and arranges for the triggers to be distributed to pervasive computing devices that can detect when the trigger conditions have been satisfied and alert the user accordingly. The main contribution of the architecture is an infrastructure-centric approach to the trigger management problem. We argue that pervasive computing devices benefit from extensive support in the form of of infrastructure computing Permission to make digital or hard copies of all or part ofthis work Iix personal or classroom use is granted without fee provided that topics are not made or distributed for profit or commercial advantage and that copies bear this nolice and the full citation on the first page. To cop)’ othcrwisc, to republish, to post on servers or to redistribute lo lisls. requires prior spccitic permission and/or a fee. MobiDE Seattle WA USA Copyright ACM 1999 I-581 13-175-5/99/08...

User interfaces for network services: what, from where, and how

5.00 services in at least two ways. First, infrastructure adaptation services can help manage communication among heterogeneous devices. Second, access to public infrastructure services such as MapQuest and Yahoo can augment the functionality of trigger management because they naturally support the timeand location-dependent tasks typical of pervasivecomputing users. We describe our experience with a functional prototype implementation that exploits GPS to simulate an AutoPC, and propose a research agenda to further the creation and deployment of pervasive-computing infrastructure based on the architecture we describe. 1 The Problem Is That There Is No Problem The Internet-connected Electrolux ScreenFridge [8], the NCR Microwave Bank [2], and the new AutoPC [I] appear to be primitive first steps in the direction of pervasive computing. If these efforts sound a bit outlandish, there’s a good reason: the devices are solutions in search of a problem. Yet the devices do have something in common with Web browsers, pagers, cell phones, grocery lists, and to-do notes stuck on the door. We are inundated with information of all kinds, arriving over various media, and targeted for various tasks-do this tomorrow, check up on that when you’re in the office, call me back, and so on. This suggests that one natural target for pervasive computing is data management-getting information into the temporal or spatial context in which it will be most useful (as opposed to the context in which the information was originally created), and using pervasive computing devices to accept or deliver it. It has been argued [ll, 141 that pervasive computing will have succeeded when computers “disappear into the infrastructure” and we find ourselves using computer-assisted task-specific devices, as op-

Interoperability among independently evolving web services

An important problem in the context of network services in ubiquitous computing is the support of ad-hoc interaction. Ad-hoc interaction allows a user entering an environment to discover, request, and interact with user interfaces for the locally available network services, even if she has done minimal or no installation in advance. We observe that most recently-proposed ad-hoc interaction frameworks lack two important mechanisms: distribution and personalization. A distribution mechanism would make it easy to add third-party UIs and to centrally administer UIs across multiple independent workspaces forming an administrative or logical unit, such as all workspaces on a campus. A personalization mechanism would enable a user to see familiar UIs as she roams to different workspaces. We propose extensions to an existing ad-hoc interaction system, ICrafter, that enable these two independent behaviors. The mechanisms raise important policy questions; although we have not studied optimal policies, we outline the policy space and the policies we have adopted.