Toward a Standard Ubiquitous Computing Framework
Total Page：16
File Type：pdf, Size：1020Kb
Toward a Standard Ubiquitous Computing Framework † Martin Modahl Bikash Agarwalla T. Scott Saponas Marsdorferstrasse 36 Gregory Abowd Dept of Computer Science 50858 Koln¨ Germany Umakishore University of Washington [email protected] Ramachandran Box 352350 College of Computing Seattle, WA 981952350 Georgia Institute of [email protected] Technology 801 Atlantic Drive NW Atlanta, GA 303320280 [bikash|abowd|rama] @cc.gatech.edu ABSTRACT 1. INTRODUCTION This paper surveys a variety of subsystems designed to be the build- A ubiquitous computing (UbiComp) environment entails (1) an ing blocks from which sophisticated infrastructures for ubiquitous extensive and complex computer architecture deployment, (2) so- computing are assembled. Our experience shows that many of these phisticated conduits for dynamic data flow and control across this building blocks fit neatly into one of five categories, each con- architecture, and (3) a judicious external interface facilitating user taining functionally-equivalent components. Effectively identify- interaction with the system. A ubiquitous infrastructure must act ing the best-fit “lego pieces”, which in turn determines the compos- very much like a telephone patch board i.e., a software layer which ite functionality of the resulting infrastructure, is critical. The se- various assets are “hooked” into and where logical and physical lection process, however, is impeded by the lack of convention for connections between these assets are instantiated. Assets, in the labeling these classes of building blocks. The lack of clarity with broadest sense, refer to physical devices, bandwidth, processors, as respect to what ready-made subsystems are available within each well as services made available through the patch board. This anal- class often results in naive re-implementation of ready-made com- ogy suggests a standard and uniform, but not necessarily central, ponents, monolithic and clumsy implementations, and implemen- interface. It is only through this middleware layer that the vast ar- tations that impose non-standard interfaces onto the applications ray of disparate assets can be brought together to create the type of above. This paper explores each class of subsystems in light of rich ubiquitous applications we are excited about. the experience gained over two years of active development of both A necessary precondition for deployment of a UbiComp appli- ubiquitous computing applications and software infrastructures for cation is a distributed system composed of (1) computational re- their deployment. sources including network-connected sensors and actuators, and (2) a mechanism to generalize patterns of interaction with these resources. The reusable corpora of middleware can speed the sec- Categories and Subject Descriptors ond step, but in our own experience, we have often overextended C.2.2 [Computer-Communication Networks]: Networking Pro- or mis-used existing UbiComp middleware subsystems. A standard tocols—Protocol Architecture (OSI Model); D.2.1 [Software En- language for describing middleware subsystems or a simple taxon- gineering]: Requirements/Specifications—Methodologies; D.2.11 omy for classifying subsystems could aid in the identification of [Software Engineering]: Software Architectures—Patterns potential candidates for a middleware deployment. Different distributed applications, each using middleware for intra- application communication, have very diverse needs. Similarly, an Keywords individual distributed application might, at times, require very dif- ubiquitous infrastructure, infrastructure stack ferent things of middleware subsystems. In these cases, multiple, complementary middleware subsystems might be used simultane- Martin completed all work while at Georgia Tech. ously across a single computer architecture deployment to provide †Scott completed all work while at Georgia Tech. the most effective communication tools to all applications. Here the middleware taxonomy must also provide aid in choosing what mul- tiple middleware subsystems might be deployed simultaneously to the greatest effect. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are To arrive at a reasonable taxonomy describing UbiComp infras- not made or distributed for profit or commercial advantage and that copies tructure and to understand the possible infrastructure interactions, bear this notice and the full citation on the first page. To copy otherwise, to we begin by examining some current and potential UbiComp in- republish, to post on servers or to redistribute to lists, requires prior specific frastructures such as UPnP, MediaBroker, and the GRID. By parti- permission and/or a fee. tioning these varied middleware subsystems into categories/ equiv- 2nd Workshop on Middleware for Pervasive and AdHoc Computing alence classes, it becomes possible to reason about entire infras- Toronto, Canada tructures piecemeal. Thus a whole infrastructure may be evaluated Copyright 2004 ACM 1581139519 ...$5.00. in terms of its constituent parts, streamlining the evaluation process resources that applications might query and use. This way, an ap- and the infrastructure's subsequent refinement. plication might require a camera stream or a speaker, query for de- In addition, standard subsystem classes can improve develop- vices containing that service in the area requested, then request and ment of standard intra-infrastructure, subsystem-to-subsystem in- use the resource. Each of these resources as well as the infrastruc- teraction patterns. With a clearer picture of what infrastructure ca- tures exposing these resources to the outside world are managed as pabilities exist and where they are located, developers are better modular building blocks. positioned to leverage these capabilities in their applications. Once the application requirements have been identified, developers may 2.2 Development Case Study be able to pick existing infrastructure pieces to develop the appli- Our software intercom is an example of an application built on cation quickly and effectively. hardware and middleware, deployed with the above paradigm in This paper proposes a five-class infrastructure taxonomy based mind, in the Aware Home at Georgia Tech [17]. Using consumer on the orthogonal functionalities of most commonly occurring sub- electronics computers and our middleware—MediaBroker [20]— systems. These include Registration and Discovery, Service and this software intercom allows users throughout a home to commu- Subscription, Data Storage and Streaming, Computation Sharing nicate through walls and floors as if they were in the same room. and Context Management. In accordance with the paradigm described above, applications Figure 1, appearing later in the paper, shows a stack correspond- expose resources which other applications use. The user interacts ing to top to bottom interaction between the equivalence classes. with an intercom interface application which controls a set of mod- The user application is provided the APIs for interacting with Ser- ular audio applications deployed throughout the Aware Home. The vices, Streams and Storage Locations, and Process Migration/ Dis- user interface application projects a control-information resource tribution. Context Management Services and Ontologies are also which outputs current state information while the audio applica- common among all applications. tions provide audio resources which stream captured audio. While This paper continues in Section 2 discussing the imagined com- running, The interface application queries the state of the audio re- puter architecture deployment for UbiComp as well as some initial sources and actuates end-to-end connections through its single con- application deployment experience using middleware to bridge be- trol resource. In turn each audio application listens to the interface tween application and hardware deployment. Section 3 details the application's control resource for direction. five taxonomy classes. We conclude in Section 4. Our initial deployment, built entirely on MediaBroker, relied on one-way data streams to transfer audio information between audio inputs and outputs between audio access applications while using 2. EXAMINING EXISTING the same one-way data streams to distribute control information INFRASTRUCTURE COMPONENTS from the interface application to the audio applications. The nature The intrinsic nature of common UbiComp applications builds of these one-way, relatively static, connections between controller on connecting distributed nodes into a over-arching application. and controlled made the deployment of the intercom much less dy- This application might distribute itself onto multiple computers as namic than anticipated. a common Internet messaging client is deployed on multiple com- Recently, the intercom has been redesigned to use MediaBroker puters throughout the world, while each individual client connects as an infrastructure for low latency audio data streams and UPnP into a larger whole that is a global messaging application. An ap- for distributing discrete control messages between a set of control plication might also run in a single location but request and access applications and the audio applications they control. resources throughout an environment the same way a cable set-top In this case, taking advantage of UPnP for low-bandwidth mes- box might request resources from the cable company and display sage passing