UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A common model for ubiquitous computing Blackstock, Michael Anthony 2008-10-06

You don't seem to have a PDF reader installed, try download the pdf

Item Metadata


24-ubc_2008_fall_blackstock_michael.pdf [ 1.75MB ]
JSON: 24-1.0051355.json
JSON-LD: 24-1.0051355-ld.json
RDF/XML (Pretty): 24-1.0051355-rdf.xml
RDF/JSON: 24-1.0051355-rdf.json
Turtle: 24-1.0051355-turtle.txt
N-Triples: 24-1.0051355-rdf-ntriples.txt
Original Record: 24-1.0051355-source.json
Full Text

Full Text

A Common Model for Ubiquitous ComputingbyMichael Anthony BlackstockB.A.Sc., The University of British Columbia, 1991M.Sc., Simon Fraser University, 2002A THESIS SUBMITTED IN PARTIAL FULFILMENT OFTHE REQUIREMENTS FOR THE DEGREE OFDoctor of PhilosophyinThe Faculty of Graduate Studies(Computer Science)The University Of British ColumbiaOctober, 2008c Michael Anthony Blackstock 2008iiAbstractUbiquitous computing (ubicomp) is a compelling vision for how people will in-teract with multiple computer systems in the course of their daily lives. To date,practitioners have created a variety of infrastructures, middleware and toolkits toprovide the flexibility, ease of programming and the necessary coordination of dis-tributed software and hardware components in physical spaces.However, to-date no one approach has been adopted as a default or de-factostandard. Consequently the field risks losing momentum as fragmentation occurs.In particular, the goal of ubiquitous deployments may stall as groups deploy andtrial incompatible point solutions in specific locations. In their defense, researchersin the field argue that it is too early to standardize and that room is needed to explorespecialized domain-specific solutions.In the absence of an agreed upon set of standards, we argue that the communitymust consider a methodology that allows systems to evolve and specialize, whileat the same time allowing the development of portable applications and integrateddeployments that work between between sites.To address this we studied the programming models of many commercial andresearch ubicomp systems. Through this survey we gained an understanding ofthe shared abstractions required in a core programming model suitable for bothapplication portability and systems integration.Based on this study we designed an extensible core model called the UbicompAbstract iiiCommon Model (UCM) to describe a representative sample of ubiquitous systemsto date. The UCM is instantiated in a flexible and extensible platform called theUbicomp Integration Framework (UIF) to adapt ubicomp systems to this model.Through application development and integration experience with a compositecampus environment, we provide strong evidence that this model is adequate forapplication development and that the complexity of developing adapters to severalrepresentative systems is not onerous. The performance overhead introduced byintroducing the centralized UIF between applications and an integrated system isreasonable. Through careful analysis and the use of well understood approachesto integration, this thesis demonstrates the value of our methodology that directlyleverages the significant contributions of past research in our quest for ubicompapplication and systems interoperability.ivTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiList of Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xivAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . 11.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Integration Approach . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Ubicomp Programming Models . . . . . . . . . . . . . . . . . . 81.4 Research Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Survey and Analysis of Ubiquitous Systems . . . . . . . . . . . . . . 142.1 Categories of Ubicomp Systems . . . . . . . . . . . . . . . . . . 162.1.1 Abstraction levels . . . . . . . . . . . . . . . . . . . . . 16Table of Contents v2.1.2 Scale of Deployment . . . . . . . . . . . . . . . . . . . . 182.1.3 Organization . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Component Composition Systems . . . . . . . . . . . . . . . . . 202.2.1 Commercial Systems and Standards . . . . . . . . . . . . 222.2.2 Appliance Data Services . . . . . . . . . . . . . . . . . . 232.2.3 SpeakEasy/Obje . . . . . . . . . . . . . . . . . . . . . . 242.2.4 Equip Component Toolkit . . . . . . . . . . . . . . . . . 252.2.5 PCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.6 Reflective Middleware for Mobile Computing (ReMMoC) 262.2.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 262.3 Context Frameworks . . . . . . . . . . . . . . . . . . . . . . . . 272.3.1 ParcTab . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2 The Context Toolkit . . . . . . . . . . . . . . . . . . . . 292.3.3 One.world . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.4 Sentient Objects . . . . . . . . . . . . . . . . . . . . . . 302.3.5 Java Context Aware Framework . . . . . . . . . . . . . . 312.3.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 312.4 Smart Space Systems . . . . . . . . . . . . . . . . . . . . . . . . 322.4.1 iROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.2 Sentient Computing . . . . . . . . . . . . . . . . . . . . 342.4.3 InConcert/Easy Living . . . . . . . . . . . . . . . . . . . 342.4.4 Gaia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4.5 Ontology Based Systems . . . . . . . . . . . . . . . . . 362.4.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 372.5 Wide Area Systems . . . . . . . . . . . . . . . . . . . . . . . . . 372.5.1 Cooltown . . . . . . . . . . . . . . . . . . . . . . . . . . 382.5.2 Context Fabric . . . . . . . . . . . . . . . . . . . . . . . 40Table of Contents vi2.5.3 Nexus . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.4 Aura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.5.5 ActiveCampus . . . . . . . . . . . . . . . . . . . . . . . 422.5.6 Web Services for Ambient Intelligence (WSAMI) . . . . 422.5.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 432.6 Common Abstractions Derived from the Survey . . . . . . . . . . 442.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 The Ubicomp Common Model . . . . . . . . . . . . . . . . . . . . . 483.1 Common Model Requirements . . . . . . . . . . . . . . . . . . . 483.2 Existing Systems' Abstractions . . . . . . . . . . . . . . . . . . 513.2.1 Core Abstractions to a Common Model . . . . . . . . . . 543.3 The Ubicomp Common Model Design . . . . . . . . . . . . . . . 563.3.1 Environment State . . . . . . . . . . . . . . . . . . . . . 593.3.2 Environment Meta-state . . . . . . . . . . . . . . . . . . 603.3.3 Environment Implementation . . . . . . . . . . . . . . . 613.3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 633.3.5 Model Example . . . . . . . . . . . . . . . . . . . . . . 633.4 Model Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 653.4.1 Portability . . . . . . . . . . . . . . . . . . . . . . . . . 653.4.2 Specialization . . . . . . . . . . . . . . . . . . . . . . . 653.4.3 Introspection . . . . . . . . . . . . . . . . . . . . . . . . 663.4.4 Mapping to existing systems abstractions . . . . . . . . . 663.5 Access Control and Security . . . . . . . . . . . . . . . . . . . . 683.5.1 Security Example . . . . . . . . . . . . . . . . . . . . . 723.6 Use Cases for an Executable UCM . . . . . . . . . . . . . . . . 763.6.1 Design/Integration Time Use Cases . . . . . . . . . . . . 76Table of Contents vii3.6.2 Run Time Use Cases . . . . . . . . . . . . . . . . . . . . 773.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794 The Ubicomp Integration Framework . . . . . . . . . . . . . . . . . 814.1 Analysis and Approach . . . . . . . . . . . . . . . . . . . . . . . 814.1.1 Analogy to Enterprise Application Integration . . . . . . 824.1.2 Environment Model Management . . . . . . . . . . . . . 854.1.3 Cross-Domain Interaction . . . . . . . . . . . . . . . . . 874.2 Implementation Overview . . . . . . . . . . . . . . . . . . . . . 884.3 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.4 Environment Composition Logic . . . . . . . . . . . . . . . . . . 964.4.1 Environment and Entity Interaction . . . . . . . . . . . . 964.4.2 Application and Subscription Management . . . . . . . . 994.5 Model and Reasoning . . . . . . . . . . . . . . . . . . . . . . . 1014.6 Component Container . . . . . . . . . . . . . . . . . . . . . . . 1034.7 Message Broker: AdapterManager . . . . . . . . . . . . . . . . . 1054.8 Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064.8.1 Adapter Framework . . . . . . . . . . . . . . . . . . . . 1084.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105 Evaluation: An Integrated Campus Environment . . . . . . . . . . 1125.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.1.1 PlaceMedia . . . . . . . . . . . . . . . . . . . . . . . . . 1145.1.2 Lab Monitor . . . . . . . . . . . . . . . . . . . . . . . . 1165.1.3 Environment Browser . . . . . . . . . . . . . . . . . . . 1185.2 System Integration . . . . . . . . . . . . . . . . . . . . . . . . . 1195.2.1 Campus Composite Environment Model . . . . . . . . . 119Table of Contents viii5.3 Adapter Design and Implementation . . . . . . . . . . . . . . . . 1205.3.1 Equip Component Toolkit Adapter . . . . . . . . . . . . 1215.3.2 Context Toolkit Adapter . . . . . . . . . . . . . . . . . . 1225.3.3 iROS Adapter . . . . . . . . . . . . . . . . . . . . . . . 1265.3.4 MUSEcap Adapter . . . . . . . . . . . . . . . . . . . . . 1285.3.5 Adapter Implementation Summary . . . . . . . . . . . . 1305.3.6 Adapter Design Process . . . . . . . . . . . . . . . . . . 1315.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1345.4.1 Application Development . . . . . . . . . . . . . . . . . 1345.4.2 Adapter Complexity . . . . . . . . . . . . . . . . . . . . 1355.4.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . 1355.4.4 The UIF as a Stand Alone System . . . . . . . . . . . . . 1415.5 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . 1415.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . 1476.1 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . 1496.1.1 A Common Model for Ubiquitous Computing is Usefuland Practical . . . . . . . . . . . . . . . . . . . . . . . . 1496.1.2 Unifying Environment Model is the Key to Integration . . 1506.1.3 Entity Types and Relationships are Important Subclassesof Context . . . . . . . . . . . . . . . . . . . . . . . . . 1506.1.4 Systems Share Several Common Event Types . . . . . . . 1506.1.5 Applications are Both Consumers and Producers . . . . . 1516.1.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 1516.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1526.2.1 Enhancing and Specializing the UCM . . . . . . . . . . . 152Table of Contents ix6.2.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 1526.2.3 Improved Scalability . . . . . . . . . . . . . . . . . . . . 1536.2.4 Improved Application Interface . . . . . . . . . . . . . . 1536.2.5 Applications as Components . . . . . . . . . . . . . . . 1546.3 In Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155xList of Tables2.1 Summary of Surveyed Component Composition Systems. . . . . . 212.2 Summary of Surveyed Context Frameworks. . . . . . . . . . . . . 282.3 Summary of Smart Space Systems. . . . . . . . . . . . . . . . . . 332.4 Summary of Wide Area Systems. . . . . . . . . . . . . . . . . . . 392.5 Summary of the Abstractions Used by Ubicomp Systems. . . . . . 455.1 ECT Adapter UCM Abstractions . . . . . . . . . . . . . . . . . . 1225.2 Context Toolkit Adapter UCM Abstractions . . . . . . . . . . . . 1235.3 UCM Abstractions Mapped to the iROS System . . . . . . . . . . 1275.4 UCM Abstractions Mapped to the MUSEcap System . . . . . . . 1295.5 Adapter Implementations by UCM Abstraction . . . . . . . . . . 1315.6 Components of UIF Overhead . . . . . . . . . . . . . . . . . . . 1375.7 Query Time as (Static) Model Size Increases . . . . . . . . . . . . 139xiList of Figures1.1 Ubicomp deployments under a common model. . . . . . . . . . . 32.1 Ubicomp systems surveyed by scale and abstraction level. . . . . 193.1 Smart campus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.2 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.3 The three aspects of the Ubicomp Common Model . . . . . . . . 583.4 Environment State abstractions and relationships. . . . . . . . . . 593.5 Environment Meta-State abstractions and relationships. . . . . . . 613.6 Environment Implementation abstractions and relationships. . . . 623.7 Key objects and relationships of the UCM. . . . . . . . . . . . . . 633.8 Example State, Meta-State and Implementation aspects. . . . . . . 643.9 Access control property associated with capabilities. . . . . . . . 693.10 Example of AC properties used to mark security domains. . . . . 703.11 Access control and security example. . . . . . . . . . . . . . . . . 733.12 Example of capabilities restricted by UIA personal group. . . . . . 744.1 Ubicomp Integration Framework Architecture. . . . . . . . . . . . 894.2 High level interaction between UIF subsystems. . . . . . . . . . . 904.3 Key classes of Environment Composition Logic. . . . . . . . . . . 974.4 Sequence diagram for Facade.callService(). . . . . . . . . . . . . 98List of Figures xii4.5 Key classes and interfaces of Component Container subsystem. . . 1044.6 Key classes of the Adapter framework. . . . . . . . . . . . . . . . 1085.1 Composite campus environment deployment. . . . . . . . . . . . 1135.2 PlaceMedia user interface. . . . . . . . . . . . . . . . . . . . . . 1155.3 Lab Monitor application user interface. . . . . . . . . . . . . . . . 1175.4 Environment Browser user interface. . . . . . . . . . . . . . . . . 1185.5 Composite environment model. . . . . . . . . . . . . . . . . . . . 1205.6 Average latency vs. number of active polling applications. . . . . 1365.7 Latency of queries when model changes. . . . . . . . . . . . . . . 1385.8 Time required to update a model after a change. . . . . . . . . . . 140xiiiList of Programs3.1 Example Environment State RDF fragment. . . . . . . . . . . . . 603.2 Example Environment Meta-State RDF fragment. . . . . . . . . . 624.1 AdapterListener interface. . . . . . . . . . . . . . . . . . . . . . 1064.2 Adapter interface. . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.1 Component description for a Context Source. . . . . . . . . . . . 125xivGlossaryAdapter Software component that maps heterogeneous data, interfaces and pro-tocols to a common model and data format. 83AdapterManager The UIF Message Broker implementation that mediates inter-action messages between the UIF and its adapters. 99Component Container UIF subsystem that hosts ?native? UCM components in-stantiated by the system. 89Context Widget A Context Toolkit software component that provides access tocontext information in their operating environment. Applications can querytheir state or subscribe to context changes[34]. 29DataObject UIF internal object used as a generic data structure designed for mar-shaling to SOAP and integrated systems. 93Dataspace A data sharing service similar to a tuplespace used in the EQUIP Com-ponent Toolkit (ECT) to relay events and share state between software com-ponents [46]. 25Discoverer A Context Toolkit software component used by applications to locatecomponents such as Context Widgets and Aggregators that are of interest tothem based on the attributes (e.g., location, username) it is interested in.[34].29Glossary xvEnterprise JavaBeans A component model for component transaction monitors.There are three types of server-side components called enterprise beans: en-tity, session and message-driven beans 1. 115Entity Aggregator A Context Toolkit software component that is acts as a medi-ator between applications and Context Widgets. It is responsible for all ofthe context about a particular entity (person, place or thing).[34]. 29Environment Composition Logic (ECL) UIF subsystem that dispatches calls tointegrated ubicomp systems and maintains event subscriptions for applica-tions. 89Event Heap A tuplespace based coordination system used in iROS where tuplesare called events, and contain certain mandatory fields for sequencing andgarbage collection [64]. 33Facade In the Facade design pattern [44], the facade is an object that providesa simplified interface to a larger body of code. In the Ubicomp IntegrationFramework, the Facade is a Java object exposed using Web Services thatprovides a single interface to an integrated ubicomp environment. 81ICrafter A service infrastructure for the iROS system that includes service aggre-gation and user interface creation and selection [82]. 53Java 2 Enterprise Edition Version of the Java Platform used for the developmentand deployment of enterprise applications [97]. The latest version of thissystem is now simply called Java Platform, Enterprise Edition (Java EE)[98]. 921[75] pp 23-24Glossary xviJavaBeans A software technology for building reusable Java components called?beans?. Beans are Java classes that follow a convention for naming, con-struction and behavior for reuse and manipulation visually in a builder tool[96]. 25Message Broker A software intermediary that broker's messages between int e-grated systems. 6Model and Reasoner UIF subsystem that maintains the current environment modelincluding the UCM itself, specializations of the UCM, entity instances, staticcontext values, capabilities, component descriptions and their relationshipsusing a knowledge base and associated reasoning engine. 89OWL Web Ontology Language. 56RDF Resource Description Framework. 10Session Bean A type of server-side component used in Java-based componenttransaction monitors typically used to implement application logic. See alsoEnterprise Javabean 2. 1282[75]xviiAcknowledgementsThis work would not have been possible without the help, encouragement and fi-nancial support of my supervisors Dr. Rodger Lea and Dr. Charles 'Buck' Krasic.It is difficult for me to overstate my appreciation to Dr. Lea. After first meeting hequickly become not only a good friend but a mentor, helping me focus my thesisresearch, providing valuable feedback and by introducing me to other researchersin the ubiquitous and pervasive systems community.I wish to thank Dr. Krasic for taking me on as his first PhD student. I amgrateful for his open door policy, for the time that he spent with me brainstorming,challenging my ideas, for his feedback and support both academically and career-wise.Thank you to the National Sciences and Engineering Research Council ofCanada for their finanical support for my first two years of study, and for the Uni-versity of British Columbia University Graduate Fellowship program for my thirdyear.I'd also like to thank all of my friends and colleagues. While I can't thankeveryone, I must single out a few people: Kan Cai, Matt Finke, Tony Tang, AimanErbad, Nicole Arksey, Phillip Jeffrey, Meghan Deutcher, Rock Leung, Nels An-derson, Vincent Tsao, Crystal Giesbrecht, and Gavin Tian for their collaborationand feedback. Thank you to Dr. Adrian Friday for his help organizing Ubisys andCMPPC workshops, and for his feedback during his visit to MAGIC and for hisAcknowledgements xviiihospitality during my visits to Lancaster.I cannot finish without saying how grateful I am to my family for their encour-agement and support. I dedicate this thesis to my beautiful wife Kim, my sonsDanny and Marcus, and to my parents.1Chapter 1Introduction and MotivationUbiquitous computing (ubicomp) is a compelling vision for how computing re-sources will become an integral part of our daily lives [108]. In future living andworking environments, such as our homes [25], schools [49], meeting rooms [83]and hospitals [16], sensors and services embedded in an environment can be usedby applications hosted on portable devices such as laptop computers, smart phones,personal entertainment devices, or in the environment itself.To support this vision, a variety of middleware, toolkits, and operating systemshave been created. Over time, these innovative and pioneering systems have ma-tured to address many research issues both unique to ubiquitous computing and/orinherited from distributed systems. These include such issues as hiding the hetero-geneity of underlying infrastructures, scalability, dependability, security, privacy,spontaneous interoperation, mobility, context awareness, context management, ap-plication mobility, and human computer interface issues [32]. While this com-pelling vision has inspired much research in all of these areas, after more than 15years ubicomp systems have (mostly) been confined to lab prototypes and relativelylimited deployments. Many reasons have been cited for this lack of deployment[33]. In some cases it can be difficult to persuade others to use a non-standardtechnology; perhaps there is a perception that, as research prototypes, softwarequality and ongoing support from their creators will be questionable [95]. Thatsaid, even when researchers have attempted to leverage open infrastructure andChapter 1. Introduction and Motivation 2middleware standards such as the Open Systems Gateway Initiative (OSGi) [80] orWeb protocols (e.g. [68]) ubicomp systems still have not been widely adopted.Without agreed apon standards, or even a set of best practices on how to buildubicomp systems, designers have primarily focused on supporting applications anduser access within single administrative or network domains. This has led to `is-lands' of ubicomp installations specialized for specific applications, physical lo-cations and devices. Unless a solution can be found, the lack of standards or acommon platform will continue to be an impediment to the widespread adoptionof ubicomp systems in the `real world'.To bridge islands of existing and future ubicomp deployments, we propose thedevelopment of a common model for ubicomp systems that facilitates a mappingto existing ubicomp systems' programming models. This will allow developers tocreate new applications, assured that a suitable intermediary or gateway will allowtheir application to run on existing systems. It will also support the developmentof cross domain applications, allowing developers to bridge islands of ubicompdeployments. Furthermore, we argue that the development of a common model isa first step toward standardization of ubicomp deployments and the establishmentof a common reference platform.The current deployment situation for many ubicomp systems is illustrated inFigure 1.1 (a). Application 1 and 2 are dependent on ubicomp environments Aand B respectively. These applications can only access environment resources thatthey are designed for, and only (typically) within the same administrative and net-work domain. With a common model and supporting infrastructure, applicationscan make use of environment resources across domain boundaries, independent oflocation and ubicomp system used as shown in Figure 1.1 (b). Moreover, disparateubicomp systems can be integrated under a single integrated environment modelas shown. Environments can be composed to integrate environment resources suchChapter 1. Introduction and Motivation 3Environment A Environment BApplication 1 Application 2Domain Boundary (a) Existing ubicomp deploymentsCommon Model andIntegration SystemAdapter BEnvironment A Environment BApplication 3 Application 4 (b) Integrated deploymentsFigure 1.1: Current and future integrated ubicomp deployments under a com-mon model.as smart meeting rooms, and classrooms across larger physical locations such as acities, campuses or buildings or across branch locations of a company.The question then arises, if a common model for ubicomp is needed for appli-cation portability and systems interoperability, why one has not been proposed bythe research community? To understand these issues, the author helped organizetwo workshops: Systems Support for Ubiquitous Computing (Ubisys) at Ubicomp2006, and Common Models and Patterns for Pervasive Computing (CMPPC 2007)at Pervasive 2007.Several submissions and discussions at Ubisys '06 were focused on commonabstractions, and models toward interoperability and portability supported by sys-tems and tools[70]. At CMPPC 2007, participants agreed that many existing sys-tems can serve as examples for techniques, best practices and design patterns forubicomp1. Both of these workshops helped shape this thesis, especially the dis-1see http://www.ubisys.org/index.php/Main/CmppcResultsChapter 1. Introduction and Motivation 4cussions on patterns, techniques and guidelines at CMPPC2. We have begun todocument the collective experience of the ubicomp and pervasive systems com-munity into an online resource3. In one area of this community portal we havedocumented specific patterns and techniques such as the use of Event Brokers, Webservices, and entity aggregation used in a variety of systems and captured in ourwork [20?23, 40].While consensus on a programming model is recognized an important longterm goal, this workshop participation highlighted the fact that agreement on oneis far from straightforward for two reasons. One is that the field continues to evolve.Researchers are still exploring not only implementation issues, but the abstractionsand programming models for ubicomp applications themselves (e.g. [14, 48, 56]).While creating a reference platform is eventually achievable, we feel it is imprac-tical to settle on one while new abstractions and implementations continue to beexplored. Furthermore, we argue that even in the long term, the use of the sameprogramming model and supporting middleware platform in all smart spaces isnot realistic as there will always be cases where systems specialized for specificapplications and locations will be deployed in particular environments.Given these observations, it is clear that there will always be a variety of ubi-comp platforms and hence, there is a need to develop a methodology that supportsthe integration of specialized platforms as they evolve. This will allow developersto continue to create environment-specific applications, while others can create in-tegrated ubicomp deployments, and applications that are portable between sites andadministrative domains. Such an approach will ensure systems developers can con-tinue to evolve their platforms while supporting a growing application developercommunity. However, the development of such a methodology is not straightfor-2see http://www.ubisys.org/index.php/Main/PatternsTechniquesGuidelines3http://www.ubisys.orgChapter 1. Introduction and Motivation 5ward, and there are several technical and non-technical challenges to address.1.1 ChallengesUnlike systems deployed within a single domain, services used between organiza-tions over the wide area Internet are exposed and managed carefully by adminis-trators. Maintaining autonomy and ensuring underlying services are accessed in asecure manner by authorized users is therefore critical.It is also important to provide a mechanism for resolving protocol and inter-face mismatches between systems. In closed environments, this is easily resolvedby using the same types of hardware, or by wrapping devices and software ser-vices using the same middleware. Previous efforts to address this have includedthe use of device-hosted middleware that expose a single interface for service dis-covery and binding mapped to various service architectures [43, 45] or middlewarethat advocates a generic set of interfaces for the rapid assembly of components[47, 76]. While these approaches suffice when integrating individual services andcomponents, they are not feasible when entire middleware systems with a varietyof APIs and programming models must be integrated.Another problem is that ubicomp systems to date support a range of abstractionlevels. Some systems expose high level abstractions such as explicit environmentmodels (e.g. [11, 25]) while others support simpler component or service abstrac-tions (e.g. [47]). Systems have been designed to support a range of deploymentsfrom small scale, ad hoc, single task-oriented configurations of devices [76], tolarge scale integrated campus environments [49]. A system that integrates thesesystems must be able to ?understand? not only a simple component or service ab-straction, but higher level concepts exposed by existing ubicomp APIs such asphysical entities (people, places, things), context [35] and environments.Chapter 1. Introduction and Motivation 6Since ubicomp environments are highly dynamic, any supporting system mustbe self organizing to some degree. An integration platform must be able to adapt tothe addition and removal of resources exposed by a variety of internal middlewareplatforms.Finally, users should be able to access computing resources around them usinga variety of personal computing devices such as PDAs, personal music players ormobile phones using a wide variety of client software such as mobile browsers andcustom clients.1.2 Integration ApproachTo begin to address these challenges, we can look toward progress in other domainssuch as enterprise application integration (EAI). The development of distributedenterprise applications has been supported by the rapid evolution of middlewaretechnology. This technology has moved from supporting single-tier mainframeapplications, to distributed object technologies such as Common Object RequestBroker Architecture (CORBA) [79], and eventually to the use of message brokersto integrate complete heterogeneous applications across an organization.Similarly, designers of ubicomp environment systems have leveraged tradi-tional middleware technologies to address issues such as device and service in-terface heterogeneity. Like many ubicomp systems, enterprise systems have alsobeen restricted for use in single local area networks for various reasons. Whilearchitectures based on distributed objects and message brokers have proved effec-tive in integrating applications in a single network, they have not been effectivebetween enterprises and network domains. One of the biggest problems in achiev-ing inter-enterprise integration has been the lack of standards at the middlewareand component levels. To address this, the enterprise integration community hasChapter 1. Introduction and Motivation 7turned toward the use of Web technologies.The Web emerged initially as a technology for sharing information across theInternet. With the introduction of Web services, however, it has also become amedium for application integration. More specifically, Web services have been es-tablished as a way to expose the functionality of an information system (or groupof systems) to applications in other companies, across network and administrativedomains. Web service standards have already made significant progress toward re-solving the limitations of conventional middleware platforms. Standardization inkey areas needed for cross-domain interoperation have included an interface defi-nition language [105], wide-area service discovery [2] and protocols for tunnelingprocedure calls within HTTP requests and responses [104]. Web services addressa specific purpose: to expose functionality in an information system and make itdiscoverable and accessible over the wide area Internet in a controlled manner.Conceptually Web services are wrappers to encapsulate one or more applicationswith a unique interface available across the Internet.When we compare the evolution of ubiquitous computing environments withthat of enterprise application integration, they have followed a similar trend. Ini-tially, small scale ubicomp research projects assumed homogeneous interfaces tosensors and actuators, and processing related to the environment and the applica-tion has been blurred. To minimize the amount of programming required to createnew applications, researchers have recognized the need to support heterogeneousdevice interfaces, and have provided middleware services to isolate application-specific logic from issues related to device heterogeneity, location, protocols, andnon-application specific processing of sensor (context) information.More recently, service-oriented architectures such as Universal Plug and Play[74] and OSGi [80] have been leveraged for even greater modularity and extensi-bility within an environment [51]. While the use of standard protocols and serviceChapter 1. Introduction and Motivation 8oriented architectures such as those supported by Web services are necessary firststeps toward cross domain interaction, they are not sufficient for application porta-bility and ubicomp system interoperability. Now that internal middleware for ubi-comp environments has matured for single domains, deployment of interoperablesystems that reach across domains will require appropriate external middlewareand a common programming model for ubicomp. To achieve this, we must alsoconsider the higher level abstractions and programming models exposed by ubi-comp systems so far.1.3 Ubicomp Programming ModelsMany ubicomp systems to date have focused on providing an easily understoodprogramming model to access sensors, services and other environment resources(e.g. [11, 36]). Others have focused on service or device interoperability (e.g.[47, 74, 76]) or large scale infrastructures for sharing context information [58, 77].Designers have focused on addressing the requirements specific application do-mains such as collaboration, or locations such as meeting rooms and the home. Wemaintain that there is such diversity in the deployment objectives and approach ofan individual system that no one system is suitable for both application portabilityand integration of other systems.One issue is that a given system does not consider the variety of programmingmodels that other systems expose for effective interoperability and integration.Rather, they aim to provide a homogeneous interface to the variety of services,sensors and actuators in a single environment. If the chosen integration platform'sprogramming model provides low level abstractions, it may not leverage many ofthe higher level capabilities available to application developers by an underlyingsystem. Conversely, if the integrated programming model is too high level, it mayChapter 1. Introduction and Motivation 9not be able to compensate for the missing abstractions in an integrated system.For example, the ParcTab system maintained a set of variables aggregated byenvironment servers representing entities such as people, places or groups [91].Similarly, the Context Toolkit used Entity Aggregators to provide a `one stop shop'for context data about an entity [36]. These systems both made it easier for appli-cations to find relevant context by aggregating information around entity compo-nents. Both iROS [83] and Gaia [87] systems highlight the value of a multi-devicepublish-subscribe event infrastructure for smart spaces. Applications can listen for,and produce events to interact with multiple devices. Both of these systems providewell understood and useful abstractions for application development, however, wemaintain that it is not straightforward to use the ContextToolkit to expose the capa-bilities of the EventHeap that iROS applications expect ? there is no central eventproducer in the system. Nor is it an easy task for the iROS system to provide a wayfor applications to find and query an entity aggregator component ? none is definedexplicitly in the iROS programming model. A new system designed for abstrac-tion mapping is required. The abstractions this system supports must be based ona thorough analysis of these important systems and others.1.4 Research FocusWhile there are many challenges in creating a common model that lends itself toapplication portability and interoperability between systems, our research focuseson the following:? The design of an extensible core model for adequately describing a repre-sentative subset of existing ubiquitous computing environments deployed todate. This model must lend itself to application portability and interoperabil-Chapter 1. Introduction and Motivation 10ity between different environment domains such as the home, the office andpublic places.? Providing a flexible and extensible platform to adapt representative systemsto this model. This includes systems that support small to large scale deploy-ments, those that expose a range of programming abstractions not specific toubicomp like services and components to more ubicomp-specific abstrac-tions like context and entities.The foundation of this work is the design of the Ubicomp Common Model(UCM), a programming model that aims to unify the abstractions of a variety of ex-isting ubicomp systems. We describe the UCM using Semantic Web languages: theWeb Ontology Language (OWL) [102] built on the Resource Description Frame-work (RDF) [101]. With such a model, we hypothesized that an integration systemcan be designed to map a single API to the interfaces of existing systems with ad-equate coverage of the underlying functionality. The design of the UCM is basedon the following assumptions:1. The programming models of ubicomp systems deployed to date share certainprogramming abstractions specific to the ubicomp domain.2. These abstractions can form the basis for a core programming model suitablefor the development of interoperable applications that can make use of somesubset of the functionality of any underlying ubicomp system.3. This core programming model can be used to unify the programming modelsand capabilities of more than one system into composite environments.To validate these claims, we conducted an extensive survey and analysis ofexisting commercial and research ubicomp systems. Based on this analysis weChapter 1. Introduction and Motivation 11identified the abstractions that recur in the programming models of several sys-tems: environment models, entities, context, entity relationships, services, eventsand data. These abstractions formed the basis for the design of the UCM, a coremodel for ubicomp systems.To evaluate the UCM, we developed an integration platform called the Ubi-comp Integration Framework (UIF). The UIF is a flexible and extensible meta-middleware platform based on Web services standards used to integrate ubicompsystems using the UCM and expose its capabilities to applications across networkand administrative domains. With this system we can provide an API for applica-tion interoperability and portability while allowing underlying systems to continueto specialize and evolve.This thesis provides details of our analysis and design of the UCM, the designand implementation of the UIF, and evaluation of both for application developmentand integration with several representative systems. The thesis for this dissertationis as follows:The identification of common abstractions used by existing ubicompsystems contributes to a core common model for integrated ubiquitouscomputing environments suitable for both application interoperabilityand mapping to existing ubicomp systems' interfaces.The primary contributions of this thesis are:1. A comprehensive survey of existing systems categorizing systems in termsof their level of abstraction and scale of deployment highlighting the com-mon abstractions used by these systems exploited in the design of a commonmodel for ubiquitous computing.2. The design of a core model for ubiquitous computing called the UbicompChapter 1. Introduction and Motivation 12Common Model shown to unify the exposed abstractions of several repre-sentative ubicomp systems.3. A demonstration of the feasibility of using the UCM to map to the abstrac-tions of several representative systems.4. Confirmation that this model is adequate for application development.Our secondary contributions include:1. A novel meta-middleware architecture and implementation for integratingmore than one ubicomp system under a common model.2. The use of an integrated knowledge base and reasoning to describe and main-tain an integrated ubicomp environment composed of more than one ubi-comp system.1.5 Thesis OutlineThe remainder of this thesis is organized as follows. In Chapter 2 we present acomprehensive survey and analysis of representative ubiquitous systems. Based onthis survey we identify the common programming abstractions used as the basisfor the UCM design. In Chapter 3 we present the design of the Ubicomp Com-mon Model including the three key aspects of the model: the Environment State,Meta-state and Implementation. In Chapter 4 we describe the design and imple-mentation of the Ubicomp Integration Framework, used to evaluate the UCM byproviding a single environment model and associated API to four underlying sys-tems [36, 40, 47, 83]. Our evaluation and discussion is presented in Chapter 5where we discuss the development of several prototype applications, integrationChapter 1. Introduction and Motivation 13adapters and performance of the UIF. We conclude the dissertation in Chapter 6with a discussion of lessons learned and future work.14Chapter 2Survey and Analysis ofUbiquitous SystemsThe design of a common model for ubicomp suitable for integration depends on anunderstanding of existing systems' programming abstracti ons. As in any softwareengineering task, the use of abstraction in a ubicomp system has two main benefits.Firstly, it helps manage complexity for developers by exposing important aspectsof a system hiding unimportant details. Secondly, it separates aspects of a systemthat are common to all from those specific to a particular implementation. In thischapter we survey a broad range of representative ubicomp systems to highlightthe individual programming abstractions they expose to application developers.Based on this survey, we then derive a set of abstractions that occur across severalsystems, giving names and examples for each. These abstractions are the basis ofthe Ubicomp Common Model presented in Chapter 3.When we survey the wide variety of systems, we note that finding the mostappropriate programming model is not straightforward: there are often tradeoffsrelated to finding the ?right? level of abstraction. For ease of application develop-ment, ?high level? abstractions can relieve the developer from having to deal withcertain implementation details, but for broad applicability it is often more feasibleto expose ?low level? abstractions that expose more details to the developer.For example, some ubicomp systems expose distributed components or ser-Chapter 2. Survey and Analysis of Ubiquitous Systems 15vices to applications, what we consider ?low level? abstractions. Developers createapplications by composing these building blocks by various means. This includesthe use of generic interfaces and mobile code [76], linking compatible componentproperties [47], or through the use of standard interface definitions [74]. Othersystems provide higher level abstractions that more closely reflect the overlap ofphysical and digital space in an effort to make programming pervasive spaces moreintuitive. To do this, systems will often associate relevant information and serviceswith physical or virtual entities such as people, places, and things. These entityabstractions often act as aggregators or containers for relevant information fromsensors and inference services called context. Context may include the user's cur-rent location and activity, the sound and lighting levels in a room, the online statusof a printer, or the names of people in a group for example.The most appropriate programming model may also depend on the scale ofa typical deployment. In smaller scale deployments, where the aim is to supportsimple tasks, a programming model consisting of compositions of service abstrac-tions is often suitable. In room to building-scale deployments with more concur-rent users and applications, programmers can benefit from the use of higher levelabstractions such as explicit environment models that hide individual componentimplementations. In even larger scale deployments such as a university campus,exposing every projector, light switch, media player, large screen display, camera,and thermostat does not scale for user interfaces, applications or integrators. Fur-thermore, wide area communications can be slow and expensive. Consequently,wide area systems tend to aggregate functionality around coarser grained entities,even whole environments federated using wide area protocols.In this chapter we survey and analyse existing systems to identify and namethe abstractions that occur regularly in their programming models to derive thecore abstractions for a common model for ubicomp. The remainder of this chapterChapter 2. Survey and Analysis of Ubiquitous Systems 16is organized as follows. In Section 2.1 we define our categorization of ubicompsystem. In Sections 2.2 to 2.5 we describe each system by category. In Section2.6 we discuss the programming abstractions typically exposed in each categoryand then group these to present our derived set of common abstractions acrosscategories. We conclude this chapter in Section Categories of Ubicomp SystemsGiven the diverse research targets and approaches to systems design, grouping thebroad range of ubicomp systems deployed so far can be challenging. For the pur-pose of this survey, we have gathered systems into four categories as follows:? Component Composition Systems: generally lower level abstractions andsmaller scale deployments? Context Frameworks: medium level abstractions/mid scale environments? Smart Space Systems: higher level abstractions/mid scale environments? Wide Area Systems: low to high level abstractions/large scale deploymentsor cross domain accessThese categories were derived by rating systems in terms of two dimensions:the level of abstraction a system exposes and the scale of a typical deployment,both defined next.2.1.1 Abstraction levelsTo create these four categories we first rated systems in terms of level of abstractionto group systems with similar programming models. We point out that our use ofChapter 2. Survey and Analysis of Ubiquitous Systems 17the phrase ?level of abstraction? does not indicate the quality or applicability ofone system over another, but rather its intended purpose and similarity betweensystems' programming models. Our definition of abstraction levels including someexamples are defined as follows .? Service and Component Compositions (low). Systems that provide a ser-vice oriented architecture or component abstraction are considered to expose?low level? abstractions. Some of these systems will support the compositionof components and services. Example systems include several commercialstandards like UPnP [74] and research systems such as SpeakEasy/Obje [76].? Entities and Context (medium). We consider systems that provide abstrac-tions including the notion of a person, place or thing (i.e. physical or virtualentities), and context to expose ?medium level? abstractions. Systems at thislevel often build on distributed services and component architectures. Exam-ples include the Context Toolkit [36] and the Java Context Aware Framework(JCAF) [15].? Explicit Detailed Environment Models (high). For our survey we rate sys-tems as having a ?high level? of abstraction when they provide an interfaceto an explicit model of the physical environment. The system may includecentralized servers for event brokering and data storage. The environmentmodel may include both mobile and fixed entities like places, tables, wallsand relationships. Example projects include Sentient Computing [54], theNexus project [57] and ontology based systems (e.g. [28, 51]). With anexplicit and centralized model it is possible for the supporting system to rea-son about the situation as a whole, removing the need for applications tomaintain their own model of the current physical and run time environment.Chapter 2. Survey and Analysis of Ubiquitous Systems 182.1.2 Scale of DeploymentTo categorize systems we also consider the scale of deployment targeted by thedesigners. Some systems, for example, focus on the composition of devices fora single mobile user, or only a few users. A given component configuration willgenerally support only only a few simple tasks at a time. Other systems aim to inte-grate several applications, services, devices for all of the users in a room. Mediumscale systems tend to support tens of users, in a meeting room for example, andmany applications at once. Larger scale systems, designed for wide area deploy-ments and infrastructures with many users and applications, target campuses, citiesor the world. To summarize:? Small scale. Sub room, single or few users e.g. on a broadcast network forone (mobile) or a small number of users. This includes ADS, PCOM and theZeroConfig standards for example.? Mid scale. Room, building, floor, single servers, tens of users, several appli-cations. Systems include those that use servers such as iROS and the ContextToolkit.? Large scale. Campus, city, global, wide area networks, federated servers,wide area protocols for many applications and thousands to millions of users.Systems here include Cooltown and ActiveCampus.When we place systems along both the abstraction level and scale axes, asshown in Figure 2.1 we note that there is some correlation between these two di-mensions. Smaller scale systems tend to use service composition (low level) ab-stractions since they are often concerned with composing individual componentscorresponding to devices or software services. When the number of devices, users,and applications increases in medium scale (room-building) systems we see a trendChapter 2. Survey and Analysis of Ubiquitous Systems 19to provide context and entity (medium level) abstractions that aggregate softwareservices and shared state around objects of interest such as people, places andthings - medium level abstractions. Finally, larger systems scale to even moreusers and applications; the abstractions exposed in larger scale systems tend torange from medium to high level explicit environments.Interestingly, while there is some correlation between scale and abstractionlevel, there are examples in the Smart Space and Wide Area Systems categorisethat show these dimensions are orthogonal: medium scale systems with high levelabstractions (e.g. EasyLiving [25]) and large scale systems that provide mediumlevel abstractions (e.g. Cooltown [68]). Based on their approximate location in thescale/abstraction space, we grouped systems into the four system categories usedin the body of this survey as shown.Explicit Environments (High)Service Composition(Low)Sub room Campus GlobalSpeakEasyECTSentient ComputingContext ToolkitNexusConFABActiveCampusJiniiROSRoom- Floor BuildingGaiaEasyLivingAuraPCOMCooltownSentient Objectsone.worldContext and Entities (Medium)OntologySystemsJCAFScale of DeploymentReMMoCZeroConfigOSGiParcTabComponent Composition SystemsContext FrameworksSmart Space SystemsWide Area SystemsWSAMI  Abstraction Level Figure 2.1: Ubicomp systems surveyed placed in terms of scale and abstrac-tion level.Chapter 2. Survey and Analysis of Ubiquitous Systems 202.1.3 OrganizationIn the following four sections we present representative systems in each category:Component Composition Systems, Context Frameworks, Smart Space Systems,and Wide Area Systems in rough chronological order. This not only gives a senseof the features of a category, but also of the evolution of abstractions within thatcategory as research progressed. Where a system can be considered to be in morethan one category we have placed it in the section where it shared the most fea-tures of other systems. In each section we begin by providing a table with a rowfor each system, summarizing the purpose of its design (e.g. programmability orinteroperability or both), its scale, abstractions, and key references. This is fol-lowed by a description of the system with attention to the programming model andabstractions it exposes. To respect the significant contributions of these projects,we describe the abstractions of each system using the names used by the designersin each subsystem. We then summarize the important abstractions shared acrossseveral systems in a final subsection at the end.2.2 Component Composition SystemsThe first section of our survey presents systems generally used in smaller scaleubicomp environments that provide a ?lower level? abstraction for component reg-istration, discovery, communications and composition. Unlike other categories ofsystems in this survey, several commercially used systems belong here: Jini, Uni-versal Plug and Play (UPnP), and Zero Configuration Networking (ZeroConf) arediscussed in Section 2.2.1. These systems can be used directly for ubicomp ap-plication development since they were designed for a changing distributed execu-tion environment. Another commercial standard presented in Section 2.2.1 is theChapter 2. Survey and Analysis of Ubiquitous Systems 21Open Systems Gateway Initiative (OSGi), which provides a centralized, dynami-cally extensible execution environment. The Appliance Data Services (ADS) sys-tem (2.2.2), SpeakEasy (2.2.3), the Equip Component Toolkit (2.2.4), and PCOMresearch systems (2.2.5) all compose software components, often corresponding todevices in an environment. ADS and PCOM compose services automatically whileSpeakEasy and ECT allow end users to compose device components for data trans-formation, display and storage. The Reflective Middleware for Mobile Computing(2.2.6) system provides a single API for several distributed component systems.The systems surveyed in this section are summarized in Table 2.1.Table 2.1: Summary of Surveyed Component Composition Systems.System Purpose Scale Abstractions RefsJini Interoperability Small-medium:lookup servicesObject registration, dis-covery, services, events,transactions[106]UPnP Interoperability, sim-ple device networkingSmall-medium:broadcast net-workDevice registration, dis-covery, services, state,events[74]ZeroConfig Interoperability, sim-ple networkingSmall-medium:broadcast net-workService registration, dis-covery[13, 29]OSGi Dynamically extensi-ble service host plat-formMedium: room-houseBundle (object collections)registration, discovery,services, state, events[80]ApplianceDataServicesTask based compo-sition of services fordata transformation/-transferSmall: collectionof devicesTasks as sequences ofservice executions ondata hosted in infrastruc-ture[60]SpeakEasy/ObjeEnd user compositionof devices/compo-nents for data transferSmall: collectionof devicesObjects with generic in-terfaces for data transfer,grouping, metadata andUI[76]Equip Com-ponentToolkitEasy end usercomposition of com-ponents for controland data processingSmall: collectionof devicesComponents contained ina DataSpace linked usingcompatible properties/s-tate[47, 61]PCOM Automatic and dy-namic composition ofservicesSmall-medium:broadcast net-workServices composed dy-namically using depen-dency contracts[17, 18]ReMMoC Interoperability withvarious service in-frastructuresSmall-medium::broadcast net-workAbstract service discov-ery, reflection and interac-tion interface[45]Chapter 2. Survey and Analysis of Ubiquitous Systems 222.2.1 Commercial Systems and StandardsCommercial systems described in this section have been developed to create ap-plications that can dynamically adapt to a changing network environment: a keyrequirement for ubicomp. Most expose the ability to communicate with individualsoftware components that may come and go to get and change state, subscribe toevents, and call services.Jini. Jini was designed to provide a way for distributed objects to find eachother and work together on a network. Its use of mobile code and support for dy-namic service registration and discovery make it an obvious starting point for ubi-comp systems. A fixed Lookup Service is deployed on a network for lease-basedcomponent registration and lookup. A client will typically search for a Lookup Ser-vice using multicast, then find the service it needs using a template-based search.The proxy code needed to communicate with the service is downloaded from theLookup Service to communicate with it directly. Clients can register for asyn-chronous event notifications by registering their own remote service interface.Universal Plug and Play (UPnP). The purpose of UPnP is to make it easyto set up and configure networked devices such as printers, Internet gateways andconsumer electronics without the need for specialized servers or other infrastruc-ture. There are three building blocks of a UPnP system: a Device is a containerfor services and other nested devices, Services are units of control consisting ofstate variables, implementations of actions, and an event server implementation,to publish events to subscribers when its state changes. Finally, applications asControl Points discover and control other devices by invoking services, subscrib-ing to events, and getting device and service descriptions. A protocol is used fordevices to announce themselves and for control points to find resources, no dis-covery server is needed; every control point maintains information on the devicesChapter 2. Survey and Analysis of Ubiquitous Systems 23available to minimize traffic.Zero Configuration Networking (Zeroconf). Zeroconf, also known as Bon-jour and Rendezvous [13] is a collection of standard and proposals used by Applefor dynamic discovery of devices and services on IP networks. These specifica-tions include dynamic link local addressing, multicast domain name system (DNS)for use in small networks such as the home, where there is no conventional unicastDNS server, DNS based service discovery, DNS related notifications, and proto-cols for printing and file sharing. Unlike Jini and UPnP, Bonjour does not includespecific mechanisms and protocols for service interaction, applications use anyprotocol on top of TCP or UDP.OSGi. The Open Services Gateway Initiative Alliance defines a Java basedplatform that defines a dynamic life cycle model for modules called bundles, whichcan be remotely installed and started without rebooting the system. It also includesa service registry to detect the addition and removal of services for applications toact accordingly. Many layers are built on this core including services for logging,administration, security, and integration with systems such as UPnP. Although itwas originally designed for service gateways, it is now used in a wide range ofapplications such as integrated development environments, enterprise applicationservers, cars and mobile phones.2.2.2 Appliance Data ServicesThe designers of ADS [60] recognized that the use of distributed services and de-vices such as those supported by Jini or UPnP often revolves around moving datafrom one to another. Unfortunately, in some cases, this task can be unexpectedlydifficult. ADS addresses this problem by allowing developers to define tasks suchas ?move photos from camera to online photo album?. ADS applications are aChapter 2. Survey and Analysis of Ubiquitous Systems 24composition of services that operate on data or content supplied by devices. Theframework consists of three components: Data Receive, Application Control andService Execution. Data is received from a device, and put into the infrastructure,a shared data store, by the Data Receive components. Application Control compo-nents determine the task to perform by looking at a user id and requested commandto find a matching template listing the services required. The Execution Compo-nent executes services in turn to operate on the data supplied in the receive stageor output by a previous service as defined by control template. A key abstractionintroduced by ADS is the notion of a service composition they call an applicationand the support for data as an abstraction in the system passed between services.2.2.3 SpeakEasy/ObjeSpeakeasy researchers decided to take a different approach from ADS to movingdata between devices. Unlike the ADS system, SpeakEasy allows end users toopportunistically assemble devices for data exchange, even when the devices donot support the same data protocols [76]. Unlike ADS which relied on compatibleservice interfaces for composition, the system uses mobile Java code to translatepotentially incompatible data streams between components and to supply inter-faces for end user control. Every component, typically corresponding to a physicaldevice or software service on a local network, exposes one or more of a small setof generic interfaces. These interfaces are used to (1) transfer data, (2) group re-lated components together (3) reveal and use metadata about the component, and(4) allow end user control with a user interface. SpeakEasy component interfacesallowed end users to easily compose and control devices for data transfer and pro-cessing.Chapter 2. Survey and Analysis of Ubiquitous Systems 252.2.4 Equip Component ToolkitWhile components in Speakeasy communicate with each other directly using genericinterfaces, the Equip Component Toolkit exploits the use of a shared, distributedDataspace to create component compositions. The Dataspace contains referencesto software components such as JavaBeans, the current value of their properties,and links between compatible properties. Applications are created by ?wiringup? compatible properties, so that when the value of one property in a compo-nent changes, its value is relayed to the property in another component. End usersand developers can instantiate and configure components in the Dataspace usinga graphical editor such as the supplied GraphEditor, or the Jigsaw puzzle editor[61]. A key advantage of the system is the ability for components to interoperateby connecting properties; no common service API or mobile code is required.2.2.5 PCOMIn mobile applications, the services available in an environment may come and goover time. To use a commercial system like Jini or UPnP, applications must adaptthemselves to the changing resources they need at run time. Another approach isfor a system like PCOM to relieve applications from this responsibility. PCOM wasdesigned to adapt automatically to changing protocols, and the services available.It assembles service hierarchies dynamically based on application-programmer de-fined service dependency contracts. Application programmers provide service re-quirements (events and service interfaces) in advance. PCOM then creates a hierar-chy of services dynamically to fulfill the contracts using the current and changingservice execution environment. Application programmers can use built-in PCOMadaptation mechanisms or provide their own strategies to reselect or discontinuerequired components at run time as the environment changes.Chapter 2. Survey and Analysis of Ubiquitous Systems 262.2.6 Reflective Middleware for Mobile Computing (ReMMoC)Similar to PCOM, ReMMoC addresses the problem of clients finding and makinguse of appropriate services in ubiquitous computing environments. However, un-like PCOM, ReMMoC makes use of existing service infrastructures directly. Insuch environments, different service discovery protocols may exist such as Jini,UPnP or ZeroConf. In addition, different interaction protocols such as SimpleObject Access Protocol (SOAP), or Common Request Broker (CORBA) InternetInter-Orb Protocol (IIOP) may be used. The ReMMoC mobile device middle-ware uses a pluggable component architecture to address both service discoveryand interaction heterogeneity. A generic service lookup interface hides the detailsof different service discovery protocols. A generic binding abstraction, based onWeb Service Definition Language (WSDL) allows for the abstract definition of anyservice independent of the underlying service provider.2.2.7 DiscussionSystems in this category revolve around the use of distributed components exposedusing a service abstraction. The ReMMoC system provided a generic service APIfor systems such as UPnP and Jini. Several systems in this category also provideaccess to component state or properties, and asynchronous events or service call-backs. In several of these systems, applications are considered to be compositionsof components composed or connected to perform some task. For example, ECTdevelopers can compose components using a Dataspace that encapsulates all com-ponents and their property links in a deployment. PCOM composes services auto-matically and dynamically as the execution environment of an application changes,without centralized infrastructure. The ADS system introduced a data abstractionto pass between services in predefined compositions. SpeakEasy users composeChapter 2. Survey and Analysis of Ubiquitous Systems 27devices on the fly to transfer and process data. To summarize, these systems typi-cally support the composition of components that expose service, state, events, anddata or state abstractions.2.3 Context FrameworksThis category lists those systems designed to make use of context. Dey definedcontext as ?any information that can be used to characterize the situation of en-tities (i.e. whether a person, place or object) that are considered relevant to theuser and an application. . . ? [35]. In the simplest sense, context is some state as-sociated with a physical or electronic entity. Many of the systems here such asParcTab (Section 2.3.1), the Context Toolkit (2.3.2), and the Java Context AwareFramework (2.3.5), include abstractions to aggregate such information about peo-ple, places or things. Several systems such as Sentient Objects (2.3.4) can inferhigher level context information such as user activity and the local weather con-ditions from raw sensor data, external information sources combined with lowerlevel context information such as location and time. For the purpose of this sur-vey, we consider entities and context abstractions exposed by these systems to be?medium? level ubicomp abstractions. The systems listed in Table 2.2 are typicallydesigned for larger installations than Component Composition Systems since theyoften aggregate information and the capabilities of individual components.2.3.1 ParcTabParcTab was a pioneering ubicomp system that leveraged the Remote ProcedureCall (RPC) model for distributed middleware to allow applications hosted on work-stations to interact with users with mobile devices. In later work, Schilit et al. [91]highlighted the need for dynamic customization as a key concept common to ubi-Chapter 2. Survey and Analysis of Ubiquitous Systems 28Table 2.2: Summary of Surveyed Context Frameworks.System Purpose Scale Abstractions Key RefsParcTab Application cus-tomization using stateabout users andlocationsMedium: multipleroomsUser agents and sensorssupply state to Environ-ment Servers correspond-ing to entities: users andlocations[90, 91]ContextToolkitEasy context awareapplication develop-mentMedium: multipleroomsDiscoverer for componentlookup/registration, wid-gets that support contextquery, events, interpretersand entity aggregators[36]one.world App. changing ex-ecution environment,sharing data betweendevicesSmall: broadcastnetworkEnvironments, containdata and components(typically associated withentities), asynchronousevents for all communica-tions[48]Sentient Ob-jectsContext-aware appli-cation development inad hoc network envi-ronmentsSmall-Medium:ad hoc networksDistributed sentient ob-jects (typically associatedwith entities). Eventbased communication,framework for contextreasoning, interpretation,& aggregation[19]Java Con-text AwareFrameworkStandardize Javacontext aware appli-cation APIsMedium: dis-tributed serversEntities associated withcontext items that mayalso be other entities.[15]comp applications. They describe a system made up of a collection of environmentservers each corresponding to users, places, workgroups and other entities. Eachenvironment server maintained a set of names and values corresponding to somerelevant information about the physical or computational run time environment.A user agent updated environment servers on behalf of the user it served. Ap-plications typically monitored for changes in the environment by subscribing tovariable changes on environment servers. An application could subscribe to theenvironment server for a group of users, and to the servers corresponding to thelocations of these users for example. The servers used by a given application couldchange over time as a users location changes. An important abstraction from thisearly work is the environment server corresponding to a place, user, group or otherentity. These servers aggregated relevant state about an entity called context inChapter 2. Survey and Analysis of Ubiquitous Systems 29follow on systems.2.3.2 The Context ToolkitThe Context Toolkit aimed to provide a set of abstractions for the rapid develop-ment of context aware applications. A typical deployment contained a number ofself describing distributed components on a LAN that supply context (e.g. sensordata) and/or services to applications. These components register with a central-ized Discoverer which maintains information for lookup by applications or othercomponents. The component types included Context Widgets which can be querieddirectly or subscribed to using asynchronous events, Context Interpreters used totranslate one form of context to another, for example from an RFID tag reading toa user name. Entity Aggregator components were used to aggregate context andservices around an entity: a person, place or object. Services, typically imple-mented by Context Widgets were exposed to interact with software services andactuators. Recognizing that applications still had to do a lot of work to find andinteract with the various component types provided by the toolkit, the system wasextended to provide a higher level, situation abstraction: a collection of relevantcontext queries (called the situation) in a single interface that deals with multiplecomponents. The Context Toolkit situation abstraction forshadows the ability tomodel whole environments demonstrated by Smart Space Systems in Section One.worldOne.world was designed for ad hoc composition and data sharing between appli-cations and devices in a changing execution environment. To address this need,the designers argue that data and functional abstractions, unlike objects in objectoriented systems that combine these abstractions, should be separated to facilitateChapter 2. Survey and Analysis of Ubiquitous Systems 30data sharing, searching and filtering. To establish this separation, they created anenvironment abstraction as a way of structuring and composing applications. En-vironments serve as storage for shared data using tuples, and containers for appli-cation components and other environments in a hierarchical fashion. Componentsin an environment communicate with each other using asynchronous events. Gen-erally, environments correspond to entities such as people, places or objects andcan migrate from one device to another as a user moves for example. Like ParcTabenvironment servers, and Context Toolkit Entity Aggregators, one.worlds environ-ment abstraction acts as both a container and aggregator for related entity state andfunctionality.2.3.4 Sentient ObjectsThe Sentient Object Model was developed for context-aware application develop-ment in ad hoc network environments. Like one.world, the designers anticipateda degree of mobility, and resilience to changes in connectivity between compo-nents. This model defines abstractions for sensors and actuators and a frameworkfor creating Sentient Objects. Sentient objects retrieve information about their envi-ronment from each other using event-based communications [19], or directly fromsensors. Sentient Objects work independently, and proactively try to achieve goalsand anticipate problems. A framework for creating Sentient Objects makes it easierfor developers obtain, aggregate and interpret context information received by theobject. This framework includes probabilistic reasoning capabilities to interpretraw sensor data, and to derive higher level context from lower level sub contexts ina hierarchical fashion. An entity such as a person, place or thing typically corre-sponds to one or a group of sentient objects in a deployment.Chapter 2. Survey and Analysis of Ubiquitous Systems 312.3.5 Java Context Aware FrameworkThe Java Context Aware Framework (JCAF) is a more recent system used for con-text aware application development. Inspired by previous work like the ContextToolkit, a deployment consists of context services that receive, manage, store anddistribute context information for one or more entities. The programming modelfor a context service consists of entities associated with context items using a con-text relation. Context items may also be other entities so that useful entity relation-ships can be established. Context clients typically access entities and their contextusing a context service, by registering interest in events associated with specificcontext to receive notifications, or querying for a context value at any time. Clientscan also be suppliers (called context monitors) or consumers (context actuators)of context information from context services which aggregate the context for oneor more entities. JCAF's programming model refines the high l evel abstractionsfound in other frameworks consisting of event based asynchronous communica-tions, entities, context, and entity relationships as a specialization of context.2.3.6 DiscussionThe systems in this category support the development of context aware applica-tions: applications that use relevant information about the user and their situation.These systems often contain and/or aggregate access to relevant information aboutpeople, places and things around an entity abstraction. ParcTab designers call theseentity aggregators Environment Servers; they are Entity Aggregators in the ContextToolkit, Environments in one.world, Sentient Objects. Context services contain en-tities in the JCAF programming model. Several systems allow applications outsideof the framework to query for context on demand, and subscribe to changes in con-text values. Sentient Objects and one.world host applications within their entityChapter 2. Survey and Analysis of Ubiquitous Systems 32containers (i.e. sentient objects or environments). In some cases context valuescan be other entities, hinting at an important specialization of context we call entityrelationships found to be valuable in Wide Area systems described in Section 2.5.To summarize, the systems in this category build on Component Compositions tointroduce entity aggregations, and context abstractions to application developers.2.4 Smart Space SystemsIn this section we consider the systems listed in Table 2.3 that typically provide ahigher level of abstraction than Context Frameworks. Generally, the scale of de-ployment in this category are comparable to those in Context Frameworks: singlerooms, or buildings. The core of both the iROS (Section 2.4.1) system and Gaia(2.4.4) is a centralized event broker to move messages between distributed com-ponents. Other core components in Gaia and iROS were created for data storageand transformation, shared environment state and services. InConcert/EasyLiving(2.4.3) and Sentient Computing (2.4.2) efforts focused on providing a detailed envi-ronment model to applications to customize interaction based on the user's absoluteand relative location to other objects and people. We also consider ontology-basedsystems in this category in Section 2.4.5. The use of ontologies and a knowledgebase in these systems allows the semantics of objects such as entities, relation-ships and context values to be standardized for interoperability. Information in theknowledge base can be processed using standard semantic web reasoning systemsto infer new context values and trigger application services.2.4.1 iROSiROS aimed to make it easier to create applications for a specific class of smartspace: meeting rooms. In these scenarios it is important to support multi-deviceChapter 2. Survey and Analysis of Ubiquitous Systems 33Table 2.3: Summary of Smart Space Systems.System Purpose Scale Abstractions Key RefsiROS Meeting room appli-cation developmentMedium:roomCentralized Event Heap,shared state, ICrafter services,Data Heap for storage andtransformation[42, 63, 83]SentientComput-ingEasy location-awareprogrammingMedium:floorDetailed environment modelcontaining entities, absoluteand relative location facts, andlocation events[11, 54]InConcert/EasyLiv-ingDynamic cross device(screens) user inter-faces based on loca-tionMedium:houseDetailed environment modelcontaining fixed and mobileentities and their geometric re-lationships.[25]Gaia General purposesmart space operat-ing systemMedium:room-floorCentralized event broker, datastore, service infrastructure,space/presence repository,and context inference service[87]Ontology-based:SoCAM,CML,Gaia,CoBrAEasy context awaresmart space applica-tion development andimplementation inde-pendent modelMedium:room-floorEntities and context in an ex-ecutable knowledge base, ap-plication execution chosen ortriggered using rules.SoCAM [51]CoBrA [28]Gaia [85]CML [55, 56]interactions where users can move between a portable device such as a PDA orTablet PC to one or more large wall-mounted displays. Recognizing the value ofthe event abstraction in interactive desktop applications, the main subsystem ofiROS is the centralized Event Heap. Using the Event Heap, any device can pro-duce events, and any number of event consumers can listen, enabling group com-munications and multi-device interaction. The State Manager subsystem makesuse of the Event Heap to maintain shared state of devices, and software compo-nents in the room. Shared state includes published service descriptions used bythe ICrafter subsystem [82]. ICrafter provides a service discovery and interactioninterface similar to the Context Toolkit Discoverer and Service components. TheData Heap was used for storing content and documents, and meta-data associatedwith this content. Notably, this system also provided data-format transformationservices for applications to make it easier to view and manipulate content on a wideChapter 2. Survey and Analysis of Ubiquitous Systems 34range of devices. To summarize, all of the devices in a room use centralized serversfor event communications, shared state and data storage.2.4.2 Sentient ComputingUnlike iROS, the Sentient Computing platform was designed to provide an explicitmodel of the physical environment for applications. The system provides a veryfine grained location system [107], and a detailed data model of space for eventbased applications. To build and maintain this model, components called resourcemonitors and spatial monitors are used. The detailed environment model describesthe entities (people, places, and things) and possible ways of interacting with them.Applications are provided with an API for location-aware programming providingboth absolute and relative location facts, such as ?the user is at (x,y) facing di-rection (angle)?, or ?the person (Bob) is standing in front of workstation (Xyz)?.Sentient Computing highlights the value of an explicit, accurate and dynamic en-vironment model to ease application development. Another important distinctionfrom Component Composition Systems and some Context Frameworks is that ap-plications need not access components that implement or maintain the model sincethe system itself effectively hides these concerns.2.4.3 InConcert/Easy LivingEasyLiving designers focused on supporting user interaction across multiple de-vices including mobile devices and large screen displays in the home. Like Sen-tient Computing, the InConcert middleware provides a explicit environment modelto enable applications to dynamically assemble a user interface across multipledevices. Knowing a user's location and orientation allows t he system to choosewhich display to use for information, and which speakers to use for music or voiceChapter 2. Survey and Analysis of Ubiquitous Systems 35responses. Within this environment model, objects in the physical world are associ-ated with each other using geometric entity relationships called measurements. Asin Sentient Computing, and Gaia discussed next, software tracks mobile objects tomaintain the model so that these relationships are kept current. Developers makeuse of the geometry model and service descriptions to adapt their user interfaceto the current situation. Maintaining the measurements using the geometry modelis a key enabler for EasyLiving applications that must take into consideration thespatial relationships between devices and end users in the environment.2.4.4 GaiaGaia aimed to apply and extend approaches proven in systems like iROS andSentient Computing to domains such as the home, the office, and the car. LikeiROS' Event Heap, a centralized event broker called the Event Manager providesa publish-subscribe mechanism for services, applications and components. TheSpace Repository and Presence Service subsystems store and track tracks the phys-ical location of entities, such as people and devices and software components forapplications. A general purpose Context Service tracks other context such as sound,temperature and weather. This subsystem supports the use of first order logic to in-fer higher level context from sensor data. A Context File System allows users toassociate content with different contexts such as time, place, and user presence. Fi-nally an Application Framework made it easier for application developers to makeuse of the various Gaia subsystems and distributed components. Since interactingwith multiple devices can be challenging, the notion of an ?Application Session?was created for end users to contain the applications and data associated with thatuser when they enter the space.Chapter 2. Survey and Analysis of Ubiquitous Systems 362.4.5 Ontology Based SystemsSeveral systems in this survey demonstrate that that application code can be reusedwith the consistent use of an interface to a given smart space. However, to addressapplication portability and interoperability between smart spaces, it is not onlyimportant to share the same interface, but also the same semantics for context types,and service interfaces. In ontology-based context-aware systems such as SoCAM[51] and the Context Broker Architecture (CoBrA) [28], context is modeled with amodel called an ontology, a formal description of concepts in a particular domain.Gaia was also extended to use ontologies for context reasoning [85] about entitiesand components in the system. The Context Modelling Language (CML) [55,56] is a graphical notation developed to assist developers to design and explorethe context requirements of applications independent of the infrastructure used.While the CML does not use sematic web notations or technologies such as theWeb Ontology Language (OWL) [102], it does relate attributes to physical andconceptual entities such as users, and devices. CML also permits designers tospecify context quality and dependencies between context information.In ontology-based systems, logical expressions using facts in the knowledgebase can define situation abstractions similar that in the Context Toolkit, inferringhigher level context from lower level facts in the environment model. The useof an ontology provides a way to share common understanding of concepts in anenvironment and facilitates the use of an executable model in a knowledge base.An executable model with a general purpose reasoning engine can also be used toinfer higher level context and new entity relationships from facts in the model, orto alter application behavior and execute specific services when certain situationsexists.Chapter 2. Survey and Analysis of Ubiquitous Systems 372.4.6 DiscussionSmart Space Systems aim to provide even more comprehensive support for ap-plication development in specific places such as meeting rooms, and the home.Typically these systems coordinate multiple mobile devices, users, and large fixeddisplays: inter-device interaction is a critical requirement. iROS and Gaia central-ize communications between components to broadcast and intercept the value ofevents as a key abstraction for smart spaces. Several systems such as EasyLivingand Sentient Computing introduce the notion of a comprehensive and explicit en-vironment model. Ontology based systems maintain information about containedentities, their relationships to one another, and current context values in a centralknowledge base. All of the systems provide mechanisms to call services indepen-dent of their underlying implementation and location in the smart space. iROS andGaia both provide comprehensive data and content storage and transformation ser-vices for applications. To summarize, smart space systems highlight the value ofcross-device interaction events, explicit environment models and centralized dataand data transformation services for application developers in their programmingmodels.2.5 Wide Area SystemsThe systems listed in Table 2.4 coordinate larger scale environments containingmany users and applications potentially across smart spaces. The cross-physical,-network and -administrative domain requirements for such systems means thatmany of the communications protocols used in other categories are not appropriate;the systems here use protocols such as HTTP and Web Services rather than localnetwork broadcast for example. Security and privacy are also a consideration in thisChapter 2. Survey and Analysis of Ubiquitous Systems 38category. Since the number of computing resources in large scale environments canbe high, and communications can be expensive in terms of latency and bandwidth,there is often a need to provide coarser grained abstractions than software com-ponents, individual devices and services in this class of systems. Typically thesesystems will aggregate information and services associated with entities: people,places and things, or environments as a whole as in Context Frameworks or SmartSpace Systems. The first system we describe in Section 2.5.1, Cooltown, leveragedthe well understood distributed document model of the web to integrate the phys-ical world with the online world. The Context Fabric (2.5.2) aimed to provide aprivacy sensitive context infrastructure by linking distributed Infospaces containingcontext about entities. Active Campus (2.5.5) provided integrated large scale ubi-comp environment containing many services to potentially thousands of users ona university campus. The Nexus (2.5.3) system designers federate environments,while Aura (2.5.4) aimed to support migration of high level user tasks betweensmart spaces by marshalling the services there. Web Service for Ambient Intelli-gence (WSAMI) in Section 2.5.6 is unique in that it composes wide area servicestaking a similar approach to Component Composition Systems.2.5.1 CooltownThe World Wide Web introduced a model for distributed computing where infor-mation is organized into documents identified by uniform resource locators (URL)linked to other documents elsewhere in the world. Cooltown leverages this sim-ple and effective model for ubicomp by providing a software layer to integrate thephysical environment with the web [68]. People, places and things in the worldeach have their own web presence, software running on a server that provides aweb user interface to an entity. The web presence of a user is related to otherChapter 2. Survey and Analysis of Ubiquitous Systems 39Table 2.4: Summary of Wide Area Systems.System Purpose Scale Abstractions Key RefsCoolTown Leverage WWW to in-tegrate physical worldwith online worldLarge Web presence servers corre-sponding to entities (people,places, objects) linked to eachother[68]Context Fab-ricContext infrastructurefor privacy sensitiveapplicationsLarge Network of Infospaces typicallycorresponding to entities con-taining instrinsic and extrinsiccontext (entity relationships)[58, 59]Nexus Infrastructure forspatial-aware appli-cationsLarge Network of Augmented Ar-eas containing entities (objectsof interest) in an AugmentedWorld. Location queries andevents.[57, 77]Aura User/task migra-tion between smartspaces, and changingdevicesMultiple-smartspacesTask abstraction to marshalend-user services (Suppliers)in the environment based oncontext information in an Envi-ronment Manager[94]Active Cam-pusAddress tradeoffsbetween extensibilityand integration inlarge scale ubicompLarge: cam-pusTwo layer environment modelassociating entities with ser-vices and context. Entity Mod-eling layer deals with static re-lationships, Situation Modelinglayer with dynamic context andrelationships.[49, 50]WSAMI Situation aware webservices compositionLarge: inde-pendent oflocationWeb services composed dy-namically using dependencyand QoS requirements.[3, 62]entities such as places, or objects nearby using dynamic web links correspondingto directed entity-entity relationships. These relationships may include contains,next-to, or carried-by for example; they may be reciprocal or one-way relation-ships to protect user privacy. Users typically interact with one web presence at atime, starting with their personal (user) web presence; sensors are used to discovernew entities and dynamically create entity links. For example, when a person en-ters a room, the users web presence is linked to the rooms web presence when aninfrared beacon is detected by a mobile device carried by the user. Users (and ap-plications) may follow the links to take advantage of functionality (applications)hosted by the rooms web presence. A key abstraction for Cooltown is the notionof entity relationships corresponding to web links used by users and applicationsChapter 2. Survey and Analysis of Ubiquitous Systems 40hosted on web servers to adapt to a changing environment.2.5.2 Context FabricThe Context Fabric was proposed as an infrastructure for context storage and man-agement. When collected and distributed in a shared infrastructure, privacy ofcontext information such as location and activity is a vital concern for end users.To address this, context can be manipulated (e.g. aggregated or anonymized) asit enters or leaves the system to manage the privacy requirements. The ContextFabric is a network of servers containing InfoSpaces corresponding to entities suchas people, places and things. An InfoSpace contains context about the entity ithandles, both intrinsic context, information about the entity itself, and extrinsiccontext, relationships between entities. Applications can also use the InfoSpaceto store service descriptions. A client library simplifies querying by supportingon demand, periodic and subscription based queries on InfoSpace data. The Con-text Fabric is similar to several systems in the Context Frameworks category andCootown in that it aggregates context data in Infospaces corresponding to entities.Infospaces aggregate context about entities, and relate them to one another, similarto Cooltown web links.2.5.3 NexusNexus is a generic wide area infrastructure for location and spatial-aware applica-tions [57]. The designers aimed to provide a model of regions of the physical worldcalled Augmented Areas similar in concept to the explicit environments in SmartSpace Systems such as EasyLiving or Sentient Computing. Both physical and vir-tual objects of interest exist in Augmented Areas accessible through the platform.An object of interest may also be a proxy for an end user. Furthermore, AugmentedChapter 2. Survey and Analysis of Ubiquitous Systems 41Areas can be federated in a global Augmented World related to one another by con-tainment and relative distance relationships. Since all Augmented Areas use thesame Nexus interface, applications can easily move between Augmented Areas us-ing a handoff mechanism. An important attribute for objects in an Area is locationdetermined using an Active Badge or GPS for example. Like Sentient Comput-ing, the system supports location events triggered by changes in location such asentering areas or proximity to other users, but aims to unify such smart space ca-pabilities for larger scale deployments. Nexus demonstrates that federating smartspaces is another approach to addressing scalability and smart space integration.2.5.4 AuraIn the Aura system, user mobility between ubiquitous computing environments issupported with an abstraction called a user's personal aura that encapsulates theusers current task. Similar to the notion of an Application Session in Gaia, the auraor task is defined as the information and services (applications) required by a userat a given time. Once the users task is transferred to an instance of the system,the hub of the system, called the Task Manager marshals resources in the currentenvironment to support that task. Services are hosted by components called Suppli-ers which register with the Task Manager. A service hosted by a Supplier may bea display device, a text editor, storage server or drawing application for example.Like Gaia's Space Repository, Aura's Environment Manager manages informationrelated to the physical environment. Aura uses a Context Observer to watch theenvironment for end user activity, to report this information to the EnvironmentManager. When the user moves from one environment to another, that user's Auracan be migrated to the Task Manager at the new location to continue their currenttask. Each Aura system provides an environment model for task execution andChapter 2. Survey and Analysis of Ubiquitous Systems 42demonstrated that the use of a common platform in multiple smart spaces makes itpossible to for users seamlessly move between environments, migrating data andapplications on their behalf.2.5.5 ActiveCampusLike Cooltown, Active Campus services are presented as web pages, however, thegoals of this system are quite different. This project aimed to address the trade-offs between easily providing new services, while maintaining the integration ofthese services in an large (campus) scale environment [49]. The centralized Ac-tiveCampus architecture consists of several layers. In the top layer, mobile devicescommunicate with an Environment Proxy which marshals data between the ser-vices on the device and the ActiveCampus system. The Situation Modeling layerin the server synthesizes the situation of entities from multiple information sources(mobile devices and other sensors). Finally, the Entity Modeling layer of the serverrepresents entities in several forms for access by other services and presentation ona browser, and stores static relationships among these entities. In this system weagain see an explicit environment model containing entities, entity relationshipsand entity-related context. Unlike Context Frameworks and Smart Space Systems,however, ActiveCampus was designed to scale to larger environments and moreusers by making use of a layered architecture.2.5.6 Web Services for Ambient Intelligence (WSAMI)WSAMI [62], part of the Ozone project [3], is a middleware that leverages WebServices standards to deploy and compose web services dynamically on wirelessnetworks and mobile devices. The use of Web Services enables availability inmost environments, and potentially across network domains. WSAMI uses a nam-Chapter 2. Survey and Analysis of Ubiquitous Systems 43ing&discovery service that supports naming, service discovery and lookup in bothlocal and wide area networks. Like PCOM and other Component CompositionSystems described in Section 2.2, this work focuses on dynamic distributed ser-vice composition. Unlike these systems, however the designers targeted wide areaweb service composition. Novel aspects of this work included the customization ofthe network links for performance and security. Services are specified using stan-dard WSDL. These specifications are then referred to in WSAMI specificationswhich include the required services that an application needs.2.5.7 DiscussionWe find that systems in the wide area category tend to borrow abstractions fromthe other three. For example, WSAMI exposes and composes services directlylike others in the Component Composition category. The Context Fabric exposesentities and context, like other Context Frameworks. The Nexus system federateswhole environments called Augmented Areas similar in concept to the environmentmodels exposed by Smart Space Systems.For greater scalability large scale systems will often distribute storage process-ing among multiple servers. Several systems here distribute work among serversthat proxy physical or virtual entities in the real world. These servers will of-ten expose relationships between servers that correspond to their proxied entity'sreal world relationships. The Context Fabric, for example, aggregates informationabout entities in Infospaces, relating them to each other using extrinsic context.Similarly, Cooltown aggregates services and relevant information about entitiesusing separate web servers, relating them to each other using hypertext links.Unlike other systems, the Active Campus system addresses scalability by sep-arating the concerns of managing an integrated environment model into separateChapter 2. Survey and Analysis of Ubiquitous Systems 44layers on a single server. Aura is also unique in that it supports user migrationbetween environments by migrating information about a users current task to betransferred from one smart space to the other.2.6 Common Abstractions Derived from the SurveyBased on this survey, two things become evident: one is that we have a wealthof experience to draw from when designing new ubicomp systems. Secondly, wesee that certain high level concepts are shared by several systems, in some cases,under different names. Systems in all categories, for example, supply services toapplications; functionality exposed using an interface registered with the system.Systems in all categories support application callbacks or events for notificationwhen something about the state of a device, entity or the environment changes.Context Frameworks tend to aggregate components and information around an en-tity abstraction to avoid the need to communicate with multiple components to findcontext, relevant information about that entity [36]. Several smart space systemsillustrate the value of a centralized and explicit environment model containing de-tailed information about entities, context and relationships. Several componentcompositions expose a data abstraction and certain smart space systems supportdata or content storage. We note that Wide Area Systems surveyed here often usereal world relationships between entities: people, places, things, and whole en-vironments to link servers representing these entities. This allows applications toeasily find and use relevant context and services, avoids unecessary communica-tions to individual components, and lends itself to greater scalability by distribut-ing storage and processing of context information. Table 2.5 indicates when one ofthese abstraction appears in a given system.Chapter 2. Survey and Analysis of Ubiquitous Systems 45Table 2.5: Summary of the scale, level of abstraction and abstractions used.Here we indicate whether an abstraction is supported (a19), not supported(a21) or partially/implicitly supported (P).System Abstraction Scale Env. Entities Context Entity Services Events Data /Level Model Rel. ContentJini L S Pa a21 Pb a21 a19 a19 a21UPnP L S Pa Pc Pb a21 a19 a19 a21ZeroConfig L S Pa a21 a21 a21 a21 a21 a21OSGi L S-M Pa a21 Pb a21 a19 a19 a21ADS L S Pa a21 a21 a21 a19 a21 a19SpeakEasy/ObjeL S Pa Pc Pb a21 a21 a21 a19ECT L S Pd a21 a21 a21 a21 a19 a21PCOM L S a21 a21 a21 a21 a19 a19 a21ReMMoC L S a21 a21 a21 a21 a19 a21 a21ParcTab M M a21 a19 a19 a21 a21 a19 a21ContextToolkitM M Pa a19 a19 P a19 a19 Peone.world M M a21f a19 a19 Pg a21 a19 a19SentientObjectsM M Ph a19 a19 Pi a19 a19 a21JCAF M M a21 a19 a19 a19 a19 a19 a21iROS H M Pj Pk a19 a21 a19 a19 a19SentientComputingH M a19 a19 a19 a19 a19 a19 a21EasyLiving H M a19 a19 a19 a19 P a19 a21Gaia H M a19 a19 a19 a21 a19 a19 a19OntologySystemsH M a19 a19 a19 a19 Pl a19 a21CoolTown M L a21 a19 Pm a19 P P PContextFabricM L a21 a19 a19 a19 a21 a19 a21Nexus H L a19 a19 a19 a19 a19 a19 a21Aura H M-L a19 P a19 a21 a19 P a19ActiveCampusH L a19 a19 a19 a19 a19 P PWSAMI L H a21 a21 a21 a21 a19 a19 a21aa component/service or device registrybcomponent state as contextcDevices onlydDataspaceedata or content treated as contextfalthough called an environment, typically corresponds to an individual entitygenvironment/entity containment relationshipshthe ad hoc networkiimplicit in event subscriptions between objectsjEvent heap, service registrykembedded in event fieldslsome ontology-based systemsmwithin web presence serverChapter 2. Survey and Analysis of Ubiquitous Systems 462.7 ConclusionsIn this chapter we presented a survey of twenty one representative research sys-tems, and four commercial standards used for ubicomp application development.To consider related systems together, we grouped systems into four categories:Component Composition Systems, Context Frameworks, Smart Space Systems,and Wide Area Systems. These categories were created by placing systems in aspace defined by two dimensions: the typical scale of deployment targeted by theirdesigners, and the level of abstraction they support. We defined three abstractionlevels: services and components (low), entities and context (medium), and explicitenvironment models (high). By considering groups of systems in this space it be-comes evident that there is some correspondence between the scale, and the levelof abstraction that system exposes. Small scale systems tend to expose simplerservice/component abstractions while larger scale systems provide additional ab-straction layers, alleviating the need for applications to find individual componentsand model physical environments themselves. We noted also that some systemsdemonstrate that these dimensions are also orthogonal. Smart Space Systems tendto provide explicit environment models (high level abstractions) to medium scaledeployments (e.g. [11]), while some large scale systems provide entity and con-text (medium level) abstractions (e.g. [59]), or service and component composition(low level) abstractions (e.g. [62]). Finally, we derived a set of common abstrac-tions exposed by several systems. These include an environment model, entities,context, entity relationships, services, events and data or content. We present thesecommon abstractions in more detail in the next chapter.Based on this survey, it is evident that there are tradeoffs between interoperabil-ity, scale of a typical deployment, and the level of interactivity or domain-specificcapabilities that influences the programming abstractions chosen. With the wealthChapter 2. Survey and Analysis of Ubiquitous Systems 47of experimentation and deployment experience so far, we can now begin to un-derstand these tradeoffs and address some the challenges the ubicomp communityfaces related to interoperability. Armed with the set of common abstractions iden-tified here, we have a solid foundation for the design of a common programmingmodel for ubicomp. In the next chapter we continue our analysis starting with thecommon abstractions we identified in this survey and describe the design of theUbicomp Common Model.48Chapter 3The Ubicomp Common ModelIn the previous chapter we identified several categories of ubicomp systems, andsummarized the core abstractions shared across categories. In this chapter we con-tinue our analysis in Section 3.1 by highlighting several requirements for a interop-erable model for ubiquitous systems. We then review the abstractions identified inChapter 2 in Section 3.2 with examples, and present the Ubicomp Common Modeldesign consisting of three related aspects: the Environment State, Meta State andImplementation providing examples of each in Section 3.3. In Section 3.4 we re-flect on how the UCM addresses several requirements presented in Section 3.1. InSection 3.5 we discuss how the UCM could be extended to support the integrationof different security domains and access control mechanisms. Section 3.6 outlinesuse cases for an executable UCM that can be queried and reasoned with. Finallywe summarize the Chapter in Section Common Model RequirementsTo drive our analysis, we envision scenarios where applications hosted on mobilephones connected to wide area networks interact with public ubicomp environ-ments such as shopping malls and museums. We anticipate that application servershosted outside of a ubicomp environment's network domain wi ll need to make useof resources there. This can occur across a large university campus or betweenorganizations to link smart meeting rooms for example. Based on our survey ofChapter 3. The Ubicomp Common Model 49systems in Chapter 2, our own integration experience described in Chapter 5, andour deployment of other ubicomp systems [39, 40] we highlight the following re-quirements for the design of a common model for ubicomp:Application Portability. An interoperable model should support a level ofapplication portability between different environment types such as the home, theoffice and public places.Environment Specialization. While portability is important, a common modelmust support specialization for different domains. A specialization may includesubclasses of core entity types, service interfaces, context and event types specificto a location and its use. This will allow general purpose applications to workbetween locations while allowing deployments to provide location and domain-specific resources.Introspection. To support both portability and specialization, A commonmodel must support introspection, exposing not only the current environment state(entities and context information), but also its current capabilities such as the typesof context and service interfaces available. This will allow applications to queryand adapt to the the environment and the facilities that are available.Separate Implementation. The model should separate exposed abstractionssuch as entities and context from implementation abstractions such as distributedcomponents and servers. This separation of concerns will allow implementationindependence, and dynamic binding of components to entities without applicationinvolvement. Available components can come and go, and change depending onthe current context. By separating the implementation from exposed abstractions asupporting system can be designed to adapt to change.Straightforward Mapping to Existing Systems. For ease of integration, acommon model should lend itself to a relatively straightforward mapping to a va-riety of existing systems' abstractions. The model should support the integrationChapter 3. The Ubicomp Common Model 50of different categories of ubicomp systems: Component Compositions, ContextFrameworks, Smart Spaces, and Wide Area Systems as described in Chapter 2.This means there should be support for a wide variety of abstraction levels andscales of deployment. The model must find the right tradeoff between being suit-ably generic across a wide range of systems but semantically close enough to spe-cific systems to take advantage of their unique capabilities.Access Control and Security. When applications interact with environmentresources across network domains (e.g. [41, 93]), or in unadministered ad hocconnections such as Bluetooth, access control and security issues are importantconsiderations. In these scenarios, we cannot rely on a network administrator of aprivate deployment to ensure all of the applications in an environment are autho-rized and secure as the designers of closed ubicomp systems have. As a minimum,an intermediary that exposes resources outside the domain must provide accesscontrol to previously assumed private or closed deployments.Executable Model. We also claim that that an integration model should be ex-ecutable, that is, have the ability to be queried and reasoned with by applications.Support for flexible queries will allow applications to discover entities and associ-ated services, and allow applications to determine whether their requirements canbe satisfied. Support for reasoning will allow an integration platform to maintainthe exposed model as its composition changes, simplify integration tasks, providemissing general purpose capabilities such as context inference, and establishingrelationships between entities and components.There remain many open research challenges in ubicomp such as the variousdimensions of scalability, dependability, security, privacy, context management,application mobility and HCI that in some cases affect the programming modelof ubicomp systems. However, until there is some consensus in whether or howthese issues are exposed to application developers, it is likely too early to addressChapter 3. The Ubicomp Common Model 51them all in the design of common programming model; however, we acknowledgethat change must be anticipated in our core model design by ensuring it can beextended with new abstractions, and provide an example of this in Section 3.5. Ofcourse, the addition of new abstractions will likely require additional interfaces toan implementation (i.e. in an integration gateway or standalone system).A key challenge is to find the right balance between interoperability and suit-ability for cross domain access as outlined while maintaining as much of the func-tionality of a given underlying ubicomp system. This will necessitate the provisionof a new layer of abstraction on top of the native one. Of course, the introductionof a new programming model can make application development more difficult,especially if it doesn't match the problem at hand. Just as di fferent programminglanguages and supporting libraries support some application domains better thanothers, we expect that different environment models will need to coexist. Since wedo not expect all local ubicomp applications to require cross-domain interaction,we need not replace an existing set of abstractions and associated APIs for nativeapplication development; we can provide an interoperable model as an alternativesuitable for the basic needs of portable applications and cross domain access. Toaddress these requirements we must base our model on the common abstractionsof existing systems reviewed in the next section.3.2 Existing Systems' AbstractionsTo derive the UCM model we based our core abstractions on the analysis of rep-resentative systems presented in Chapter 2. We found the following core abstrac-tions were shared across systems in all four categories, Component CompositionSystems, Context Frameworks, Smart Space Systems and Wide Area Systems:Environment Model. An environment model is an abstraction that contains theChapter 3. The Ubicomp Common Model 52current state of the environment for application access. This abstraction ismost evident (and comprehensive) in smart space systems, containing enti-ties, context values, and entity relationships. There are other examples ofthis abstraction in every category however. In component composition sys-tems, and in some Context Frameworks, for example, this abstraction canbe considered a component registry or lookup service. We can consider theJini Lookup Service and the Context Toolkit Discovers to be simple environ-ment models for example. The ECT Dataspace is an environment model thatcontains components and links between component properties. The Nexusinfrastructure federates their environment models, while Active Campus en-capsulates their environment model using a centralized integration servercontaining information about entities and integrated services.Entity. An entity abstraction is used in several systems to represent or proxy aperson, place or thing in an environment: either physical or virtual. Exam-ples of implementations include the ParcTab Environment Server, the Con-text Toolkit Entity Aggregator, a Cooltown Web Presence, and one.worldEnvironment abstraction. In many Smart Space Systems, the exposed envi-ronment model will contain entity abstractions, context, and relationships.Context. Most Context Frameworks in this survey expose context as informa-tion related to an entity. Applications may query for this information, orregister to be notified when context data changes. In some cases, the entityabstraction in a system such as a server or distributed component is usedto aggregate context data or the components that supply context such as sen-sors. Again, the use of context is most evident in most of the Context Frame-works surveyed, and in some Wide Area Systems such as the Context Fabricinfrastructure.Chapter 3. The Ubicomp Common Model 53Entity Relationship. Several systems make use of a specialized form of contextwe call an entity relationship to mirror the relationships between physicalobjects, places and people in the real world. These include location-basedrelationships: a user is contained-in a place, objects are near each other.Relationships may include ownership, a user owns a device, or social rela-tionships such as friendship or community group relationships. Entity rela-tionships, are evident in Cooltown, JCAF, the Context Fabric, to some extentin one.world, and the Context Toolkit.Service. The notion of a service, functionality exposed through an interface, isat the core of most of the Component Composition Systems listed here. Itis also supported either implicitly by the underlying middleware, or explic-itly in a service framework supplied by a system. For example, the iROSICrafter subsystem supports RPC semantics for services implemented usingthe Event Heap. Similarly Context Toolkit Widgets can implement serviceswith remote procedure call semantics.Event. The iROS and Gaia systems highlighted the value of a centralized eventbroker at the core of a smart space system for loose coupling between ap-plications and devices. Virtually all other systems including Context Frame-works such as one.world support events as a key communications primitivefor components in ubicomp. To avoid polling, events are used to communi-cate important changes in device state, context values, and relationships inan environment.Data or Content. Finally, we note that several systems, particularly in the Com-ponent Composition and Smart Space categories, support content or data asa separate abstraction. The Appliance Data Services system for exampleChapter 3. The Ubicomp Common Model 54stores data in the infrastructure to allow device services to transfer it fromservice to service. Both iROS and Gaia have centralized data storage andtransformation services to make it easy to share data between software ser-vices and end users in a smart space. In some systems and deployments dataor content is considered an entity, whereas in others, it is treated as con-text. For example, content stored in the Gaia Data Manager or iROS DataHeap is treated like other objects in the system, stored in the infrastructureand passed between services. The data itself may have context meta-datacontaining information about who created it, its title and current version. Inother systems, content is treated as context. The Context Toolkit applicationcalled the Conference Assistant [37], the system treats presentation contentand questions as context for example.3.2.1 Core Abstractions to a Common ModelAs a concrete example of how these core abstractions can be used to model aubiquitous computing environment, we describe a ?smart? campus as illustrated inFigure 3.1. Buidings contain classrooms containing students equipped with lap-tops, smart phones or other mobile devices. Each classroom includes a projectorthat can be used for presentations. The projector can signal when a slide changesso that users can follow the presentation on their laptops or mobile devices. Userscan communicate with each other using messaging, and locate their friends in thecampus.In this environment the (static) location of buildings, classrooms should bemade available to applications. We anticipate that the dynamic location of users(coordinates), their identity, online status and social relationships will also be im-portant to certain applications.Chapter 3. The Ubicomp Common Model 55ClassroomCampusFigure 3.1: Smart campus including buildings and classrooms.We can model this environment using the abstractions outlined as follows:? Environment. The environment is a campus that hosts various entities, re-lated to other entities, services, context and content.? Entities. The campus environment hosts entities such as buildings, class-room places, users, and projectors.? Context. Buildings, classrooms and users all have location context. Usershave presence context (e.g. online, offline, busy).? Entity relationships. Buildings and classrooms have static containment re-lationships. Users can be friends with one another, and can be contained ina classroom or a building.? Services. In this environment, messages can be sent to users, and presenta-tions can be made on projectors using appropriate service interfaces.? Events. To keep in sync with the presentation, the projectors send eventswhen a slide has changed.Chapter 3. The Ubicomp Common Model 56? Content. A projector will have a presentation associated with it while it isbeing used in the classroom.To implement the smart campus, we need a variety of software and hardwarecomponents to be used. An instant messaging system can provide messaging andfriend management services for example. A PC can be used to drive the projector,and a location sensor in each classroom can sense the entry and exit of each user.These available computing resources will directly affect the capabilities exposedby the environment model. Because of this, it is important to expose these capa-bilities to applications so that they can adapt to their availability (or absence). Byconsidering the three aspects of an environment: its state including entities, theirrelationships and and their current context values, its meta-state, the current capa-bilities of entities, and the implementation of this model, we designed the UbicompCommon Model described next.3.3 The Ubicomp Common Model DesignThe Ubicomp Common Model is an entity-centric model for ubiquitous computingsystems. It is entity centric in that all of a ubicomp's computing resources arerelated to one or more entities: e.g. people, places, things, and other physical andvirtual concepts. The definition of an entity depends on the UCM specialization.To describe the UCM we used the Web Ontology Language (OWL) [102] alongwith a set of rules for use in a general purpose reasoning engine [1].OWL is an ontology language built on the Resource Description Framework(RDF) [101]. Over time RDF has come to be used as a general way of modellinginformation and used as the basis for ontology languages such as OWL. RDF isbased upon the idea of making statements about resources typically named by aUniform Resource Identifier (URI). RDF statements typically provide meta-dataChapter 3. The Ubicomp Common Model 57about those resources in the form of subject-predicate-object expressions, calledtriples. A collection of RDF triples intrinsically form a graph. In this chapter weuse graphs to highlight the key concepts and relationships in the UCM as shownin Figure 3.2. Specifically we use elipses to represent OWL classes, labelled lineswith arrows to represent OWL properties, subclasses and subproperties as shown.A rounded rectangle is used to represent properties that are also properties of aclass, and rectangles for literal values (numbers and strings). In the RDF snippetsin this chapter we use the XML serialization format.ClassA ClassBSubclassCsubpropertyCpropertyBLiteralpropertypropertyFigure 3.2: Notation used to highlight classes, properties and relationships inthe UCM.To address the requirements and scenarios highlighted in previous sections, weconsidered three related aspects of an environment called the Environment State,the Environment Meta-State and the Environment Implementation as shown in Fig-ure 3.3. The Environment State aspect consists of entities, entity relationships, andthe current state of those entities: current context values and content for example.The Environment Meta-State consists of entity capabilities: the types and qualityof events, services, context and content an entity exposes are linked to the entitiesin the state aspect by the exposes property, (and subproperties). This aspect is nec-essary for application introspection. Both the Environment State and Meta-Stateare exposed to applications to query the current context values, entity relationships,and capabilities of an environment. Finally, the Environment Implementation as-Chapter 3. The Ubicomp Common Model 58pect links entity instances by an aggregation property to the specific componentsthat supply the services, context and events for a given entity. Together these as-pects form the Ubicomp Common Model core.EntitiesEntity RelationshipsContextService InterfacesContext TypesEvent TypesServicesContextSourcesEventSourcesEnvironment State Environment Meta-StateImplementationexposeshasContexthasEventimplementshasContexthasEventaggregatesExposed Environment ModelInternal Implementation ModelFigure 3.3: The three aspects of the Ubicomp Common ModelThe three aspects of the UCM depend on one another and typically change overtime. In a typical environment entities and components are added and remove andcontext values change. The Meta-State depends on the current Implementation,since the exposed capabilities of an entity will depend on the components aggre-gated by it. The current Environment State aspect depends on the Meta-State sincethe entities, relationships and context values of an entity will depend on its capabil-ities. In some cases, the components associated with a given entity will depend onthe current situation; that is, the Implementation aspect will depend on the Envi-ronment State. This can occur, for example, when a mobile user changes locations,or the device they are currently using. A messaging service may change from aninstant messaging implementation to SMS when the user leaves the office. The lo-cation context source may change from a GPS-based infrastructure for outdoor useto a wifi-based location sensor when indoors. We elaborate further on each aspectin the following subsections.Chapter 3. The Ubicomp Common Model 59EntityEnvironmenthostsassociatedWithpositiontemperaturecontainedInholdsContextValuehasContentContentcontextAttributepropertysub-propertysubclassStringValue IntValueLocationstateFigure 3.4: Environment State abstractions and relationships.3.3.1 Environment StateThe Environment State consists of entities modeled by the supporting system, therelationships between entities and their current context values. Context values arerelated to entities by context attributes. Context values need not be simple primitivetypes such as strings and integers, but may also be more complex data structures.These data structures could indicate a range of values, or an indication of timelinessand accuracy. The key abstractions and their relationships in the Environment Stateare shown in Figure 3.4.The Environment object serves as the root entity of an environment and hostsother Entities and subclasses of Entities such as places, people and devices. Ina supporting system context values can be retrieved by requesting the value ofthe associated context attribute or in an event data structure when an event is re-ceived. The contextAttribute property and ContextValue object may be specializedas shown to support different data types. Entities may also have content associatedwith them as shown by the hasContent relationship with a Content object.The UCM does not define all possible context types or quality of context;rather, it is a core ontology intended for specialization by an integrator or standardsChapter 3. The Ubicomp Common Model 60Program 3.1 Example Environment State RDF fragment.<campus:CampusBuilding rdf:ID="coffeeShop"><location:location><location:Position><ucm:name>position</ucm:name><ucm:javaType rdf:datatype="&xsd;string">ca.ubc.cs.uif.prototype.types.WorldPosition</ucm:javaType><location:latitude rdf:datatype="&xsd;double">49.260537157736785</location:latitude><location:longitude rdf:datatype="&xsd;double">-123.24801921844482</location:longitude><ucm:time rdf:datatype="&xsd;long">0</ucm:time></location:Position></location:location><ucm:containedIn rdf:resource="&campus;ubcCampus"/></campus:CampusBuilding>group to define the context types for a specific environment or application domain.The interpretation of a given ContextValue will depend on the specialization of theUCM model for a given domain such as a campus, home, office or classroom. Afragment of Environment State RDF is shown in Program 3.1. The prefixes area short form of the various namespaces used: ucm is the core UCM namespace,location is the namespace for a simple location ontology that extends the UCM,and campus is the namespace for a campus instance of the UCM. This exampledescribes a coffeeShop with static location context, and a static containedIn rela-tionship with the ubcCampus place. The coffeeShop has a static context campus-Location: a data structure containing latitude and longitude properties.3.3.2 Environment Meta-stateThe Environment Meta-State aspect is required to support introspection. It as-sociates entities with their capabilities: the types and quality of events, services,context and content an entity supports as shown in Figure 3.5.Chapter 3. The Ubicomp Common Model 61EntityServiceInterface ContextTypeexposescontextAttributeServiceDescriptiondescriptionusesContextAttributeusesContextValue ContextValueContextQualitycontextQualityCapability propertysub-propertysubclassproperty (as object)Figure 3.5: Environment Meta-State abstractions and relationships.When an entity has context associated with it, the entity exposes a ContextTypecapability. A ContextType specifies the context attributes to use to retrieve a Con-textValue (usesContextAttribute) and may include other properties to specify theContextValue and quality of this context as shown. Similarly, entities may exposeServiceInterfaces. Clients of the model can then call these services as specifiedin a ServiceDescription. ServiceDescriptions can be specialized to support stan-dard service descriptions such as Web Services Description Language (WSDL)[105] or others. The type of events that may be fired by an entity is specifiedusing an EventType object. The RDF fragment in Program 3.2 indicates that theCampusUser entity bob exposes the pointLocation context type, the event typecontextChangeEvent, and the MessageService interface.3.3.3 Environment ImplementationTo avoid dealing with a plethora of sensors, actuators, services, and software com-ponents, ubicomp systems typically expose a variety of distributed components,protocols or related APIs which we call components. The role of these compo-Chapter 3. The Ubicomp Common Model 62Program 3.2 Example Environment Meta-State RDF fragment.<campus:CampusUser rdf:ID="bob"><rdfs:label>Bob Smith</rdfs:label><ucm:containedIn rdf:resource="#campusPlace"/><ucm:exposes rdf:resource="&ucm;pointLocation"/><ucm:exposes rdf:resource="&ucm;contextChangedEvent"/><ucm:exposes rdf:resource="&campus;MessageService"/></campus:CampusUser>ComponentService EventSourceContextSourceEntityHandlerEntityaggregates propertysub-propertysubclassimplementsfireshasContextContextTypeEventTypeFigure 3.6: Environment Implementation abstractions and relationships.nents are captured in the Implementation aspect of the UCM as shown in Figure3.6. Here we show that components are aggregated by an entity instance and forma class hierarchy. Service components implement a ServiceInterface, EventSourcecomponents fire EventTypes, and ContextSources have a ContextType. These com-ponent abstractions can be used to map the common model to corresponding APIsin an existing system to invoke services, retrieve context or fire events. When an en-tity aggregates a component, the following rule ensures that that entity exposes thetypes and interfaces that component implements in the Environment Meta-State.[aggregateComponent: (?entity ucm:exposes ?capability) <-(?entity ucm:aggregates ?component)(?component ucm:implementsCapability ?capability)(?component rdf:type ucm:Component)]Chapter 3. The Ubicomp Common Model 63This rule depends on the fact that implements, fires and hasContext are sub-properties of implementsCapability.EntityassociatedWithlocationtemperaturecontainedInownsContextValuecontextAttributestateexposesComponentaggregatesServiceInterfaceEventTypeContextTypeCapabilityhasContextfiresService EventSourceContextSourceStringValueIntValueLocationEnvironment State Environment Meta StateEnvironmentImplementationpropertysub-propertysubclassimplements CapabilityFigure 3.7: Key objects and relationships of the UCM.3.3.4 SummaryThe three aspects of the Environment model and how they relate to one otherthrough an entity is summarized in Figure 3.7. The State, Meta-State and Imple-mentation aspects are all related to an entity instance. Furthermore, entities maybe related to each other by entity relationships.3.3.5 Model ExampleAn simple example of the model is illustrated in Figure 3.8. A person entity per-sonBob is shown to hold a mobile phone bobsMobilePhone. In the current Envi-ronment State, this phone has a location called phonePosition containing the lon-gitude and latitude of the device. In the current Meta-State, bobsMobilePhoneChapter 3. The Ubicomp Common Model 64personBobbobMobilePhonemobileMsgServiceoutdoorPositionSourceholdsaggregatesaggregateshasContextOutdoorLocationTypeMessageServiceInterfaceimplementsphonePositionusesAttributelocationexposes hasContextEnvironment StateMeta-StateImplementationFigure 3.8: Model example illustrating State, Meta-State and Implementationaspects.is shown to expose a MessageServiceInterface and has the OutdoorLocationTypeof context available for applications. The OutdoorLocationType uses the locationattribute as shown. In the current Implementation, bobsMobilePhone enitity ag-gregates the mobileMsgService Service component and the outdoorPositionSourceContextSource component. The mobileMsgService implements the MessageServi-ceInterface type, and the outdoorPositionSource hasContext OutdoorLocationTypeas shown. The component aggregation rule ensures that bobsMobilePhone ex-poses the same MessageServiceInterface ServiceInterface and OutdoorLocation-Type ContextType to applications.In this example, the mobileMsgService and outDoorPositionSource implemen-tation components would be supplied by integrated systems. For example, a Con-text Toolkit Widget could be mapped to the outdoorPositionSource component ofthe UCM, while an SMS service could be mapped to the mobileMsgService.Chapter 3. The Ubicomp Common Model 653.4 Model DiscussionIn this section, we discuss how the UCM addresses the requirements outlined inSection 3.1, specifically how it supports application portability, environment spe-cialization, introspection and mapping to existing systems.3.4.1 PortabilityWhen a system is adapted to the core UCM as described, some degree of interoper-ability is possible. Applications can browse an environment by entity relationships,and display the types of context and services associated with these entities for ex-ample. Applications can identify entities, context, services and events. However,a higher degree of interoperability is only possible only when applications share adeeper semantic understanding of entities and their associated resources with thesupporting infrastructure. To address this we propose the use of Environment Pro-files described next.3.4.2 SpecializationTo support specialization, Environment Profiles specialize the core model for spe-cific environment types. Profiles will contain the specific classes of entities, ser-vices, context, events, content and their possible relationships for a given environ-ment type. A home profile, for example, can consist of typical place entities inthe home such as kitchens and living rooms, device types such as appliances, andhome entertainment systems. Home context and services can include temperature,lighting controls and room-resolution location sensors. An application interactingwith the home environment can then ?turn the lights on in a room? when a userarrives by specifying the expected lighting service associated with a room. Sim-ilarly a museum profile could define displays, visitors, galleries, display content,Chapter 3. The Ubicomp Common Model 66visitor location, and interests. Profiles may be extended further by an integrator toprovide extensions specific to a deployment, at the possible expense of interoper-ability. Through the use of a specialized core model, and supporting infrastructureto map this model to existing systems we argue that it is possible for applicationshosted outside of an environments local domain to interoperate with an environ-ments resources independent of the ubicomp middleware used.3.4.3 IntrospectionThe Meta-State aspect of the model supports introspection for applications to de-termine whether its requirements can be met by the environment. An entity canbe queried for the context types, service interfaces and event types it currentlysupports. The environment as a whole can be queried for the entities that match agiven criterion such as current context values, entity types, and the types of context,events and services exposed.3.4.4 Mapping to existing systems abstractionsSince the UCM design is based on a thorough analysis of existing systems, ourmodel should lend itself to a straightforward mapping to a subset of these systems.The separation of the Implementation aspect from the exposed State and MetaState lends itself to a straightforward mapping assuming there is a correspondencebetween the component types of the UCM Implementation aspect and those of anintegrated system.For example, the ContextSource is similar in concept to a Context Widget inthe Context Toolkit, providing the capability to query and subscribe to contextchanges. The EventSource component can be used to describe the iROS EventHeap, providing the capability to subsribe to and receive arbitrary events. UCMChapter 3. The Ubicomp Common Model 67Services can be used to describe service oriented systems interfaces. When a sys-tem such as Cooltown, or Parc TAB provides servers that aggregate context andservices around entities, the EntityHandler can be used to describe these compo-nents in the UCM. Since an instance of the UCM describes an explicit environmentmodel, adapters for smart space systems such as Sentient Computing and EasyLiv-ing can keep their model in sync with the UCM by adding and removing static anddynamic entities and relationships as they change.Furthermore, the separation of Implementation concerns allows a supportingsystem to vary component aggregations independently of the exposed capabilities.This allows more than one system component to provide capabilities to a singleentity, or many entities to make use of a single component in an underlying sys-tem. An implementation of the UCM may change entity-component aggregationsdepending on the situation.The key to integration is the use of adapters which will supply an instanceof the UCM with descriptions of the components and entities of the integratedsystem as they are added and removed. The adapter will also delegate method callsfrom UCM applications to the integrated system's as appropr iate by maintaininga mapping of UCM component descriptions to the underlying system capabilities.The use of adapters for integration is discussed further in Chapter 4.Assuming the Implementation aspect is used to map existing systems abstrac-tions to a common model, at best we should expect to mirror the ?native? environ-ment programming model presented by a given system. In some cases, however,we may need to present the UCM as an alternative programming model, one that iseither higher level or lower level than the native model. The tradeoffs in providingthe UCM as an alternative programming model for existing systems is exploredfurther in Chapter 5 by creating applications that make use of several concurrentlyintegrated ubicomp systems.Chapter 3. The Ubicomp Common Model 683.5 Access Control and SecurityAs ubiquitous computing systems become more widely deployed, the need to pro-tect access to computing resources such as sensors and actuators becomes morenecessary. Sensors can record movement, activities and other information aboutusers in areas that can threaten user's privacy. With the use of a common modelfor ubicomp we can anticipate the need to provide access control for previouslyassumed private or closed ubicomp deployments.Recent research in the areas of security and privacy have explored the useof new metaphors for ubicomp security (e.g. virtual walls [67]) and the use oflightweight authentication approaches for resource constrained devices such as thatused in Bluetooth [86] and the Unmanaged Internet Architecture (UIA) [41].To highlight the UCM's extensibility, we describe how the UC M (EnvironmentMeta State) could be extended to support an access control abstraction used torepresent both security domain and access control mechanism. We then providean example of how this model extension could be supported in a future integrationplatform. We chose the Unmanaged Internet Architecture [41] in our examplesince it uses a novel peer to peer authorization mechanism, includes device groupmanagement and can serve as a secure base communications platform for otherubicomp systems (e.g. MyNet [66]).In the UCM, an application accesses the capabilities of an an associated entity.Note that we use the term capabilities as introduced earlier in this chapter, in theUCM sense, recognizing that this is not the same as capabilities in a capability-based operating system1. Recall that in the UCM, capabilities are the super classof ServiceInterfaces, ContextTypes, and EventType as shown in Figure 3.7. For1In capability-based systems capabilities are defined as unforgeable references to objects thatallow access to well defined operations on operating system objects such as files and devices.Chapter 3. The Ubicomp Common Model 69Entity exposes CapabilitypropertysubclassComponentaggregatesAccessControlimplementsOutOfBandIntroductionUserNamePassword SharedKeyFigure 3.9: Access control property associated with capabilities.example, in the home there may be a UCM capability (ServiceInterface) that allowsan application to control the lights in a room (entity). While UCM capabilities arealso references to computing resources, they are not unforgeable, and representonly the potential use of an integrated computing resource: access is by no meansguaranteed. In the remainder of this section we use the term capability to refer toa UCM capability and not a security capability.In a UCM deployment, computing resources in a ubicomp system are typicallyprovided by one or more underlying systems' adapters by adding UCM compo-nents to the model. UCM Components implement capabilities. When a componentis aggregated by one or more entities, these entities expose these capabilities asshown in Figure 3.9. UCM applications access computing resources by interactingwith entity capabilities.Here we assume that the computing resources accessible by an application arecontrolled as a group in a single administrative, network domain, perhaps withinvirtual walls [67], or individually (e.g. using Bluetooth). We can expect that thecredentials required for an application to access resources in a ubicomp system canvary from something as simple as a PIN, a user-readable string of words (used forout of band authentication [41]), or a public key.To illustrate how the core UCM can be extended to model both security do-Chapter 3. The Ubicomp Common Model 70personBobdeviceAccessControl roomAccessControlrestrictsoutdoorLocationTypemessageServicerestrictsexposes hasContextmeetingRoomactivityTypehasContextcontainsrestrictslightingServiceexposesrestrictsDevice Security DomainRoom Security DomainFigure 3.10: Example of AC properties used to mark security domains.mains and access control required to interact with computing resources in a ubi-comp system, we can add a new core abstraction we call an access control (AC).We say that an AC restricts capabilities as shown in Figure 3.9. When a capabilityis restricted with an AC property, this indicates that the capability is a member ofa security domain (such as a LAN, a server or individual device like a laptop) thatmay require participation by the UCM application in an access control mechanism(e.g. an out of band introduction, PIN, public key). In this way, entity capabilitiesin the UCM are grouped by domain and access control type as illustrated in Figure3.10.In the model example illustrated in Figure 3.10, the entity personBob has twocapabilities, one (a ContextType) is used to retrieve Bob's location (outdoorLoca-tionType), another (a ServiceInterface) allows applications to send SMS messagesto Bob (messageService). Another capability allows us to retrieve Bob's currentChapter 3. The Ubicomp Common Model 71activity (activityType). A ServiceInterface of the room entity (meetingRoom) al-lows applications to control the lighting (lightingService). Access to the outdoor-Location and messageService are controlled by Bob's device, whereas the activi-tySource and lightingService are controlled by a ubicomp system installed in themeeting room. To indicate this, the messageService and outdoorLocation are re-stricted by an AC instance called deviceAccessControl; the activityType and light-ingService are restricted by the roomAccessControl as shown. Note that there is notnecessarily a correspondence between how entities group capabilities and securitydomains marked by an AC instance.By associating access control instances with capabilities, and subclassing acore AC abstraction class as shown in Figure 3.9 we can extend the UCM to includeinformation about both the security domains and access control mechanisms usedin integrated systems.Using this extension to the UCM it should be possible to limit the access andvisibility of specific integrated resources to UCM applications. For example, eachUCM application may have an associated access control list. When the model isqueried in an integration platform like the UIF described in Chapter 4, this listcan be checked against the capability AC restriction to either hide or expose thecapability for that application. The use of AC abstractions in an executable modelmay also be used by a supporting system to reason about security domains at runtime, adjusting security domains depending on the context of certain entities forexample.Note that neither capabilities nor their associated AC identifiers are used as thecredentials needed to access a system's resources. ACs repr esent a security domainand the mechanism required in the UCM. We expect to rely on the underlyingsystem to ensure that a UCM intermediary authenticated and secured within theirsecurity domain(s).Chapter 3. The Ubicomp Common Model 723.5.1 Security ExampleAs an example of the use of the access control abstraction, we discuss how theUnmanaged Internet Architecture (UIA) [41] security domain and access controlmechanisms could be supported by a UCM implementation. This may be necessarywhen the user wishes to access personal devices such as a mobile phone from aUCM application.The UIA is a peer-to-peer connectivity architecture where each user is the ad-ministrator of his or her personal group containing their mobile and personal de-vices. Users can ?merge multiple UIA devices to form a personal group, afterwhich the devices work together to offer secure access to any device in the groupfrom any other.?[41]. Similarly, users can create shared groups to share access oftheir personal devices with others. When a user wants to add a new device to agroup, the UIA finds other devices in the group (e.g. one discovered on a wirelessLAN or via social network). The user then selects ?Introduce Devices? on the newdevice and one already in the group to start an introduction process. An introduc-tion key consisting of three words chosen randomly from a dictionary is shown onthe display of both devices. Users then choose the other device's introduction keyfrom a list of three other random keys to complete the introduction. If a matchingkey is not found, the procedure is aborted. The user ensures that the introductionkey of the other device is correct since it is highly unlikely that an impersonator onthe wireless LAN will supply another random key that matches. Other aspects ofthe UIA security mechanisms are discussed in [41]In a typical UCM deployment, UCM applications will be proxied by an inter-mediary such as the UIF platform and adapter described in Chapters 4 and 5. Toaccess devices in a UIA personal group, an adapter must become a member of thatgroup using the UIA introduction process as shown in Figure 3.11.Chapter 3. The Ubicomp Common Model 73UIFAdapterApplicationFirewallLANDeviceDeviceUIA Personal GroupintroductionDeviceFigure 3.11: Access control and security example: introducing a UIF adapterinto a UIA personal group.To do this, capabilities discovered in the LAN by an integration system adapter(as described in Chapter 4) are marked (i.e. restricted) with an AC instance thatrepresents a UIA group. The type of the AC instance is used to indicate that an?out of band? introduction process is required. An example of this is shown inFigure 3.12. Bob has two capabilities supplied by his mobile phone restricted bythe uiaPersonalGroup. The uiaPersonalGroup is an instance of an OutOfBandIn-troduction AC abstraction as shown.PlaceMedia is a web application that displays the positions of friends andplaces of interest on a Google map [40] as described in Section 5.1.1. For a UCMapplication such as PlaceMedia to interact with a capability, the integration system(UIF) delegates calls to an adapter as described in Chapter 4. The adapter then pro-cesses the call by marshalling the request and response to and from the integratedsystem.For example, the PlaceMedia application would like to retrieve the position ofChapter 3. The Ubicomp Common Model 74personBobuiaPersonalGroupoutdoorLocationTypemessageServicerestrictsexposes hasContextrestrictsrdf:typeOutOfBandIntroductionAccessControlUIA Personal GrouppropertysubclassFigure 3.12: Example of capabilities restricted by UIA personal group.the user to display on a map. This could be done by accessing a user's mobilephone which is a member of the user's UIA personal group. To do this, the UIFdelegates the location (context) request to the UIA adapter. The UIA adapter canthen delegate the call to a UIA device to process the request.When the adapter is not yet a member of the UIA personal group the phonebelongs to, the UIA adapter will need to be introduced to the device. To do this, theadapter can trigger the UIA introduction process and return a ?challenge? responseto the UIF. The response will include public information needed by a PlaceMediauser to complete the introduction. The UIA introduction key of the adapter can beincluded in the challenge.If the adapter host is near the mobile phone, the standard UIA introduction userinterface can be used on both the adapter and the phone to complete the adapter-phone introduction.For situations when the PlaceMedia user is not near the mobile phone, Place-Media can display the adapter's introduction key supplied w ith the challenge re-sponse. The introduction between the adapter and the mobile device can then beChapter 3. The Ubicomp Common Model 75completed remotely by the PlaceMedia user and the mobile phone owner by voice,SMS or email to ensure the introduction keys match [41]. When both users de-termines that the intoduction key is correct, PlaceMedia can continue the processby making an ?authentication? call with the remote introduction key to signal theadapter to complete its side of the introduction process. The mobile phone user cancomplete his or her side using the standard UIA interface.Once authenticated, future requests to the mobile phone in the UIA personalgroup will now succeed since the adapter is now an introduced member of the UIApersonal group. As described in [41], the owner of the personal group can revokethe adapter's membership at any time; the adapter will need t o be introduced againto access the mobile phone.To support other authentication mechanisms, other (public) information canbe provided in an authentication challenge and/or response in the same way. Forexample, public keys carried with an end user device such as a mobile phone as inthe Instant Matchmaker [93] can provide the necessary credentials when a UCMapplication is challenged for access to a resource. Of course, integration with theintegrated systems' access control mechanism assumes there is an API, or code isavailable2 to allow an adapter to trigger the introduction process and retrieve theintroduction key displayed in the dialogs as described.Our treatment of this example is deliberately informal and is meant only toillustrate how a given security framework like the UIA may be supported by theUCM access control extensions and an integration system. We recognize that givena specific security framework, an implementation may require a thorough and for-mal analysis to ensure all security requirements are satisfied. However, from ourinitial investigation and as described above, we are optimistic that the UCM is ableto gracefully support a meta level security model that maps naturally to underlying2see http://pdos.csail.mit.edu/uia/Chapter 3. The Ubicomp Common Model 76security models as implemented by existing systems.3.6 Use Cases for an Executable UCMTo use the UCM for creating and maintaining an integrated ubicomp environment,it must be instantiated in a supporting sytem. By expressing the UCM explicitly us-ing semantic web languages such as the Web Ontology Language (OWL) [102] andthe Resource Definition Framework (RDF) [101] it is possible for such a system tostore, query and infer new information about an integrated ubicomp environmentusing Semantic Web tools and libraries such as the Jena Semantic Web Framework[1] in an integrated system. In this section we summarize several environmentdesign/integration time (static), and run time use cases for for an executable UCM.3.6.1 Design/Integration Time Use CasesAt environment design time, the UCM expressed as an ontology can be used todescribe the initial state and static aspects of the environment model. This includesthe following:Static environment model descriptions. In any environment there are staticentities such as rooms, furniture, and fixed devices. The UCM can be used todescribe these entities and their static context such as the location of fixed objectsor the name and email address of a user. Important static relationships such asrelative location can also be described. For example, a printer is containedIn aroom, and a meeting room is nextTo an office.Interface semantics and context quality. Even when a component exposesthe same interface, the behavior or quality of its service may vary from one imple-mentation to another. A GPS location sensor may provide location accuracy of 5moutdoors whereas an indoor location sensor may provide only room level accuracy.Chapter 3. The Ubicomp Common Model 77Semantic descriptions can make the quality and semantics of an interface explicitto applications so that they know when they can and should be applied.Component configuration information. In a supporting system such as theUIF described in the next chapter, components in the system may be implementedby native Java classes or by integrated ubicomp middleware. In the UCM, a bindingproperty of a component is used to associate a component in the model with a nativeJava class implementation, while an adapter property associates the componentwith integrated middleware.Initial entity-component dependencies. A physical entity such as a devicewill often have services, context or events associated with it. The aggregation re-lationship between entities and implementation components establishes the initiallink between the conceptual or exposed model of an environment and its imple-mentation components.3.6.2 Run Time Use CasesA challenge for any ubicomp system is in managing the dynamic aspects of anenvironment for applications. In our system, the UCM used with an associatedreasoning engine can be used to maintain the exposed model and associated com-ponents as their composition changes. We have explored the following run timeuse cases for an executable UCM:Entity Composition. When new entities such as mobile users and their en-vironment arrive and leave the environment, associated information about theseentities can be added or removed from the model. A reasoning engine can thenassociate these new entities with the appropriate components, types and serviceinterfaces.Context Inference. Ontology-based systems such as [27, 51] have shown thatChapter 3. The Ubicomp Common Model 78it is possible to use an integrated reasoning engine to infer higher level context fromlower level context information. Cooltown [68] and other systems have demon-strated the value of entity relationships for service discovery and other use cases.A reasoning engine with appropriate rules can be used to infer such relationshipsfrom lower level context information. For example, the following rule establishesthe near relationship when one entity is within 50 metres of another.[(?entity1 ucm:near ?entity2) <-(?entity1 ucm:location ?position1)(?entity2 ucm:location ?position2)notEqual(?entity1, ?entity2)inRange(?position1, ?position2, 50)]Dynamic component call/message dispatch. At run time, an environmentmodel described using the UCM can be queried to determine the component thatcurrently supplies the requested service or context which may depend on the cur-rent situation. For example, one context source may be used to determine a user'slocation indoors and another outdoors. The following rule will aggregate a contextsource (csIndoorPositionSource) for providing indoor position information onlywhen a Person entity is containedIn the csBuilding place.[(?entity ucm:aggregates campus:csIndoorPositionSource) <-(?entity rdf:type ucm:Person)(?entity ucm:containedIn campus:csBuilding)]Entity classification and discovery. A client of the system or internal compo-nent may need to find the entities in the environment that match a certain criteriasuch as its type, the service interfaces, or context types they provide. Similarly,clients or components may need to know the interfaces or context supported by agiven entity.Situation events. With an integrated model of an environment, it is possible toquery or be notified when a certain situation exists in the environment as a whole.Chapter 3. The Ubicomp Common Model 79For example, one can query whether there is more than one user entity containedin a meeting room. This may be used by an application to infer that a meeting maybe starting to call appropriate services.Security. If the model is executable, the capabilities accessible (e.g. associatedwith access control properties as described in Section 3.5) by UCM applicationscan change depending on the context of various entities such as users location inthe model, permitting context-based security mechanisms. Of course there are anumber of assumptions such as the integrity of context that are critical for consid-eration in the use of the UCM in these scenarios.3.7 SummaryIn this chapter we presented the requirements for a common programming modelfor ubicomp based on core abstractions shared by several representative ubicompsystems surveyed in Chapter 2. These shared abstractions are an environmentmodel, entities, entity relationships, context, services, events and data or content.Using a simple example we demonstrated how these abstractions can be used tomodel an environment leading to the the design of the Ubicomp Common Model.The UCM is an entity-centric model consisting of three related aspects: the En-vironment State containing context and entity relationships, Meta-State containingentity capabilities such as context types and service interfaces, and Implementa-tion containing implementation components such as context sources and services.We discussed the UCM's suitability for meeting several requirements of a commonmodel: application portability, specialization for different environments, introspec-tion, its suitability for adaptation to existing systems, and extensibility to supportemerging security mechanisms. Finally we presented use cases for an executableUCM in a supporting system such as the Ubicomp Integration Framework (UIF).Chapter 3. The Ubicomp Common Model 80The UIF used to evaluate the UCM's suitability for ubicomp systems integration isdescribed next.81Chapter 4The Ubicomp IntegrationFrameworkIn this chapter we present the Ubicomp Integration Framework (UIF), a meta-middleware platform that uses the UCM for both application development andubicomp system integration. Its primary use is to expose the functionality of ex-isting ubicomp systems in a controlled and unified manner. In this way the UIFcan then be considered a sophisticated wrapper or Facade [44] that encapsulatesone or more ubicomp system with a service interface. In reality the UIF is morecomplex than its role implies since it provides a composite model of an integratedenvironment, and so contains much of the functionality of other ubicomp middle-ware platforms. In this chapter we describe the architecture and implementationof the UIF system and associated adapter framework in some detail. Readers whoare more interested in the use of the UCM for application and adapter developmentthan the UIF implementation details may prefer to skip much of this chapter andinstead turn to the summary in Section Analysis and ApproachThe UIF is used to assess the feasibility of using the UCM to unify the program-ming model of existing ubicomp systems for both application portability and sys-Chapter 4. The Ubicomp Integration Framework 82tems interoperability. In the next Chapter (5), we describe our experience using theUCM in the UIF to unify the abstractions of four representative systems to managea composite environment model. This composite model can then be accessed byapplication developers using a single API.To accomplish this, we require software to map the various data formats, in-terfaces and protocols of underlying systems to a common protocol, effectivelypresenting a homogeneous view of the integrated underlying ubicomp systems tothe integration framework. Unlike other ubicomp systems that also provide a ho-mogenous execution environment for applications such as those in discussed inChapter 2 and others (e.g. [72] and more recently [14]), we aim to accomplishthe same goal by integrating existing ubicomp systems, accessing as much of theirfunctionality using their existing APIs. This will demonstrate the feasibility of us-ing the UCM to integrate systems and how well the UCM is able to capture theabstractions of representative systems.4.1.1 Analogy to Enterprise Application IntegrationIn the Enterprise Application Domain (EAI), integrators face similar problemswhen attempting to integrate diverse applications in a business. Unlike the EAIdomain however, our main focus is not to integrate applications, but middlewaresystems that coordinate computing resources. Because of this, several well un-derstood (and often less arduous approaches) to enterprise integration cannot beapplied directly.For example, in some cases, enterprise applications are integrated at the pre-sentation or user interface level [71, 88]. This can be done by screen scraping theintegrated application, or combining the user interfaces into a web portal. The ad-vantage of this approach for the integrator is that it is relatively easy to accomplish,Chapter 4. The Ubicomp Integration Framework 83but it often means that there is strong coupling between the integrated applicationor interface and the integrated system. This approach is not feasible for our tasksince several ubicomp systems we aim to integrate do not always have a presenta-tion layer or user interface. Another enterprise integration approach is to integratethe data held by applications. This may involve data replication, federating data,or the use of interfaces that provide access to the data in integrated applications.This approach is sub optimal for our integration task since we need to access notonly the changing environment model and state of an integrated system, but alsothe functionality of those systems.Finally, enterprise integrators have used a functional integration model that al-low potentially new applications to invoke existing functionality from new applica-tions [88]. This is done using the available APIs to the integrated applications. Toensure we are leveraging the programming abstractions provided by an integratedubicomp system through its APIs, and to validate our integration model, this is theapproach (necessarily) taken in our integration task for evaluating the UCM.Within the functional integration model, an integration can ensure data con-sistency across applications, coordinate actions across integrated applications, anduse well defined service interfaces (called a service oriented [71] or plug and playintegration [88]). In our task, we similar goals in that we aim to ensure that as-pects of the composite environment model held in an integrated system are kept insync with that of the integrated ubicomp system's model (dat a consistency). Wealso aim to use existing systems in a coordinated manner to add new functionality(e.g. applications, composite services, inferred context and entity relationships) inthe integration framework itself. Enterprise integrators typically use adapters forwrapping applications in a well defined interface [12, 71, 88]. A different adapteris typically required for each integrated application. For integrating ubicomp sys-tems, we take a similar approach, providing an adapter for each type of system weChapter 4. The Ubicomp Integration Framework 84aim to integrate. In our case we use the same interface for all adapters.Although not all EAI approaches can be directly applied to ubicomp systemsintegration, we were influenced by well known EAI methodologies and more recententerprise middleware implementations using ontologies (e.g. [78]). An importantstep during analysis for EAI is to determine the high level ?business entities? inan enterprise leading to the identification of the component interfaces needed forintegration [88]. In the EAI domain the basis for identifying entities is often thevarious functions in an enterprise such as R&D, Production, Marketing, Sales, Dis-tribution, Service, Accounting, and Personnel. In EAI as in ubicomp, there are alsocross functional entities like people and organizations. In the ubicomp integra-tion domain, our basis for identifying entities and components are the abstractionspresent in representative ubicomp systems (e.g. context, events, services, content)and the physical world (people, places, things, their relationships) as described inChapters 2 and 3. Unlike typical enterprise applications, ubicomp systems are gen-erally cross functional in the sense that they are (typically) designed to support avariety of applications.In both the EAI and ubicomp domains, the semantics of the various abstrac-tions must be consistent for cohesion in a unified programming model for newapplication developers. Because of this, many working in the EAI domain havebegun to use ontologies ?to provide a shared and common understanding of data(and in some cases, services and processes) that exists within an application inte-gration problem domain?1. While recognizing that there are differences betweenthe abstractions of an enterprise integration and ubicomp, we also employ ontolo-gies. In a typical EAI deployment, however, the available functionality and itsrelationship to business entities is often fixed at design time. In an integrated ubi-comp environment, the available functionality and entities will change dynamically1[71] pp 394Chapter 4. The Ubicomp Integration Framework 85as discussed in Section 3.6.2. Because of this, we need facilities to for managing aintegration model that can be changed at runtime by adapters, applications and bythe integration framework itself.4.1.2 Environment Model ManagementSince our goal is to unify these systems in a composite environment model, we alsoneed a way to manage this model (i.e., an instance of the UCM). The UIF modelsubsystem will provide the rest of the integration framework with the informationneeded to correctly select and make use of an underlying system to satisfy a givenapplication request.In a composite ubicomp environment, multiple integrated ubicomp systemswill typically be involved in context provisioning or in the implementation of in-tegrated services. The underlying services and sensors used by an application ata given time may also depend on the situation. For example, in an indoor envi-ronment, location information may be provided by a Context Toolkit widget, butwhen the user is outdoors, location may be provided by wide area mobile phone in-frastructure. We need an approach that allows an integrator to coordinate both thestatic and dynamic aspects of an integrated environment model. More specifically,we need an approach that provides the integration framework with the knowledgeof the static and dynamic relationships between computing resources such as soft-ware services and sensors, and people, places and things.We can satisfy this requirement by instantiating the UCM directly in the inte-gration system itself. This will also satisfy a requirement for our model highlightedin Section 3.1, that is, for the model to be executable, i.e., queried and reasonedwith by the system. Applications will query the model to discover entities and theircapabilities for interaction and to determine whether their requirements can be sat-Chapter 4. The Ubicomp Integration Framework 86isfied. Direct support for reasoning in the integration platform will also allow thesystem to satisfy the run time use cases presented in Section 3.6.2 such as entitycomposition, context interpretation or inference, and dynamic call dispatch.Initially we considered meeting these objectives using a relational databasesuch as MySQL [8] or another data store. After some initial prototype work how-ever, we decided to make use of semantic web technologies to manage our integra-tion model. This decision was based on four factors.1. We first considered the flexibility that the use of semantic web technologiesoffers in terms of modeling, query (e.g. using SPARQL [103]) and reasoningsupport, gaining an understanding through prototypes and experimentation.2. We noted the increasing breadth and depth of tools available to create, andmanage ontologies and models that use OWL and RDF. Design tools such asthe Protg ontology editor [9] and plug ins for the popular Eclipse IDE [4, 6]are available for ontology design. Frameworks and toolkits [24, 73], highperformance knowledge bases [53, 110] and reasoning engines [52, 92] arealso available.3. Since we aimed to integrate existing ubiquitous systems using applicationservers we also considered recent enterprise middleware approaches calledOntology Driven Architectures (ODA) [78, 100]. ODAs use an integratedknowledge base and reasoning to ease the development and management ofapplications hosted by enterprise application servers.4. The use of Semantic web technologies has emerged as a well established ap-proach to managing context and configurations in ubiquitous systems asdemonstrated by Gaia [84], the Context Broker Architecture (CoBrA) [26?28], the Service Oriented Context Aware Middleware (SoCAM) [51] andChapter 4. The Ubicomp Integration Framework 87others [30, 99].Based on these considerations, we decided to make use of semantic web tech-nologies and an Ontology Driven Architecture to assist in the configuration and runtime maintenance of the composite environment model managed by the UIF. Aninstance of the Ubicomp Common Model (UCM) is created by an integrator usingto specify the static configuration of the environment. The desired response to dy-namic run-time changes such as the addition of new entities and components aredescribed using rules executed by an integrated reasoning engine [1] that maintainsboth the exposed aspects of the model (Environment State and Meta State) and theimplementation as the composition of the environment changes.4.1.3 Cross-Domain InteractionSince we aim to support access to ubicomp systems from applications outside ofthe administrative domain where an integrated ubicomp system is deployed, weprovide a standards-based Web Service interface to the UIF. The use of Web Ser-vices makes the UIF accessible and potentially discoverable on the Web throughfirewalls and across wide area networks. With a standards-based wide area se-curity framework [81] Web Services can be accessed in a secure manner. Othermobile and ubiquitous systems such as ReMMoC [45] and WSAMI [62] as well ascommercial systems such as UPnP [74] have proven the value of providing a WebService abstraction around individual environment resources. While these systemshave demonstrated that the use of Web Service is a workable solution in somecases, our aim is more ambitious: unlike these systems, we aim to wrap wholesystems that expose higher level abstractions such as environment models, entitiesand relationships, as discussed in Chapter 2, not just individual components orservices.Chapter 4. The Ubicomp Integration Framework 88While the use of other protocols is possible, there are several benefits to the useof Web Services [109]. They are relatively simple to use with application servers,especially with the variety of tools and frameworks available for virtually all pro-gramming languages today. Based on industry standards, they have been widelyadopted for cross-domain communications. Web Services promote loose coupling,since only the service and connection is described, independent of the implemen-tation at either end. They are self describing and discoverable on the Internet.Finally, while HTTP is often the transport used, other transports can be supportedby a given Web Service for more efficient internal communications over privatenetworks. However, despite the numerous benefits there are some drawbacks tothe use of Web Services, particularly in the area of performance. Scenarios likeours will incur overhead since the Web Service tools transform method calls toand from XML-based SOAP messages. Furthermore, our integration system willnecessarily add an additional layer on existing systems for routing method calls.However, through the careful application of Web Services best practices [31], webelieve that the benefits of using Web Services outweigh these cost. In the follow-ing sections we describe the implementation of the UIF including our use of WebServices in more detail.4.2 Implementation OverviewThe UIF is a tiered enterprise server application as shown in Figure 4.1. The systemperforms three essential functions:1. It serves as a repository for knowledge about a composite environment model.This ?knowledge? consists of information contributed directly by an integra-tor, by ubicomp system adapters at run time, or deduced by an integratedreasoning engine and integration rules.Chapter 4. The Ubicomp Integration Framework 89ApplicationWeb Services FacadeMessage BrokeriROSAdapterCTKAdapterECTAdapterEnvironment CompositionLogicNative Component ContainerModel andReasoner ModelStoreDomainBoundaryiROS Components CTK Components ECT ComponentsUbicomp Integration FrameworkDistributedAdaptersApplication ApplicationFigure 4.1: Ubicomp Integration Framework Architecture.2. The UIF dispatches method calls from applications to the appropriate (dis-tributed) adapter or internal components based on the raw and inferred datain this repository.3. The system manages event subscriptions for clients of the composite model,ensuring subscriptions to asynchronous events are propagated correctly andmaintained as long as the corresponding integration adapter is available.Figure 4.2 illustrates the typical interactions between UIF subsystems when anapplication requests context for an entity. First, the application makes a call tothe Facade Web Service to get context (1). This is delegated to the EnvironmentComposition Logic (ECL) (2) which makes a request to the Model and Reasonersubsystem (3) to get the component information that handles the specified entityand context attribute (4). Based on this information, the ECL then queries a nativecomponent hosted by the Native Component Container for the context value (A.5)Chapter 4. The Ubicomp Integration Framework 90ApplicationWeb Services FacadeMessage BrokerEnvironment CompositionLogicNative Component ContainerModel andReasoner ModelStore2. get context for entity, attribute1. get context value for entity, attribute3. get component for entity, attribute4. context source component informationUIF hosted by application serverA.6 context valueA.7, B.11context valueA.8, B.12context valueB.5 get context value from adapter componentB.10context valueCTKAdapterB.6 get context value from adapter componentCTK ComponentB.7 get context valueB.8 context valueB.9 context valueA.5 get context value from native componentDistributed AdaptersApplications outside domainFigure 4.2: High level interaction between UIF subsystems.or forwards it to the Message Broker (B.5). If a native component handles therequest, the context value is returned to the application (A.6, 7, 8). If it is handledby an integrated system, the Message Broker forwards the request to a distributedadapter (B.6), in this case the Context Toolkit (CTK) adapter. The adapter thenmakes the query to its component (B.7) and the context value supplied is returnedto the application (B.8, 9, 10, 11, 12). Note that it is also possible for (static)context to be maintained in the model. In this case, the ECL will query the modelfor the context value (not shown).The Facade subsystem provides a SOAP-based [104] Web Service interface toapplications for cross domain interoperability. As described, calls to the Facade areChapter 4. The Ubicomp Integration Framework 91delegated to the Environment Composition Logic (ECL) subsystem. The ECL isnot only responsible for dispatching queries, but also for maintaining subscriptionsto asynchronous events.The Model and Reasoner subsystem maintains the current environment modelincluding the UCM itself, specializations of the UCM, entity instances, static con-text values, capabilities, component descriptions and their relationships. Queriesfor entities based on their types, capabilities and static context are handled directlyby the Model subsystem since this information is maintained in its knowledge base.Based on rules supplied with the UCM and an integrator, an integrated reasoningengine can establish new relationships depending on entity types and context valueswhen components or entities are added or removed from the model by an adapteror an application.The Native Component Container hosts internal ?native? UCM components in-stantiated by the system either on start up, or when first accessed by an application.A typical use of a native component by an integrator is to provide a composite ser-vice, or a specialized context inference capability for the integrated environment.For example, in the case where user entities aggregate an SMS messaging service,an integrator can create a new service to send SMS messages to friends of a user,or users contained in a certain building or room. This new broadcast service makesuse of the SMS messaging services of an integrated system. Similarly, an integratorcould create a simple context source that provides the number of users in a roomby counting the entities contained in that space.Method calls destined for an adapter are dispatched by the Message Broker asdescribed. Distributed adapters transform the method call to and from the inte-grated system's data structures and APIs as needed.To support asynchronous events, applications supply subscription parametersspecific to the event type. The adapter associated forwards the subscription to theChapter 4. The Ubicomp Integration Framework 92native system and maintains an internal mapping to the underlying system sub-scription. Later, when an event is signalled by the integrated ubicomp system, itsadapter marshals the event data to a common UIF EntityEvent data structure,and sends it to the UIF. The ECL looks up the associated subscriber and queues theevent for application retrieval.The UIF was implemented using the JBoss [7] Java 2 Enterprise Edition (J2EE)[97, 98] server, a fairly standard platform for enterprise application development.The UIF consists of approximately 7800 lines of Java code and other components.The UIF Model subsystem wraps a Resource Description Framework (RDF) storeand general purpose rule-based reasoning engine supplied with the Jena SemanticWeb Framework [1]. The initial model of the environment consists of the UCMand environment-specific ontology loaded when the system starts. Static entity,context and component descriptions are also loaded at start up, along with defaultrules supplied by an integrator. Our prototype deployment described in Chapter5 consisted of 535 RDF triples and 278 rules. The Broker communicates withAdapters using Remote Method Invocation (RMI) [38] so they can be distributedin an integrated environment. The adapter framework and implementations areapproximately another 3000 lines of Java code. In the following subsections wedescribe each subsystem in more detail followed by a discussion of our adapterframework.4.3 FacadeTo implement the UIF Facade Web Service we have used both the Axis [10] andJBossWS [5] Web Service frameworks. These frameworks can provide server andclient side code to marshal method calls to and from SOAP, and generate WSDLfrom an supplied Java class or interface. Using tools supplied with either of theseChapter 4. The Ubicomp Integration Framework 93frameworks we generated the appropriate server side deployment files and WSDLfor the Facade interface.One challenge specific to our integration task, however, is the need for a genericdata type that is flexible enough to support complex service parameters, event dataand context information while making it easy to marshal to SOAP by differentWeb Services frameworks, not only for Java applications but other languages suchas C# and C++. While we could have considered the use of RDF as a data ex-change format, we did not want to force application developers to include an RDFparser. We required a data structure that can be marshaled easily to and from thevarious data formats needed by an integrated system, and to and from the RDF-based knowledge base and reasoning system in the UIF. To accomplish this wecreated the DataObject data structure and associated utility classes for convert-ing any data structure to and from native Java and RDF. Fields in a DataOb-ject are strings (names, values), integers (type) or nested DataObjects to supportcomplex data structures and arrays; it should be a straightforward task to provideDataObject converters for other languages. Applications typically exchange datawith the Facade Web Service using ContextValue and EventSubscription datastructures that use the DataObject where a generic data structure is needed.There are four categories of Facade methods:? Application authentication. The system must be able to authenticate ap-plications that are allowed to make use of the integrated environment. Inthe UIF, an application must log in with its client id before it can access themodel. The following methods of the Facade interface are in this category.// Application authenticationpublic String login(String clientId,String password) throws RemoteException;public void logOut(String clientId) throws RemoteException;Chapter 4. The Ubicomp Integration Framework 94? Model Composition. Methods in this category allow an application to addand remove entities such as users, objects, places and other entities to themodel. These include the following methods:// Model compositionpublic String addEntity(String clientId,EntityInfo eInfo) throws RemoteException;public void removeEntity(String clientId,String entityId) throws RemoteException;? Entity Interaction. These methods support interaction with the entity's ca-pabilities: getting current context values, entity relationships, content, call-ing services, subscribing to and retrieving events.// contentpublic String getContent(String clientId,String entityId, String contentAttr) throws RemoteException;// eventspublic EntityEvent[] getEvents(String clientId, int timeout)throws RemoteException;public void subscribe(String clientId,EventSubscription[] eventSubs, String eventListener)throws RemoteException;public void unsubscribe(String clientId, int subId) throws RemoteException;public int addSubscription(String clientId,EventSubscription eventSub)throws RemoteException;public void unsubscribeAll(String clientId)throws RemoteException;public EventSubscription[] getSubscriptions(String clientId) throws RemoteException;// relationshipspublic String[] getRelatedEntities(String clientId,String entityId, String relationship) throws RemoteException;public void addEntityRelationship(String clientId, String entityId,String otherEntityId, String relationship)Chapter 4. The Ubicomp Integration Framework 95throws RemoteException;// servicespublic DataObject callService(String clientId, String entityId, String serviceType,int serviceId, String methodName, DataObject[] parms)throws RemoteException;// contextpublic ContextValue getContextValue(String clientId, String entityId, String attribute)throws RemoteException;public void setContextValue(String clientId, String entityId, String attribute,ContextValue context)throws RemoteException;? Introspection and Capabilities Finally, methods in the last category sup-port finding entities by (RDF) type, or using a SPARQL [103] select clause,and discovering the current context attributes, service interfaces and eventsexposed by an entity.// Introspection and capabilitiespublic String[] findEntities(String clientId, String selectWhere) throws RemoteException;public String[] findEntitiesByType(String clientId, String entityType) throws RemoteException;public String getEntityDescription(String clientId, String entityId) throws RemoteException;public String[] getContextAttributes(String clientId, String entityId) throws RemoteException;public String[] getImplementedServices(String clientId, String entityId, String serviceType)throws RemoteException;public String[] getEventsFired(String clientId, String entityId) throws RemoteException;To access objects in other subsystems, the Facade methods access static meth-ods in the UIF object as shown in Figure 4.3. Note that while applications may bepermitted to add new entities, or set context, they can't themselves access, add orChapter 4. The Ubicomp Integration Framework 96remove new components into the system. This is the role of adapters, described inSection 4.8. Methods in all four categories of the Facade are delegated to objectsin the Environment Composition Logic described next.4.4 Environment Composition LogicThe Environment Composition Logic subsystem contains three key interfaces ? theEnvironment, Entity, and the ClientManager as shown in Figure 4.3. Envi-ronment and Entity objects handle all access to the model, integrated systemsand components, while the ClientManager manages application authenticationand subscriptions to asynchronous events.4.4.1 Environment and Entity InteractionA Facade call that interacts with the environment as a whole, such as findEntitiesor addEntity, will delegate to an instance of Environment. This call will thenquery the Model and Reasoning subsystem described in Section 4.5.A Facade call that interacts with a single entity, using methods such as get-ContextAttributes or callService, will first bind an Entity to a resource id in themodel. Binding associates the Entity with a resource in the model encapsulatedby a ModelEntity object. The Facade then calls methods on the Entity instance,which in turn queries the model through the ModelEntity. Wrapping the model ininterfaces in this fashion allows our queries and model implementations to changewithout affecting the ECL.To interact with a component (either hosted by the UIF or in an underlying sys-tem) the Entity object will first query the Model for the component that handlesthe request (i.e., an event subscription, service call, or context query). The En-tity method then delegates the request to either a Native Component, or the Mes-Chapter 4. The Ubicomp Integration Framework 97UIFECL::Environment-ontEntity : ModelEntityECL::Entity ECL::ClientManager-subscriptions-eventQueueECL::ClientSession?interface?Model::ModelEntity1-ontEntity1-_11-clientManager_11?instantiate? ?instantiate?1-clientSessions?interface?Model::IntegrationModel?uses??interface?Model::ModelComponent?uses?Facade?uses??uses??uses? ?uses?Figure 4.3: Key classes of Environment Composition Logic.Chapter 4. The Ubicomp Integration Framework 98Facade UIF Entity ModelEntity ModelComponent AdapterManagergetEntity(id)new Entity(id)IntegrationModelgetEntity(id)ModelEntitycallServicegetServiceImplementationsgetAdapterNameinvoke(adapterName, componentId, entityId, ...)RemoteAdapterinvokeService(componentId, entityId, ...)adapterNamemodelComponentMessage1Web Services FacadeEnvironment Composition Logic Model Broker and AdaptersRMIcallService(entityId, interface, params)ApplicationFigure 4.4: Sequence diagram for Facade.callService().sage Broker. A simplified sequence diagram for the Facade callService method isshown in Figure 4.4.In addition to illustrating the message flow, this diagram highlights potentialsources of overhead incurred when introducing the UIF between an applicationand an integrated system. We incur overhead from the Web Service library whenit marshals the SOAP call to the corresponding Java method. Another potentialdelay is incurred when the Environment Composition Logic queries the Integra-tion Model. Before it is finally handled by a native ubicomp system, it must bedelegated by the Broker, and processed by the appropriate remote adapter. Thesesources of overhead are discussed in more detail in Chapter 5, Section 5.4.3.Chapter 4. The Ubicomp Integration Framework 994.4.2 Application and Subscription ManagementThe UIF ClientManager shown in Figure 4.3 handles application authenticationand subscriptions to asynchronous events. From our experience, managing sub-scriptions for an integrated environment is not trivial since a single compositemodel event may be signalled by multiple event sources in more than one sys-tem. Furthermore, applications must be informed when an event source associatedwith one or more subscriptions is no longer available.When an application logs in using the Facade, the client id is validated, anda new ClientSession object is created. ClientSessions contain a list of eventsubscriptions and a queue of events for application retrieval as shown in Figure4.3.When an application subscribes to an event, an EventSubscription is addedto the ClientSession. An EventSubscription contains a unique subscription id,the application client identifier, entity identifier, the event name and a subscriptiondata structure specific to that event type. One event supported by the MUSEcapsystem [40] (discussed in Section 5.3.4) called a nearEvent is fired when usersare near particular places or other users. In this case, the nearEvent subscriptiondata contains entity ids, and the distance between the entities that causes the eventto fire. The subscription is then delegated to the appropriate Entity object andaggregated EventSource component(s) using the same pattern as the service callexample in Figure 4.4.If the subscription is destined for an integrated system, the subscription is for-warded to the appropriate adapter by the Message Broker. Since a distributedadapter may fail, our Message Broker called the AdapterManager maintains anadapter-subscription mapping in case an adapter is shut down or fails. When thisoccurs, the AdapterManager sends an event to the ClientSession (and asso-Chapter 4. The Ubicomp Integration Framework 100ciated application) indicating that the subscription has expired. If an individualEventSource in an integrated system is shut down, it is the responsibility of theadapter to signal to the UIF on its behalf. The UIF will then signal applicationsubscribers that the event capability of that entity has been removed.Note that, in some cases, multiple EventSources may supply the same namedEventType capability. This is the case when an entity exposes an event such ascontextUpdate which is signalled when any context value changes. In this casea single event subscription to a contextUpdate event must be dispatched to morethan one event source, potentially implemented in multiple systems. Because ofthis, event subscriptions are reference counted in the UIF. They can be removedfrom a ClientSession only when there are no remaining event sources holding thesubscription.When an Adapter signals an event on behalf of an integrated system, it sup-plies the client id of the subscribing application, and an EntityEvent data struc-ture that includes the subscription id, the event name, the entity id of the entitythat exposes the event and the event-specific data. The client id is used to look upthe ClientSession object in the ClientManager so that the event can be relayed tothe application. An application supplies a subscription id to unsubscribe from anevent. The unsubscribe call is dispatched to the AdapterManager, removed fromits adapter-subscription list, then forwarded to the appropriate Adapter.To summarize, The ClientManager component of the Environment Composi-tion Logic authenticates applications and tracks their subscriptions to events. Over-all the Environment Composition Logic is responsible for querying the Model andReasoner to delegate calls, including event subscriptions, to the appropriate inte-grated system.Chapter 4. The Ubicomp Integration Framework 1014.5 Model and ReasoningThe Model and Reasoner subsystem manages the current environment model in-cluding all entities, their capabilities and aggregated components. It typically in-cludes some static context values, in particular those that are not supplied by anyadapter or internal component, but may be useful to applications. This includesthe static relationships between locations and their coordinates for example. Weelected to store entities, components, and static entity relationships and context inthe model; dynamic entity relationships and context requests are delegated to anadapter. With many entities and rapidly changing context, we found that it wasnot practical to retrieve or cache current context values in the integrated model forentity discovery. The core of our model is implemented using the Jena semanticweb framework [1]. We integrated the general purpose reasoning engine suppliedwith Jena into the UIF.Upon start up, the current model can be loaded into RAM from a standardrelational database, or from RDF files supplied by an integrator. The RDF containsthe UCM core model, specializations of the model for particular environments orrequired features, and static instance data such as static locations, users, objects,and fixed components. Once the knowledge base is loaded, rules to support theUCM and custom rules supplied by an integrator are then read into the system.Custom rules may be used to automatically aggregate certain fixed componentswith certain entities. For example, a server currently supplies user identity andpresence information for users in the model; context sources for these capabilitiesare automatically associated with CampusUser entity types using the followingrules:# all CampusUsers have presence context[userPresence: (?entity ucm:aggregates pmedia:presenceSource)<-(?entity rdf:type campus:CampusUser)]Chapter 4. The Ubicomp Integration Framework 102# all CampusUsers have position context[userPosition: (?entity ucm:aggregates pmedia:positionSource)<-(?entity rdf:type campus:CampusUser)]Our initial model implementation wrapped a single Jena inference model: adata model wrapped with a reasoning engine and associated rules. Unfortunately,the reasoner supplied with the framework is not thread safe, so that all queries andchanges to the model must be serialized. For small prototype models, we foundperformance to be adequate, but with larger models we needed another approach.While it should be possible to improve performance by reducing the number ofrules and triples in the model to only those required by our application, we wantedto maintain the flexibility of the Jena reasoner and use OWL as much as possible.To address this we created an IntegrationModel implementation that maintainstwo cached query models. One is available for queries at all times, while the otheris updated in the background when a change is made. Once all changes have beenprocessed, the background model is then swapped in and used for queries. Usingthis implementation, both queries and changes are fast, however, changes to themodel are not returned in queries until some time after a change is made.We wrapped all queries to the model using three interfaces: the Integration-Model, ModelEntity and ModelComponent. Wrapping the integration modelin these interfaces allowed us to change not only the integration model as describedpreviously, but also the queries used without changes to other parts of the platform.An IntegrationModel is responsible for model initialization and model composi-tion using methods to add and remove entities and components. It contains meth-ods to find entities by type, or for maximum flexibility, query for entities using aSPARQL [103] clause.Together these interfaces provide the ECL with the knowledge required to dis-Chapter 4. The Ubicomp Integration Framework 103patch method calls to the right adapter and/or associated UCM components. Com-ponents by be handled by an Adapter as described in Section 4.8 or by native UIFcomponents described next.4.6 Component ContainerThe native Component Container subsystem is a simple micro-container for UCMcomponents implemented by an integrator. Such components can provide compos-ite services, or custom context sources that make use of one or more integratedubicomp systems, or services only available to the integration platform.The key classes and interfaces for the Native Component subsystem are shownin Figure 4.5. The ComponentFactory provides methods to instantiate compo-nents by providing the component identifier and the Java class for the component,both from the UCM. (The Java class is the value of a binding UCM Componentproperty.)The ComponentRegistry encapsulates a mapping from UCM componentIdto Component objects for lookup by other parts of the system. Native componentsimplement a Component interface, or one of its derived interfaces: ServiceHan-dler, ContextSource, EventSource, EntityHandler and Environment. Eachof these corresponds to a UCM component type, other than the Environment.The Environment is a special component that will receive addEntity and re-moveEntity method calls from the Facade to handle adding and removing entitiesto the model that are not handled by a supporting system and so must be added orremoved by the UIF itself. As their names imply, ServiceHandler implements amethod to invoke its services, a ContextSource supports context queries by pro-viding an attribute. A ContextSource is also an EventSource that signals eventsto objects that implement EntityEventListener interface. Note that ClientSes-Chapter 4. The Ubicomp Integration Framework 104+getComponent() : Component+registerComponent()+removeComponent()Container::ComponentRegistry+createComponent() : ComponentContainer::ComponentFactory?interface?Container::ContextSource?interface?Container::Component?interface?Container::EventSource?interface?Container::Environment?interface?Container::ServiceHandler?interface?Container::EntityHandler1-components*?instantiate?Figure 4.5: Key classes and interfaces of Component Container subsystem.sion objects in the ECL are also Components managed by the Container. Theyimplement the EntityEventListener interface so they can receive events fromboth Adapter-hosted components and native UIF components in the Container.One composite service we have implemented provides a broadcast messageservice associated with a place that calls individual message services for thoseusers containedIn a place. Another provides the capability to track users' locationssupplied by GPS-equipped PDAs. Other native components may provide customcontext inference services, or integration with components exposed using Web Ser-vices outside the UIF.A native component implements one of the above interfaces, typically by spe-cializing one of several abstract classes supplied with the system such as Abstract-ContextSource and AbstractServiceHandler. The components register them-selves by providing their unique identifiers, their Java binding class and whetherChapter 4. The Ubicomp Integration Framework 105the component should be instantiated on start up or on demand. An example nativecomponent declaration follows:<campus:CampusPositionSource rdf:ID="positionSource"><ucm:binding>ca.ubc.cs.uif.prototype.PositionContextSource</ucm:binding><ucm:onStartup>true</ucm:onStartup><ucm:hasContextType rdf:resource="&ucm;pointLocation"/><ucm:firesEventType rdf:resource="&ucm;contextChangedEvent"/></campus:CampusPositionSource>The positionSource native component implements a Web Service to receiveGPS coordinate updates from PDAs in the field. The UCM id of this native com-ponent is positionSource. Its Java binding is the PositionContextSource class.The onStartup property is true, indicating that it should be instantiated when thesystem starts up. It exposes a pointLocation context type, and a contextChangedE-vent event type.To summarize, the Container subsystem contains UCM components imple-mented within the UIF by an integrator. These components can provide compositeservices or custom context sources for example either making use of an integratedsystem or providing new functionality not anticipated by an integrated system. Likecomponents supplied by an integrated system, Container-hosted components arealso registered with the Model and Reasoner subsystem.4.7 Message Broker: AdapterManagerThe AdapterManager object in the UIF is our message broker responsible formanaging adapters and forwarding method calls using Java Remote Method In-vocation (RMI) [38]. The AdapterManager is also responsible for maintainingadapter leases and tracking event subscriptions for adapters in case an Adaptershuts down. Remote Adapters first register with the AdapterManager, using theChapter 4. The Ubicomp Integration Framework 106adapterStarted() method of AdapterListener shown in Program 4.1. Once anadapter is registered with the system, the AdapterManager dispatches methodcalls destined to Components associated with it. Adapters add and remove entitiesand components from the model depending on the integrated system as describedin the next section.4.8 AdaptersKey to our approach to integration is the use of adapters which sit between the UIFand an underlying ubicomp system. The Adapter interface shown in Program 4.2 isdesigned to encapsulate the functionality of an existing ubicomp system. Adaptersensure the integration framework holds the exposed entities and capabilities of theintegrated system, maintain mappings between components, event subscriptionsand entity identifiers, and marshal method calls to and from the integrated ubicompsystem on demand. Adapters initiate a connection with the UIF by calling theadapterStarted method of the AdapterListener interface shown in Program 4.1.Program 4.1 AdapterListener interface.public interface AdapterListener extends Remote {void adapterStarted( String adapterName, Adapter adapter);void fireEvent(String adapterName, String sourceId,String subscriberId,EntityEvent event);String addEntity(EntityInfo eInfo);void removeEntity(String entityId);String addComponent(ComponentInfo cInfo);void removeComponent(String componentId);}The add/removeComponent and add/removeEntity methods are calledby Adapters to add and remove entities and components to the model as they arediscovered in an integrated system. Aggregation links between entities and com-Chapter 4. The Ubicomp Integration Framework 107ponents may be established by the adapter in the ComponentInfo data structure, orspecified in an integration rule installed in the framework. Adapters signal eventsby calling the AdapterListener fireEvent method.Program 4.2 Adapter interface.public interface Adapter extends Remote {boolean start(boolean reset);void stop();boolean check();ContextValue getContextValue(String componentID, String entityId, String attribute);void setContextValue(String componentID,String entityId, String attribute,ContextValue value);DataObject invoke(String componentId, String entityId, String serviceType,String methodName, DataObject[] inArgs);int[] subscribe(String componentId, String subscriberId,EventSubscription[] eventSubs);public void unsubscribe(String componentId, String subscriberId,EventSubscription[] eventSubs);String[] getRelatedEntities(String componentId, String id, String relationship);void addEntityRelationship(String componentId, String id, String entityId,String relationship);public void addEntity( EntityInfo info);public void removeEntity( String entityId);}Several method calls support direct interaction with the underlying system andcorrespond directly to those in the interaction calls of the Facade. Note that thesemethod calls include a component id used to identify the particular component:EntityHandler, Service, ContextSource or EventSource, in the underlying system.Two Adapter method calls, addEntity and removeEntity are called when anChapter 4. The Ubicomp Integration Framework 108application adds or removes an entity from the model. This can occur when anapplication registers a new user with the model, or when a new place of interest isadded for example. The new entity information is broadcast to all adapters in casethey need to update their native model with this new information.4.8.1 Adapter FrameworkTo facilitate adapter development, we created a lightweight adapter framework.The key objects of this framework are shown in Figure 4.6.BaseAdapterComponentMapComponentRecordComponentMarshallerSubscriptionMap1-subs*1-components*1-component1-marshaller*SubscriptionRecord1-sub1-marshaller*AdapterNativeSystemFigure 4.6: Key classes of the Adapter framework.The adapter framework consists of the BaseAdapter abstract class which han-dles set up of a remote RMI-based adapter, and initial registration with the UIF. AComponentMap contains ComponentRecords indexed by native component idand UCM id. A ComponentRecord includes a ComponentMarshaler which mar-shals data to and from the native system format.Chapter 4. The Ubicomp Integration Framework 109Fixed components such as the iROS Event Heap are added to the model whenthe adapter starts up using the addComponent call. Dynamic components suchas Context Toolkit Widgets are added to the composite model when the adapterreceives an event from the native system. Since some systems do not support suchevents, some adapters will poll for newly discovered components.When an application makes a synchronous entity interaction call, the Adapterlooks up the ComponentRecord based on the UCM component id supplied. Itthen gets the ComponentMarshaler with that record, uses it to marshal the dataand then makes a native system call. The ComponentMarshaler is subclassedto perform the necessary data and protocol marshaling on a per-system, and ifnecessary, a per-component basis.To maintain subscriptions for asynchronous events, an adapter typically usesa SubscriptionMap. This maintains a mapping of UIF subscriberId and compo-nentId to native event subscriptions. When a new subscription is received, thesubscription data is marshaled to the native system subscription, a native sub-scribe call is made and a new SubscriptionRecord is added to the map. Like aComponentRecord, the SubcriptionRecord contains a ComponentMarshalerfor the native event source. When an event is received by the integrated system,the Adapter looks up the corresponding SubscriptionRecord. The associatedComponentMarshaler is then used to marshal the event data structure to a UIFEntityEvent data structure. The AdapterListener fireEvent call is then made tothe UIF to forward to the waiting ClientSession and associated UIF applica-tion. Since the same UIF subscription may correspond to a subscription to mul-tiple components on the same system, the UIF will supply a subscription for eachsubscriptionId-componentId pair; the SubscriptionMap will maintain a recordfor each subscription-component pair.Using the adapter interfaces and framework described here, we implementedChapter 4. The Ubicomp Integration Framework 110a prototype deployment that emulates an campus-scale ubicomp environment byintegrating four existing systems [36, 40, 47, 83] described in the next chapter.4.9 SummaryIn this chapter we presented the Ubicomp Integration Framework, a platform forubicomp systems integration used to evaluate the UCM. We described each sub-system of the UIF including the Facade Web Service, Environment Composi-tion Logic, Model and Reasoning subsystem, Component Container, Broker andAdapter Framework.To summarize, the UIF manages an environment model repository containingan instance of the UCM. The model repository is queried to dispatch method callsto the appropriate adapter or internal components. In addition, the UIF managessubscriptions for internal or integrated event sources for applications of the in-tegrated environment model. For example, to query for context about an entity(referring to the UIF architecture diagram in Figure 4.1) an application will makea Web Service call to the Facade. This will be delegated to the Environment Com-position Logic (ECL) subsystem. The ECL queries the knowledge base hosted bythe Model and Reasoning subsystem for the component that supplies the requestedcontext. If the context request can be satisfied by the Model and Reasoning sub-system directly (e.g., static context) the context is returned directly. If not, theECL examines the component properties to determine whether the query should behandled by an internal UIF component in the Native Component Container, or anintegrated system dispatched by the Message Broker. If it is destined for an inte-grated system, the request is dispatched to the appropriate adapter and marshaledto the system-specific API or protocol. The query response is then returned to theapplication in the reverse direction. Service calls and event subscriptions follow aChapter 4. The Ubicomp Integration Framework 111similar call pattern.In the next chapter we present our experience in creating the composite envi-ronment shown in Figure 5.1 to evaluate the UCM and the UIF supporting system.112Chapter 5Evaluation: An IntegratedCampus EnvironmentTo evaluate the Ubicomp Common Model and our approach to ubicomp systemsintegration we considered three key questions:1. Can our model be used to support applications that make use of multipleunderlying ubicomp environments each with their own different abstractionsand programming models?2. Is our model flexible enough to support all four classes of ubicomp systemsidentified in Chapter 2: Component Compositions, Context Frameworks,Smart Space Systems, and Wide Area Systems.3. While meeting our first two requirements, can our model be implementedsuch that it still offers both adequate performance and is practical for appli-cation development?To answer these questions we describe our experience integrating a set of fourubicomp systems into a composite environment for application development. Theprototype deployment illustrated in Figure 5.1 was created by integrating the EquipComponent Toolkit (ECT) [47] developed at the University of Nottingham, a Com-ponent Composition System, the Context Toolkit (CTK) [36] developed at Geor-gia Tech, a Context Framework, iROS [83] developed at Stanford, a Smart SpaceChapter 5. Evaluation: An Integrated Campus Environment 113System, and the MUSEcap platform [40] developed at the University of BritishColumbia, a Wide Area System. MUSEcap is a system designed for campus scaledeployments similar to Active Campus [49]. In this deployment the UIF acts as anintermediary between all four ubicomp systems as shown.Campus EnvironmentLab Environment Meeting RoomUIFMUSEcapAdapterPlaceMediaServerContext ToolkitAdapterTemperature WidgetECT Adapter iROS AdapterEventHeapServerMultiBrowserEnterpriseJavaBeansSoundLevelWidgetDiscovererIn/Out WidgetDataspaceWebCamSensorsLabMonitor ApplicationPlaceMediaApplicationEnvironmentBrowserMultiBrowserDataWeb Services FacadeIntegratedModelRMI Adapter BrokerFigure 5.1: Composite campus environment deployment.5.1 ApplicationsTo exercise our composite environment we developed three prototype applications:PlaceMedia, the Lab Monitor, and the Environment Browser. Rather than inventingour own unique applications, we aimed to support applications inspired by previouswork, particularly those used with the systems we integrated.Each application was developed for a specific purpose. The PlaceMedia ap-Chapter 5. Evaluation: An Integrated Campus Environment 114plication described in Section 5.1.1 was used primarily for rapid development andtesting of the UCM, UIF and adapter interfaces. The Lab Monitor application inSection 5.1.2 was designed to exercise the capabilities of a composite environmentas a whole, making use of four integrated systems simultaneously. Finally, the En-vironment Browser (Section 5.1.3) was developed primarily as a tool for testingand debugging the integrated environment. Each application is described in moredetail here.5.1.1 PlaceMediaPlaceMedia was created for rapid development of the UIF and adapter subsystems.To accomplish this, the dependency between the PlaceMedia application and theMUSEcap platform was broken by inserting the UIF system between the applica-tion and the MUSEcap platform. This way we ensured that the application APIswere adequate for at least one application, and the Adapter API was sufficient tointegrate the MUSEcap system.PlaceMedia, modelled after the Active Campus Explorer application [50], al-lows users to see their own location and the location of their friends on a campusmap as they roam around. They can communicate with each other, and see thelocations of interesting landmarks nearby. PlaceMedia users can see their own lo-cation and the location and on line status (presence) of friends using a map-basedinterface. They can also place media markers containing text, images or video clipsat places of interest and subscribe to alerts that let them know when they are nearanother user or media marker. Users communicate with each other using a built-ininstant messaging facility.Location and presence is updated periodically by an agent application runningon PDAs or Tablet PCs. Location is derived using wifi signal strength [69] orChapter 5. Evaluation: An Integrated Campus Environment 115 Figure 5.2: PlaceMedia user interface.provided directly by small Bluetooth GPS units. The web based application userinterface was implemented using the Google Web Toolkit1 and the Google MapsAPI2 to display locations and media markers. Since the PlaceMedia applicationwas originally designed to use the MUSEcap platform directly using an EnterpriseJavaBeans [75] API, we created an UIF adapter for MUSEcap, and modified thePlaceMedia application to use the UIF Facade web services API. This allowedus to insert the UIF and composite model between the PlaceMedia applicationand MUSEcap platform for development and testing of both interfaces. The user1see http://code.google.com/webtoolkit/2see http://code.google.com/apis/maps/Chapter 5. Evaluation: An Integrated Campus Environment 116interface for the tablet PC version of the application is shown in Figure Lab MonitorThe ?Lab Monitor? application was designed to exercise the capabilities of a com-posite environment as a whole, making use of four integrated systems simultane-ously. This required integration with three additional existing ubicomp systems asdescribed in Section 5.3.The features of Lab Monitor were inspired by the Context Toolkit In/Out Boxand the iRoom Multibrowse [65] applications. The Lab Monitor user interface,shown in Figure 5.3, performs two primary functions. First, it monitors our labby providing information about who is present (left pane), the current sound andlighting levels (bottom pane), and allows users to take a photo of the lab as shownin Figure 5.3(a). This allows remote users to see who is present and whether thereis a meeting going on, for example. Secondly, it allows users to share web pageswith others by broadcasting URLs to other Lab Monitor applications as shown inFigure 5.3(b). The LabMontitor application makes use of features from each ofthe four underlying systems. User identity is supplied by the UBC MUSEcap sys-tem. User presence in the room is supplied by an In/Out widget from the ContextToolkit (CTK) using an RFID sensor. Sound and light levels are also supplied byCTK widgets and appropriate sensors. To share web pages with other users, theUIF broadcasts URLs using the iROS Event Heap. A web camera is controlled byan integrated Equip Component Toolkit component. This integration was accom-plished using four adapter implementations described in Section 5.3.Chapter 5. Evaluation: An Integrated Campus Environment 117ECT camera controlMUSEcap and Context Toolkit user and place context(a) Lab Monitor Photo tabiROS events for multibrowsing(b) Lab Monitor Multibrowse tabFigure 5.3: Lab Monitor application user interface. The indicated systemsprovide different capabilities to the application.Chapter 5. Evaluation: An Integrated Campus Environment 118Figure 5.4: Environment Browser user interface.5.1.3 Environment BrowserTo interactively explore the contents and capabilities of the integrated environmentmodel, the Environment Browser is supplied with the UIF system. While this ap-plication was designed more as an administrative and development tool, it alsoserves as a demonstration of how an application can browse and interact with anenvironment, independent of the types of hosted entities and associated capabili-ties.Chapter 5. Evaluation: An Integrated Campus Environment 119The Environment Browser is a web application where each page correspondsto an entity in the model (person, place or thing). The page contains links cor-responding to the current context, entity relationships, and events associated withthat entity. Users can navigate to other entities following entity relationship links,retrieve current context values, call services and subscribe to events associated withentities. The user interface of the Environment Explorer is shown in Figure System IntegrationWe tested our applications using a composite Campus environment composed offour integrated systems [36, 40, 47, 63]. In this section we describe this compositemodel and the design and implementation of each adapter.5.2.1 Campus Composite Environment ModelThe composite model in our prototype integration deployment is summarized inFigure 5.5. It consists of a root Environment entity which hosts a static Campusentity. By doing this, the model anticipates incorporating other places outside thecampus. The Campus contains Users and PlaceMarker entities dynamically sup-plied by the MUSEcap system. The campus also contains a static MAGIC Labentity, and a Meeting Room place entity as shown. Users may be friends with eachother and may be contained in either the Campus or the MAGIC Lab.Capabilities such as context, services and events are associated with usersand place markers. User capabilities are supplied by MUSEcap and the ContextToolkit. The MAGIC Lab contexts sound level and temperature are supplied bythe Context Toolkit; the photo service is supplied by an ECT component. MeetingRoom capabilities for sending URLs to the browser services and subscribing toand sending interaction events are supplied by the iROS system. Note that theseChapter 5. Evaluation: An Integrated Campus Environment 120FriendRelationshipEnvironmentCampusUsersMAGIC LabMeetingRoomContains/Contained InContained InContained InLocationIdentificationContained In Magic LabDevicesBrowserServiceInteractionEvent Serviceexposes exposesexposes exposesContained InexposesSoundLevelTemperaturePhotoService InteractionEventexposesexposesContained In exposes exposesexposesChat ServiceexposeshostsFriendsFigure 5.5: Composite environment model including entities and key capa-bilities.capabilities will only appear when the underlying adapter, system and componentsare available.Each adapter design and implementation is described next.5.3 Adapter Design and ImplementationFor each adapter in this section, we provide a table that maps the UCM core ab-stractions (environment, entities, context, services, event, content) to facilities inthe integrated system. We then highlight key implementation decisions that in-formed our general adapter design process and integration lessons learned. Fol-lowing a description of our adapters, we summarize the adapter design process,outlining the steps required by an integrator to integrate a ubicomp system usingthe UCM with the UIF.Chapter 5. Evaluation: An Integrated Campus Environment 1215.3.1 Equip Component Toolkit AdapterThe Equip Component Toolkit is a platform which aims to support the rapid de-velopment of ubiquitous computing experiences. ECT components (typically im-plemented using JavaBeans [96]) are used to interact with devices, or may be soft-ware only components for processing. Components define named properties usedto control their operation or read their current state. For example, the CameraComponent has an triggerImageCapture property and an imageLocation property.When the value of the trigger property is changed, the URL for an image capturedby the camera can be retrieved using the imageLocation.Components are managed within local component containers which may becoordinated in a distributed dataspace installation [46, 61]. Components may becombined by linking shared properties with similar types to one another so thatproperty changes are propagated between the two installations [47]. A key advan-tage of using the ECT dataspace and property links as a coordination mechanismis that components can be combined very easily without knowledge of a specifictoolkit API. Table 5.1 summarizes how the UCM core abstractions map to a typicalECT deployment.Design and ImplementationTo make use of components in an ECT installation, we created an Adapter compo-nent that interacts with the dataspace as a whole, monitoring and interacting withany component, property and links in the space. The Adapter is notified when newcomponents are discovered or removed and it interacts with ECT components onbehalf of UIF applications.In our prototype adapter integrated a web cam ECT component; other compo-nents can be integrated in a similar manner. When a component of the type CameraChapter 5. Evaluation: An Integrated Campus Environment 122Table 5.1: ECT Adapter UCM AbstractionsAbstraction ImplementationEnvironmentModelDataspace containing components that publish properties, named,typed values. These component properties may be linked to othercomponent properties with the same type.Entities Not supported directly.EntityRelationshipsNot supported directly.Context Properties of components can be considered or used as contextvalues.Services Services are not supported directly, but a component's propertyvalues can be set, and then a trigger property is changed.Events Property change events may be monitored.Data/ Content Not supported directly, implicit in some components properties. Forexample, the URL of the last photo taken by the web camera com-ponent is in a property.is discovered, a UCM Service description is added to the model. This service in-cludes takePhoto and getLastPhoto methods. When the takePhoto method iscalled in the UIF service, this changes the value of the triggerImageCapture prop-erty of the ECT camera component. This causes a photo to be taken. The photoURL is saved in the Camera imageLocation property. When the getLastPhotomethod is called this value is read from the component property and returned tothe UIF application.5.3.2 Context Toolkit AdapterThe Context Toolkit (CTK) is a well known system that introduced the notion ofreusable Context Widgets that supply applications with a wide variety of context[36]. Widgets encapsulate sources of context such as sensors or context interpretersand related services. A typical CTK deployment can be mapped to core UCMabstractions as summarized in Table 5.2.Chapter 5. Evaluation: An Integrated Campus Environment 123Table 5.2: Context Toolkit Adapter UCM AbstractionsAbstraction ImplementationEnvironmentModelA Discoverer component tracks CTK components available to ap-plications. The resources available to an application may come andgo as components in the environment are started and stopped.Entities Entities are often handled explicitly by context aggregators that ag-gregate context about a certain entity such as a user, place or ac-tivity. Attributes of a widget may specify the static locations or userthat the context or services potentially apply to. Similarly dynamiccontext values can represent entities such as users and locations.EntityRelationshipsEntity relationships are not supported as a first class abstraction inthe CTK, however, certain widgets can associate entities such asplaces and users. For example the in/out widget associates userswith the place that the widget serves.Context Context supported by the toolkit include simple context values forthe ambient sound level, lighting and temperature level in a room.Services Context widgets can also support associated services. For exam-ple a light widget could also support lighting control.Events A common event in the toolkit is support for context changes. Ap-plications can subscribe to these events, specifying the context at-tributes they wish to monitor.Data/ Content Content is often treated as context in the context toolkit. For ex-ample, Questions, and presentation content in the Conference As-sistant are context associated with a Presentation room or activity[37].Design and ImplementationWe focused on integrating a deployment of the CTK by accessing its Discovererand certain context widgets directly. Since the source code available on Source-forge3 did not support our sensor hardware4, or was unavailable, we re-implementedseveral widgets described in Context Toolkit publications ourselves [34, 36]. Specif-ically we implemented a light sensing, ambient sound level, and temperature sens-ing widget and a `presence' widget [89] that sends events when an RFID tag ispassed over a reader. An in/out widget was also implemented making use of the3http://contexttoolkit.sourceforge.net/4http://www.phidgets.com/Chapter 5. Evaluation: An Integrated Campus Environment 124presence widget and an Interpreter component to track the state of certain userswhen they enter or leave a room by waving the RFID over the reader. SinceCTK components may come and go at any time, the CTK adapter subscribes tothe Discoverer component, indicating the components that it can integrate into thecomposite environment. When a supported component is discovered, its RDF de-scription is injected into the composite model by the adapter, and a mapping fromthe UCM component id to a CTK identifier is maintained.For simple widgets such as sound, light and temperature sensors, the compo-nent mapping from a Context Widget to a UCM ContextSource, and associateddata marshaling in the adapter was straightforward. Mapping the capabilities ofthe in/out widget presents some unique challenges, however, since it supports thecontainment relationship between a room and a few users equipped with RFIDtags. Since the in/out adapter only applies to certain users in our composite model(i.e., only those with RFID tags), we had the CTK adapter supply the entities ag-gregated by this component explicitly when the component description is added tothe system. To make it easy for applications to find users that can be containedin a specific room, we marked these users as pmedia:MeetingUsers in the model.The RDF roomLocationSource component describing the in/out widget is shownin Program 5.3.2 including descriptions of the users of type pmedia:MeetingUserthat have RFID tags.Our in/out widget supports queries for the relationship user contained-in place,but not the inverse relationship place contains users. Because of this, the corre-sponding UCM component is aggregated by user entities, but not place entities.The in/out widget can signal events when a user enters or leaves the room.The event data supplied when this occurs contains the user identifier and in/outstate. Since the event is related to the place not an individual user, this event isbest aggregated by the room it serves. As a result we used two UCM componentChapter 5. Evaluation: An Integrated Campus Environment 125Program 5.1 Component description for the roomLocationSource Context Source.<ucm:ContextSource rdf:ID=?roomLocationSource?><ucm:adapter>contextToolkit</ucm:adapter><ucm:hasContextType rdf:resource=?ucm;containedInType? /><ucm:aggregator rdf:resource=?&pmedia;mike?/><ucm:aggregator rdf:resource=?&pmedia;rodger?/><ucm:aggregator rdf:resource=?&pmedia;nicole?/>. . .</ucm:ContextSource><rdf:Description rdf:about=?&pmedia;mike?><rdf:type rdf:resource=?&meeting;MeetingUser?/></rdf:Description><rdf:Description rdf:about=?&pmedia;rodger?><rdf:type rdf:resource=?&meeting;MeetingUser?/></rdf:Description><rdf:Description rdf:about=?&pmedia;nicole?><rdf:type rdf:resource=?&meeting;MeetingUser?/></rdf:Description>descriptions for the CTK in/out widget, a context source and event source for asingle CTK component. The first exposed the contained-in relationship, handlingrelationship queries for user entities; the second exposed a relationship-changedevent handling subscriptions to these events for the place. There need not be a oneto one correspondence between UCM component descriptions and the componentsof an integrated system.CTK widgets support the same event type for almost all widgets: the UPDATEevent signalled when context changes. When an entity in the model aggregatescontext from several CTK widgets, a single UIF subscription for context changesmust therefore be propagated to several CTK components. Consequently, there isnot necessarily a one to one correspondence between UIF subscriptions and CTKsubscriptions.Chapter 5. Evaluation: An Integrated Campus Environment 1265.3.3 iROS AdapterThe iROS meta-operating system was constructed to support experiments aroundinteraction with large screen displays in interactive workspaces [63]. Several pro-totype versions of the installation called the iRoom were set up. From this experi-ence researchers at Stanford identified some of the most important characteristicsof an interactive workspace infrastructure [83]. A key subsystem underlying manyof the other iROS facilities is the Event Heap [64]. This provides a coordinationmechanism that decouples applications and services from one another, allowingthe system as a whole to be more stable. On top of the Event Heap, several othergeneral purpose facilities are available. The ICrafter service infrastructure pro-vides service discovery and interaction layered over the Event Heap, and the DataHeap provides a facility for storage of files associated with a place, independentof how they are stored. Arbitrary meta data associated with content in the DataHeap can be used by applications directly or by the Data Heap itself to transformdata from one format to another. In Table 5.3 we outline the mapping from the UIFabstractions to facilities in iROS.Design and ImplementationFor this integration task we focused on integrating a representative ICrafter service,and support for the Event Heap coordination facility to ensure the UCM providesadequate coverage of these capabilities. One application and ICrafter service sup-plied with the iROS installation is the Multibrowse application and Butler service.The Butler is used to control applications like Internet Explorer on a PC. Multi-browse allows Internet Explorer users in the workspace to send links to other PCsin the workspace to share URLs. We described the ICrafter Butler service usinga UCM URLService service interface that implements a sendURL method. WithChapter 5. Evaluation: An Integrated Campus Environment 127Table 5.3: UCM Abstractions Mapped to the iROS SystemAbstraction ImplementationEnvironmentModelThe ICrafter subsystem models the environment as a set of re-sources such as application services, components and associatedstate. The Data Heap contains relevant content and associatedmeta data. The Event Heap is used as a communications mecha-nism.Entities Entities information, such as devices, users, groups, are found inEvent Heap event fields, which may be associated with ICrafter ser-vices and state.EntityRelationshipsNot supported directly, but group membership can be inferred frominformation in Event fields (group, user). ICrafter service descrip-tions can include location of services.Context Variables in the state space. For example, a light switch stateServices ICrafter servicesEvents Events are a first class abstraction in the iROS system. Arbitraryevents can be produced or consumed by an iROS client applicationor subsystem.Data/Content The data heap provides storage for content.this service integrated, UIF applications, like iROS Multibrowse, can open Inter-net Explorer to display a URL on any iROS equipped PC. Initially it was unclearwhether this service should be aggregated by a user entity, or a device entity inthe room. Since the device name is included in the service description, and thereis no way of knowing from iROS who the current user of a PC is, we decided tointroduce a laptop device entity into the environment when a Butler/URLServiceis added to the model.To explore the suitability of the UCM in supporting the core capabilities ofthe Event Heap, we needed a strategy to both receive and send events. To ac-complish this, we described the Event Heap as a single UCM component withtwo capabilities. The first is a meeting:InteractionEventService that allows ap-plications to inject arbitrary events into the Event Heap. The second is the meet-ing:InteractionEventType with the event name meeting:interactionEvent to supportsubscription to arbitrary event heap events. Our current implementation is limitedChapter 5. Evaluation: An Integrated Campus Environment 128to subscribing to events by the type field only, but could be extended to supporttemplates as in the Event Heap API. These capabilities are exposed by the meetingroom when the component corresponding to the iROS adapter starts up. With thiscapability we were able to support the broadcasting and receiving of URLs to shareweb pages in our Lab Monitor application through the Event Heap like other iROSapplications.5.3.4 MUSEcap AdapterThe MUSEcap system was developed at UBC to facilitate the development ofcampus-scale ubiquitous computing applications. Like the PlaceMedia applicationdescribed previously, MUSEcap was also used for rapid UCM and UIF develop-ment, in this case, for the adapter interfaces outlined in Section 4.8. MUSEcapinterfaces are exposed as a type of Enterprise JavaBean called a Session Bean.Session Beans are a type of server-side component used in Java-based transactionmonitors typically used to implement application logic. As in previous systemadapters, we first mapped the core UCM abstractions to a typical MUSEcap de-ployment as summarized in Table 5.4.Design and ImplementationIn integrating MUSEcap, we aimed to leverage its facilities to manage users andtheir context between indoor campus locations. Another unique facility offered byMUSEcap was its ability to add (register) and remove entities such as people andplaces called Place Markers to an environment model and fire events when usersare near places of interest or other users.To integrate these capabilities, we created entity types and capability descrip-tions for the context, event types and service interfaces exposed by MUSEcap APIs.Chapter 5. Evaluation: An Integrated Campus Environment 129Table 5.4: UCM Abstractions Mapped to the MUSEcap SystemAbstraction ImplementationEnvironmentModelThe MUSEcap environment model is implemented using adatabase. This database is wrapped by several service interfaces(Session Beans) to access information about users and markers,their relationships and context.Entities Entities supported include users and media markers, or placesmarked with a latitude and longitude. User entities can be addedby the application when new users register, and marker entities canbe added by users.EntityRelationshipsUsers are related to each other using a `Roster' in the databaseindicating that the first user in the table is a friend with the sec-ond. Users may also `own' media markers, indicating that the usercreated a marker for others to see.Context Context supported includes user location updated by agent appli-cations running on PDAs or Tablet PCs. Context also includesuser identity, and presence information such as `on line', ` ff line'or `away'. Marker context includes its location, and identity. InPlaceMedia, content such as text, or an image or video can beassociated with a marker. We also consider this marker context.Services Users in the system can send messages to each other. We con-sider this to be a service associated with those users.Events The system can alert applications when users are within a certainrange of each other, or when a user is in range of a marker. Eventsubscriptions specify the two users, or the user and marker and therange. Events are signaled only once when they are in range.Data/ Content Content such as text, images or video can be associated with amarker. We consider marker content as a form of context.Since all components of MUSEcap are available as long as the server is running,static component information is provided in the configuration files loaded by theUIF on start up. Several rules were supplied to associate MUSEcap components toPlace Marker and User entity types. For example, one rule specifies that if an en-tity is a pmedia:CampusUser, it aggregates the PositionSource component. Sincethe PostionSource exposes a location ContextType, all pmedia:CampusUsers alsoexpose the ability to retrieve their location.When the UIF calls the adapter start method, the MUSEcap adapter updatesChapter 5. Evaluation: An Integrated Campus Environment 130the UIF with the entities (users and markers) and their static context values, cre-ating unique UCM ids for each entity. A mapping from UCM entity identifiers toMUSEcap identifiers is maintained by the adapter using a database. When newusers or markers are added, the UIF model is updated, and new mappings are cre-ated. To interact with the system, the UIF supplies the UCM entity id and compo-nent id. In the adapter, the component id is used to determine the method to call inthe MUSEcap API.Unlike other integrated systems, MUSEcap supports the ability to add or re-move new users and places to the composite model. To make use of this feature,UIF applications such as PlaceMedia will call addEntity or removeEntity us-ing the Facade Web Services interface. Unlike other methods that are targeted tospecific systems, these method calls are then relayed to all Adapters in case theyneed to add/remove these entities to/from their native environment model. Whenthe MUSEcap adapter is called, the UIF entity data structure is transformed toMUSEcap data, and the appropriate calls are made to the MUSEcap API.Finally, since the MUSEcap platform assumes applications periodically pollfor events, the MUSEcap adapter, taking on the role of an application on behalf ofall UIF applications polls for near events once a subscription is received from anyUIF application.5.3.5 Adapter Implementation SummaryTable 5.5 summarizes the adapter functionality we implemented as described pre-viously, categorized by the UCM abstractions.Clearly we did not attempt to map all of the available functionality of the cho-sen platforms. Rather, our efforts focused on exercising our UCM abstractionsto gain a better understanding of the integration development process, abstractionChapter 5. Evaluation: An Integrated Campus Environment 131Table 5.5: Adapter Implementations by UCM AbstractionSystem/AbstractionContextToolkitEquipComponentToolkitiROS MUSEcapEnvironmentModelDiscoverer Equip Datas-paceICrafter subsystem, andEventHeapSessionBeaninterface todatabaseEntities Static loca-tions, usersImplied place(lab) wherecomponentsare locatedHost device inICrafter servicedescriptionPlace markers,usersEntityRelation-shipsInOutWidgetrelates placesto users.Not supported Host devicecontained-inthe meetingroomUser friends,place markerownershipContext User location,user presence,room sound,light level,temperatureComponentproperties (notimplemented)iROS StateAPI (not imple-mented)User location,user identity,presence,place markerlocationServices Context WidgetServices (notimplemented)sCamera Ser-viceBrowser ser-vice, inter-action eventserviceChat serviceEvents Relationshipchanged, con-text changedPropertychanges (notimplemented)InteractioneventUser or placemarker NeareventData/Content(Not sup-ported)Get photo ser-vice methodDataHeap (Notimplemented)Place markercontentmappings and trade offs such as adapter complexity vs performance, which wereport on in Section Adapter Design ProcessFrom our application development and integration experience we have derived adesign process for integrating ubicomp systems using the UCM into a single com-posite model. This process consists of six steps as follows.Chapter 5. Evaluation: An Integrated Campus Environment 1321. Determine the application-environment interaction points. Interactionpoints for integration may be an API, protocol, message format, data store, orother abstraction hosted by distributed components or central servers. Whilelocating these interaction points seems like a straightforward step, in somecases, the integrated system's resources may not be designed for easy exter-nal application integration. For example, in ECT or iROS the application isassumed to be a component or a composition of components in the systemitself. In this case, it may be possible to access integrated components in-directly using the coordinating system such as the ECT data space or iROSEvent Heap.2. Decide on the environment capabilities to expose to outside applications.Considerations in this step of course begin with the capabilities available inthe ubicomp system deployment to integrate. Capabilities correspond to thesensors, actuators, software services, and context sources available. To avoidunnecessary integration work, an integrator should consider the functionalityrequired by applications of a composite environment where interoperabilityis most important. Generally, only a subset of the system's capabilities needsto be exposed to applications using the UCM.3. ?Find? the missing or implicit entities in the model and associate ca-pabilities with these entities. In this step, we make any implicit entities,people, places, and things explicit in the composite model. In some cases,entities are already explicit in a system. For example, the MUSEcap inter-faces expose user and place marker entities directly. In other cases, enti-ties are only implied. For example, since the camera ECT component itselfprovides no information about the physical entities it is associated with anintegrator may introduce a camera device entity to integrate an ECT cameraChapter 5. Evaluation: An Integrated Campus Environment 133component. This is necessary since the ECT camera software componentitself provides no information about the physical entity (camera or place)it is associated with. Once we've made entities explicit in t he model, wemust associate the integrated systems' capabilities with these entities. TheECT camera service is associated with the camera device; an instance of theiROS Multibrowse shared browser service is associated with a laptop device.Similarly, the Event Heap and a temperature Context Toolkit Widget can beassociated with place entities.4. Encapsulate interaction points of the integrated system in UCM com-ponent abstractions. In some cases, there may be an obvious mappingbetween a UCM component and an integrated system interaction point. Forexample, a CTK widget maps naturally to a UCM context source; similarly,an ICrafter service maps to a UCM service component. In other cases, itmay be beneficial to create a UCM component abstraction where none ex-ists. For example, the Event Heap is considered to be a central coordinationmechanism. To allow applications to inject arbitrary events into the EventHeap, it is described as a component with ServiceInterface and EventTypecapabilities. The service interface provides a method to inject events, theevent type allows outside applications to subscribe to interaction events.5. Create rules or explicit aggregation relationships. To associate compo-nents and their implemented capabilities to adapters, aggregation relation-ships can be added to the model directly when components are discovered,or can be inferred by rules that link entities to components based on type orstatic context stored in the model. An integrator can use either technique.6. Implement the Adapter. The last step is to implement the adapter. In ourChapter 5. Evaluation: An Integrated Campus Environment 134prototype work, we attempted to leverage code from a previously developedadapter in new ones. Over time we recognized that common facilities of anadapter emerged that could be used in an adapter framework as discussed inSection EvaluationIn this section, we address the three questions posed at the beginning of this chapter.First, we comment on our experience in using the UIF to build applications that usemultiple ubicomp systems at the same time. We then discuss adapter complexityto get a handle on the flexibility of our model in supporting the four systems weintegrated, each from a different category of ubicomp system as outlined in Chapter2. We then measure the performance of the system as a whole, to understand thefeasibility of our approach. Finally we make some observations on the use of theUIF as a stand alone system for application development.5.4.1 Application DevelopmentOur experience in using a single API to interact with multiple systems has severaladvantages. Developers need only learn and use one set of abstractions, and onlyone API instead of four or more. This should reduce the learning curve and in-crease the portability of applications. However, these benefits come at a cost: theperformance overhead associated with the use of meta-middleware like the UIFand the development of flexible adapters to maintain the integrated model and mar-shal method calls to and from the integrated systems. In a typical deployment, weexpect that UCM application developers will be largely isolated from the cost ofimplementing adapters since they can be created independently.Chapter 5. Evaluation: An Integrated Campus Environment 1355.4.2 Adapter ComplexityTo evaluate how well our UCM abstractions capture those of an underlying sys-tem we considered the complexity of adapter development. We found that theprocess of developing became easier with more experience and as previous imple-mentations were refactored for greater reuse. We estimate that the time requiredto integrate basic functionality (less than 6 components) of a Java-based systemwas about 2 weeks. This development time depends on the programming modeland API, the documentation available, and the capabilities to be integrated. Ourfirst adapter for MUSEcap was created without any shared code and is about 1200lines of code. The CTK, iROS and ECT adapters share about 400 lines of code,and added about 850, 1050 and 550 lines of additional code respectively. Overallwe found that the UCM abstractions provided adequate coverage of the underlyingsystems' capabilities: adapters were straightforward to develop. In future workwe intend to gather more evidence to support both conclusions with a wider studyinvolving additional systems and integrators as the platform is made available toother research groups.5.4.3 PerformanceNext, we considered the performance and the overhead of the integration frame-work. Applications such as PlaceMedia and the LabMonitor will poll the UIF fornew context values, or to retrieve events using the web services interface. Theythen call services, send events or set context based on events received or user in-put. To gain insight on the system's responsiveness to appli cation requests, wemeasured the average time taken to get context supplied by the Context Toolkit,to call a service supplied by ECT or send an iROS event at different (aggregate)request frequencies. To do this we created simple simulated applications that pollChapter 5. Evaluation: An Integrated Campus Environment 136once per second, then varied the number of these polling applications between 5and 80. We then measured the average latency of the synchronous web servicecalls made through the UIF to three integrated systems, the Context Toolkit, ECTand iROS. The results are summarized in Figure 5.6.020040060080010001200140016000 20 40 60 80Number of Active Polling ApplicationsLatencyCTKECTiROSFigure 5.6: Average latency (ms) vs. number of active polling applications(once per second).In our deployment we hosted iROS, ECT and the CTK on a single 2.13 GHzPentium Core Duo system with 1 GB RAM, the MUSEcap platform and the UIF ina second 3.4 GHz Pentium D with 2 GB RAM. Simulated applications were run ona tablet PC with 1GB of RAM and a 1.5 GHz Pentium M processor; all machineswere on the same LAN. The model consists of 535 data triples; the general purposerule-based reasoner uses 278 rules. These tests represent a best case response time;before each test we restarted the system and did not change the model. The systemwas primed with a light test to cache query results. At higher application loads(60-80), we found that the server response time increases to over one second; ap-plications are making requests faster than the server can respond. Overall we foundthat the system response is less than 100ms for loads of up to 40 or 50 applicationspolling once per second.We then examined the overhead of the UIF system in some detail by instru-Chapter 5. Evaluation: An Integrated Campus Environment 137Table 5.6: Components of UIF overhead for a call to an ECT componentthrough the UIF framework. These average values are based on 3000samples taken at about 20 per second.Component Average time (ms) Overall DistributionWeb to Logic Tier 1.096982 3.39%ECL subsystem 0.491013 1.52%Model Query 0.955580 2.95%RMI Broker 2.576806 7.97%Native ECT call 0.010512 0.03%Internal time taken 5.130892 15.86%Web Servicesa 27.214260 84.14%Total Latency 32.345150 100.00%acalculated by subtracting the measured average internaltime from the latency measured by the applicationmenting key subsystems in the framework and measuring the average time takenfor an application to call an ECT service through the UIF. As Table 5.6 indicates,we found that the largest component of overhead was related to the use of the webservices middleware and network latency taking more than 84% of the averagetime taken. Internally our system contributed just over 5 ms to the average timetaken to execute a call; most of this time was used by the RMI adapter request andadapter marshaling.Finally we considered the responsiveness of the UIF while undergoing changesto the model managed by the Jena general purpose rule-based reasoning engine[1]. The composite model changes when applications add new users to the model,or when components are added or removed by an adapter, for example. In thisexperiment, summarized in Figure 5.7, one application adds then removes a placeentity to and from the model every 10 seconds. We measured the latency of agetContext made every 2 seconds call from 10 other applications. The latency ofthe first few calls after a model change increases to more than 1 second then fallsChapter 5. Evaluation: An Integrated Campus Environment 138back to under 100ms as shown. After model changes, queries to the model becomethe largest component of overhead.Latency (ms)020040060080010001200140016000 20 40 60 80 100 120 140Time (s)Latency (ms)Figure 5.7: Model changes trigger forward reasoning, which causes contextrequests to wait for more than a second until the reasoner has completedforward reasoning and the write lock is released.This raised some concerns about the overall scalability of our approach, and inparticular the use of an integrated general purpose reasoning engine in our system.To explore how the query and forward reasoning time varies with the model size weconducted two experiments. We first measured the average query time of a staticmodel with various model sizes. For this experiment, we added user entities toour model, then measured the average time required to get the context source andassociated adapter name associated with a specified entity and context attribute.Our results are summarized in Table 5.7. Overall, we found that the average querytime for a static model did not change significantly as the model size increased.Figure 5.7 showed that subsequent queries are delayed until the model is fin-ished updating. This raised some performance concerns. As the size of the modelincreases, does this delay increase? To answer this question we measured the timetaken to complete a request after changes as the model size increases. Our resultsare summarized in Figure 5.8. The top line indicates the time taken to complete aChapter 5. Evaluation: An Integrated Campus Environment 139Table 5.7: Query Time as (Static) Model Size IncreasesUsers Model Size Time (ms)10 580 0.51650 1020 0.500100 1570 0.516200 2670 0.547300 3770 0.750400 4870 0.578500 5970 0.781600 7070 0.609change to the model, while the bottom line is the time taken to complete a queryonce an update to the model is complete. Changing the model can take several sec-onds, and varies linearly with the size of the model, whereas the query time, oncea change is complete, is very fast and relatively invariant as the number of triplesincreases.Since we expect model changes to occur when new components and entitiesare added and removed, and in some cases when context is added to the model forreasoning, this will add significant time to application queries that must wait forchanges to complete. To address this, we decided to use a ?double buffer? schemeto maintain two models in the UIF. One model containing all raw and deduceddata is for fast queries (called the query model), while the other is used to collectchanges to the model (called the change model). When a change is made to thechange model, the system starts reasoning in a background thread by queryingthe change model for all deduced facts. Once this query is complete, a new querymodel containing the raw data and deduced facts from the change model is created.At an appropriate time, this new query model containing new data is swapped inreplacing the previous query model.Using this approach both queries and changes to the model are fast, however,Chapter 5. Evaluation: An Integrated Campus Environment 140changes to the model will not be reflected in subsequent queries until after a newquery model is generated. With large models this can take several seconds as il-lustrated in Figure 5.8. We found this acceptable for our deployments, but aim toexplore other ways to optimize our model implementation in future work.0100020003000400050006000700080000 1000 2000 3000 4000 5000 6000 7000Number of TriplesChange Time (ms)Figure 5.8: Time required to update a model after a change.Performance ImplicationsOn one hand, we found that the internal performance of the system was adequate,but the overall performance factoring in the cost of web services middleware, pos-sible wide area network latency, and the use of an ?off the shelf? reasoning enginemay seem discouraging. However, with some additional optimizations these issuescan be readily addressed. We found that with a suitable model caching schemeand the use of background reasoning it was possible to trade off query and modelchange times for freshness of the environment model. By choosing light-weightprotocols, and by providing APIs to batch more than one context or service callat once, the cost of web services calls can be reduced. Based on our experiencewith web-based UCM/UIF applications, we have found that a single server-basedChapter 5. Evaluation: An Integrated Campus Environment 141application can serve multiple users in a single UIF application, reducing the loadon the integrated model.5.4.4 The UIF as a Stand Alone SystemFor effective integration of a wide variety of systems ranging from ComponentCompositions to Smart Spaces, it was necessary to support abstractions of an un-derlying system, but to compensate for missing abstractions. To this end, someof the missing functionality of an underlying system can be implemented directlyusing the UIF. For example, an integrator can add static entities and relationshipsfound to be useful abstractions but missing from systems such as ECT or onlyimplicitly supported in iROS event fields. ?Native? UCM services can broadcastmessages to users by calling single users messaging services. Our experience hasdemonstrated that a system designed around the core abstractions of the UCMmay not only serve as an integration platform, but could serve as the basis for areference ubicomp system implementation. We aim to explore this possibility incollaboration with other practitioners in the ubicomp systems community.5.5 Lessons LearnedBased on the integration experience described in this chapter, we discuss our find-ings with respect to the use of the core Ubicomp Common Model that we believewill be useful for both ubicomp systems developers and integrators.A comprehensive and flexible environment model aids application resource dis-covery. It is important for an environment model to not only contain components(as in the ECT Dataspace, or the CTK Discoverer) but also entities, relationships,context, and entity capabilities. These abstractions in a model provide a closerChapter 5. Evaluation: An Integrated Campus Environment 142mapping between the ?real world? and the digital world coordinated by the ubi-comp system making it easier to find relevant computing resources.Maintaining consistency between a composite model and integrated systems'is challenging. Keeping a composite environment model in the integration systemthat to some extent mirrors all or parts of the environment model of integratedsystems allowed us to unify the the computing resources of more than one systemin a consistent and unified manner. This benefits the application developer sincethey need not concern themselves with how capabilities are provisioned. Moreoversince certain abstractions in the UCM such as entities and relationships may bemissing or only implicitly supported in an underlying system, this approach allowsus to compensate for missing abstractions in an integrating system.That said, we found that it can be challenging to maintain consistency betweenan underlying system's model and the composite model. In our deployment we de-cided to store all entities, components, static relationships and context in the model,and delegate dynamic relationship and context requests to the underlying system.This limits the ability for applications to discover entities by context and relation-ships. Furthermore, without this information the UIF is unable to infer higherlevel context and new relationships. While an integrator could configure the UIFto subscribe to context changes or poll for context values periodically, this wouldforce the reasoning subsystem to work continuously to infer new relationships andcontext values unnecessarily, raising a scalability and performance concern.To address this we considered delegating discovery requests to the native sys-tem. However, this would not only require a common query language to interpretthese requests, but also a mechanism to translate these queries to environment dis-covery requests in the native system. Similarly, results from native discovery re-quests would need to be collected and interpreted by the integration system, whichwould require knowledge of the integrated model to interpret them correctly. TheseChapter 5. Evaluation: An Integrated Campus Environment 143challenges remain an open issue for future research.An entity abstraction is a natural way to aggregate capabilities: context, ser-vice interfaces, events, but there is not a one to one correspondence between en-tities and components. Based on our experience and others (e.g., [36, 68, 90]) wehave found that it is natural to aggregate capabilities such as service interfaces,context and events types around entities, however we found that there is not a one-to-one relationship between entities and components, the implementations of thesecapabilities. More than one entity will often aggregate a component, inheriting itscapabilities. For example, a single InOut CTK context widget is associated withboth the place entity and the user entities that are tracked. These n-to-n relation-ships can present challenges for managing event subscriptions where a single UCMevent may be supplied by multiple components.Make entity relationships explicit as they are an important subclass of context.The Cooltown system highlighted the use of entity relationships to create web linksbetween related entities allowing users to browse their changing environment [68].We found that it was valuable to make these relationships explicit in our integratedmodel. Entity relationships implicit in iROS event fields or Context Toolkit contextvalues made it easy to find devices in a meeting room or the users in the lab, forexample.Entity type is an important subclass of context. The use of ontologies allowedus to easily classify all entities in the system not only as people, places, and things,but also the types of people (lab users, students), places (media markers, build-ings), and things (laptops, printers). We found that it was natural to aggregatecomponents with certain types of entities. For example, we could aggregate anoutdoor location context source with all students, but only aggregate the indoorpresence widget with lab users.Applications are not only consumers of resources, they also manipulate theChapter 5. Evaluation: An Integrated Campus Environment 144model directly. While most systems manage context derived from sensors in theenvironment, we have found that it is common for applications to not only consumesuch context, but produce it. For effective integration, application-supplied contextmust be propagated to the underlying system for use by native applications. Appli-cations are also a source of events; the Lab Monitor application, like Multibrowse[65], can send user interaction events to other UIF applications and iROS services.We found that some applications will also add and remove entities such as placesof interest, or newly registered users to an integrated model.Most ubicomp systems share a common set of events. While several systemshave highlighted the importance of event abstractions [83, 87], we have also foundthat several systems share certain event types. Context Tookit update events, likeECT component property changes, are signaled when context values change. Whennew components are added or removed from a system, the environment model(e.g., Discovery subsystem, Dataspace) will signal applications in case they relyon their capabilities. So far we have found the following high level event types tobe common between systems: context/relationship changed, entity added/removed,capability changed. Based on our experience, the consistent implementation ofthese canonical events will reduce the need for applications to poll for changesallowing applications to more readily respond to changes in the environment.In general we found that the core UCM abstractions are a superset of the sys-tems' we integrated. This is not surprising since we attempt ed to develop unifiedabstractions based on these systems and others. While we found few abstractionmismatches, we did find it necessary to compensate for missing abstractions suchas entities and entity relationships either in the adapter implementation or the UIFsystem configuration.From this experience we came to realize that there are a range of approaches toenvironment integration: One is to compensate for missing abstractions in under-Chapter 5. Evaluation: An Integrated Campus Environment 145lying system(s) as we did. Another is to provide information about the integratedsystem's capabilities without any compensation for missing abstractions. In theformer case, the integration system can provide information about implied enti-ties, interpret context data to create and maintain missing entity relationships, andsupport composite services. In the latter case, the integration system can simplyprovide a mechanism for accessing the existing capabilities of an underlying sys-tem. An integrator may elect to compensate for some missing abstractions such asstatic entities but not others. In a sense, our Adapter framework provides a mech-anism for exposing system capabilities without (much) compensation for missingabstractions.Since our aim is to support the full range of integration approaches since weintegrate several systems with varying capabilities into a single composite environ-ment, a flexible model for ubicomp environments such as the UCM is required.5.6 SummaryIn this chapter we presented our evaluation of the Ubicomp Common Model. Wefocused our evaluation efforts on three areas:? Application Development. This experience helped us understand whetherour model can be used to support applications that make use of (potentially)several ubicomp environments with varying abstraction levels. We foundthat the model adequately supported application development, and allowedus to use a single API with more than one system. The experience alsohighlighted the cost of integration, in both building adapters, and the designand configuration of a composite environment model when using multiplesystems.Chapter 5. Evaluation: An Integrated Campus Environment 146? Adapter Complexity. To gain an in depth understanding of the flexibilityof our model, we created adapters for four representative systems, each froma different class of ubicomp system as outlined in Chapter 2. Overall wefound that it was possible to create adapters that provided adequate coveragefor each systems's capabilities and that these adapters wer e straightforwardto develop.? Performance. To assess the feasibility of the UIF as an integration plat-form that uses the UCM for environment integration, we measured the per-formance of the system under both steady state and dynamic environmentconditions. In the steady state, we found performance adequate. We thenpresented an approach to address performance in changing models using a?double buffering? scheme to trade off model freshness for fast query times.Based on this evaluation experience we discussed some of the lessons learnedrelated to the use of certain UCM abstractions and implementation challenges thatcan inform the design of future integration systems and ubicomp platforms. In thenext chapter we conclude this thesis and discuss future work.147Chapter 6Conclusions and Future WorkIn this thesis we have presented the analysis and design of a core model for ubiq-uitous computing systems called the Ubicomp Common Model. This model wasdesigned to allow application developers to bridge across a variety of existing ubi-comp platforms. To do this, it must adequately describe ubiquitous computingenvironments in a manner that lends itself to both application portability, special-ization to different environment domains, and adaptation to a variety of systems.The UCM design was based on the comprehensive survey of ubicomp systemspresented in Chapter 2. From this survey we found that the variety of ubicompsystems abstractions are influenced by the scale of ubicomp deployment and thetradeoffs between making coordinated environments easy to program (high levelabstractions) and broad applicability (low level service/component abstractions).We also identified the common abstractions used across systems: an environmentmodel, entities, context, entity relationships, services, events and data or content.In chapter 3 we outlined several requirements for a common model for ubi-comp and the design of the UCM based on the common abstractions identified inour survey. A key challenge addressed by this model is in finding the right balancebetween interoperability and suitability for cross domain access while maintain-ing much of the flexibility of a given underlying ubicomp system. Based on theabstractions identified in Chapter 2 described the UCM design in some detail pre-senting the three related aspects of the model: the Environment State, Meta StateChapter 6. Conclusions and Future Work 148and Implementation.The Environment State consists of entities modeled by the supporting system,the relationships between entities and their current context values. The Environ-ment Meta-State aspect is required to support introspection and associates entitieswith their capabilities: the types and quality of events, services, context and con-tent they support. Finally, the Implementation aspect captures component abstrac-tions aggregated by entities that provide the services, events, context, relationshipsand content in an integrated system. We then outline how the UCM addresses theoutlined requirements, provided an example of how it can be extended to supportsecurity domains and access control, and provided use cases for a executable modelof the UCM used in a supporting system like the Ubicomp Integration Framework(UIF).In chapter four we described the UIF: a meta middleware system used to eval-uate the feasibility of the UCM for both application development and systems in-tegration. We describe the design and implementation of each subsystem in somedetail including a description of the use of a integrated knowledge base and reason-ing subsystem and adapters. The key to our integration approach is to encapsulateintegrated system using an Adapter interface. Adapters provide the UIF with infor-mation about the resources in the integrated system and handle interaction with thesystem initiated by UCM applications, converting UIF protocols and data struc-tures to and from those of the native system.Finally in Chapter 5 we outlined our application and integration experiencedeploying a composite ubicomp environment that integrated four representativeubicomp systems. From this experience we described our adapter design processand comment on the system's suitability for Application development, integration,performance and suitability as a stand alone system for ubicomp development. Wethen outlined some lessons learned related to the use of the UCM in this deploy-Chapter 6. Conclusions and Future Work 149ment.6.1 Lessons LearnedBased on the experience and analysis reported in the previous chapters, we discussour key findings related to the use of the Ubicomp Common Model for ubicompsystems integration.6.1.1 A Common Model for Ubiquitous Computing is Useful andPracticalThere will always be a variety of ubicomp systems that support various levels ofabstraction, and scale. Certain systems will be specialized for different applicationdomains, and continue to track research advances in systems, software engineer-ing and middleware. Despite continuous evolution and the wide variety of systemsand application domains for ubicomp systems, we have shown that it is practicalto derive a common model for both application portability and systems integration.We have also shown how to instantiate this model in a meta-middleware platformfor systems integration by composing environments. While there are clear trade-offs in our approach to interoperability in terms of costs of integration in buildingadapters and configuring a composite environment, performance, and access to theunderlying capabilities of the integrated systems, our investigation has shown thatthese costs are manageable. Clearly our approach of integrating diverse systemsusing the Ubicomp Common Model is feasible, especially considering the benefitsof application portability and interoperability.Chapter 6. Conclusions and Future Work 1506.1.2 Unifying Environment Model is the Key to IntegrationOur work has shown that it is feasible for the Ubicomp Common Model and a sup-porting system to describe and support an environment model that unifies those ofa few representative underlying integrated systems. This can be accomplished byreplicating key resources and relationships such as entities components and aggre-gation relationships as in the UIF. We believe that this approach, i.e. providing aunified model in the integration system, is the key to effective integration for tworeasons. First, because it exposes a unified and consistent view of the environmentfacilitating application development and portability. Second, it allows an integra-tor to compensate for missing abstractions in an integrated system which is criticalwhen attempting to integrate systems that expose lower level abstractions such asservice and component compositions with others that expose explicit environmentmodels.6.1.3 Entity Types and Relationships are Important Subclasses ofContextBased on our analysis of other systems and experience we identified two importantsubclasses of context that have been shown to be valuable for resource discoveryand integration. Entity relationships allow an application to more easily find en-tities and their associated resources. The use of entity types also makes resourcediscovery easier, and enables integration rules to identify entities for the establish-ment of entity-aggregation-component relationships.6.1.4 Systems Share Several Common Event TypesWe found that several systems share certain types of common events. These in-cluded context changed, entity relationship changed, entity added/removed, andChapter 6. Conclusions and Future Work 151capability changed. Based on our experience, the consistent use of these canoni-cal events increases application portability and reduces the need for applications topoll for changes in the environment.6.1.5 Applications are Both Consumers and ProducersFrom our experience we have gained some insight into the dual role of an applica-tion in an integrated ubicomp environment. An application is not only a consumerof computing resources (e.g. finding entities, receiving events, retrieving contextvalues, calling services), but also a producer. In the producer role, the applica-tion itself is a source of events, content, context and service implementations forother applications in the environment. While we supported this role to some ex-tent through interfaces to set context values, relationships, add and remove entities,in future implementations a general purpose web services interface to the Imple-mentation aspect of the UCM may be provided so that UCM applications can alsoregister their resources with an integrated environment.6.1.6 SummaryTo summarize, we have shown that our approach and model is suitable for integrat-ing a range of representative systems. Although not exhaustive, the systems chosenfor composite model integration and application development represent each cat-egory of system as presented in Chapter 2: Component Compositions, ContextFrameworks, Smart Spaces, and Wide Area Systems. Of course while this doesnot mean we can support all systems, it does indicate that our approach is suitablefor a wide range of ubicomp systems to date.Through the careful analysis of a wide range of ubicomp systems, we haveidentified the abstractions shared by these systems, and made use of this taxon-Chapter 6. Conclusions and Future Work 152omy in the design of the Ubicomp Common Model. Our integration and deploy-ment experience has informed the design of the UCM, highlighting the advantagesand challenges of maintaining a composite environment model, important forms ofcontext and events, and the dual role of an application.6.2 Future WorkIn future work we aim to advance the design of the UCM through continued anal-ysis and practical integration experience. We see opportunities for enhancing andformalizing of the Ubicomp Common Model and continued exploration of the ubi-comp systems integration design and implementation space. From our explorationsdescribed in this dissertation we believe that a dual approach based on analysis andpractical experience is the best way forward.6.2.1 Enhancing and Specializing the UCMBased on our integration experience we see opportunities to formalize certain as-pects of the core model, and in particular the common event, context and entitytypes used across systems. We would also like to further explore the developmentof Environment Profiles: specializations of the UCM for certain application andenvironment domains, perhaps consisting of groups of overlapping ontologies forcontext, entity types, services suitable for the home, office, and other places.6.2.2 SecurityAs discussed in Section 3.5, addressing security challenges will be a challenge thatneeds to be addressed for cross domain ubicomp deployments (e.g. [41, 93]). In anintegration platform like the UIF, we must ensure access to computing resourcesare protected either individually or in groups that may not correspond to physicalChapter 6. Conclusions and Future Work 153entities, geographical or network boundaries. Future integration platforms mustsupport a variety of access control mechanisms, from traditional name, passwordand shared keys to more lightweight mechanisms that support more spontaneousinteractions involving the application directly.6.2.3 Improved ScalabilityWe see opportunities to address scalability concerns in a composite (integrated)environment through optimization of the reasoning subsystem. Approaches in-clude the use of faster general purpose reasoners, special purpose reasoners tunedto our knowledge base, and more efficient model representations in the integrationsystems. Furthermore, we believe that it may be possible to federate or cluster inte-gration systems to share the work of providing access to a composite model acrossseveral servers.6.2.4 Improved Application InterfaceWith the development of Web 2.0 applications and the use of dynamic web pagesand Asynchronous Javascript and XML (AJAX) techniques we see the increasinguse of domain specific HTTP and XML protocols rather than SOAP-based webservices. Based on recent experience with other platforms [39] we believe thatsuch protocol for integrated ubicomp environments may be a better fit than WebServices standards in some situations.Our experience also highlighted the cost of cross domain interaction. To makethe most of each web service call we believe it is important to provide interfacesthat lend themselves to batch processing. This may include interfaces to get allof the context associated with an entity, or subscribe to all user entities in a givenplace for example.Chapter 6. Conclusions and Future Work 1546.2.5 Applications as ComponentsFinally, we believe that the environment interface should be extended or compli-mented with an interface that supports the dual role of an application as both aproducer and consumer of computing resources. While the Facade interface doeswell in supporting the consumer role, additional interfaces are required to supportapplications as producers of context, services, content and events.6.3 In ConclusionIn this work we leveraged the considerable experience in developing ubicomp sys-tems to date to find some common ground for application portability and systemsinteroperability in ubicomp through the design of the Ubicomp Common Model.The feasibility of using the core UCM was tested using the Ubicomp Integra-tion Framework to integrate representative systems under a composite environmentmodel. Our hope is that systems designers will continue to ?climb on the shoul-ders of giants? in their quest for ubicomp systems interoperability and portabilityrequired for applications to be truly ubiquitous.155Bibliography[1] Jena, a semantic web framework for Java.http://jena.sourceforge.net/. last checked: 9-June-2008.[2] Universal Description, Discovery and Integration Version 2 OASISStandard. http://http://www.oasis-open.org/specs/index.php#uddiv3.0.2.last checked: 9-June-2008.[3] OZONE - new technologies and services for emerging nomadic societies.http://www.hitech-projects.com/euprojects/ozone/,2004. last checked: 9-June-2008.[4] SWeDE: Semantic Web Development Environment.http://owl-eclipse.projects.semwebcentral.org/,2005. last checked: 11-June-2008.[5] JBoss web services. http://www.jboss.org/jbossws/, 2007. lastchecked: 9-June-2008.[6] Eclipse.org Home Page. http://www.eclipse.org/, 2008. lastchecked: 11-June-2008.[7] JBoss home page. http://www.jboss.com/, 2008. last checked:9-June-2008.[8] MySQL Home Page. http://www.mysql.com/, 2008. last checked:9-June-2008.[9] The Prot?g? ontology editor and knowledge acquisition system.http://protege.stanford.edu, 2008. last checked:11-June-2008.[10] WebServices - Axis. http://ws.apache.org/axis/, 2008. lastchecked: 9-June-2008.Bibliography 156[11] M. Addlesee, R. Curwen, S. Hodges, J. Newman, P. Steggles, A. Ward, andA. Hopper. Implementing a sentient computing system. IEEE Computer,34(8):50?56, 2001.[12] Gustavo Alonso. Web services : concepts, architectures and applications.Data-centric systems and applications. Springer, Berlin ; New York, 2004.[13] Apple, Inc. Networking - Bonjour.http://developer.apple.com/networking/bonjour/,2007. last checked: 9-June-2008.[14] Mark Assad, David Carmichael, Judy Kay, and Bob Kummerfeld.PersonisAD: Distributed, active, scrutable model framework forcontext-aware services. In Pervasive Computing (Pervasive 2007), pages55?72, Toronto, Canada, 2007.[15] Jakob E. Bardram. The Java Context Awareness Framework (JCAF) - aservice infrastructure and programming framework for context-awareapplications. In Pervasive Computing and Communications (PerCom2005), pages 98?115, Munich, Germany, 2005. Springer.[16] Jakob E. Bardram, Thomas R. Hansen, Martin Mogensen, and MadsSoegaard. Experiences from real-world deployment of context-awaretechnologies in a hospital environment. In Ubiquitous Computing(UbiComp 2006), pages 369?386, Orange County, CA, 2006.[17] C. Becker, G. Schiele, H. Gubbles, and K. Rothermel. BASE - amicro-broker-based middleware for pervasive computing. In PervasiveComputing and Communications (PerCom 2003), pages 443?451, FortWorth, USA, 2003.[18] Christian Becker, Marcus Handte, Gregor Schiele, and Kurt Rothermel.PCOM - a component system for pervasive computing. In PervasiveComputing and Communications (PerCom 2004), pages 67?76,Washington, DC, USA, 2004.[19] Gregory Biegel and Vinny Cahill. A framework for developing mobile,context-aware applications. In Pervasive Computing and Communications(PerCom 2004), pages 361?365, 2004.[20] Michael Blackstock, Rodger Lea, and Charles Krasic. Toward a sharedmodel for wide area interoperability of ubiquitous computingenvironments. In System Support for Ubiquitous Computing (Ubisys)Bibliography 157Workshop at Ubiquitous Computing (UbiComp 2006), Newport Beach,CA, 2006.[21] Michael Blackstock, Rodger Lea, and Charles Krasic. Toward wide areainteraction with ubiquitous computing environments. In EuropeanConference on Smart Sensing and Context (EuroSSC 2006), Enschede, TheNetherlands, 2006.[22] Michael Blackstock, Rodger Lea, and Charles Krasic. Adapting ubicompsystems to a common model. In Common Models and Patterns forPervasive Computing Workshop (CMPPC) at Pervasive 2007, Toronto,Canada, 2007.[23] Michael Blackstock, Rodger Lea, and Charles Krasic. Managing anintegrated ubicomp environment using ontologies and reasoning. InContext Management and Reasoning (CoMoRea) Workshop at PervasiveComputing and Communications (PerCom 2007), New York, 2007.[24] Jeen Broekstra, Arjohn Kampman, and Frank van Harmelen. Sesame: Ageneric architecture for storing and querying RDF and RDF schema. InThe Semantic Web ISWC 2002, pages 54?68. Springer Berlin / Heidelberg,2002.[25] Barry Brumitt, Brian Meyers, John Krumm, Amanda Kern, and Steven A.Shafer. Easyliving: Technologies for intelligent environments. InProceedings of the 2nd international symposium on Handheld andUbiquitous Computing, Bristol, UK, 2000. Springer-Verlag. 743885 12-29.[26] H. Chen, F. Perich, T. Finin, and A. Joshi. SOUPA: Standard ontology forubiquitous and pervasive applications. In International Conference onMobile and Ubiquitous Systems: Networking and Services, Boston, MA,2004.[27] Harry Chen, Tim Finin, and Anupam Joshi. An ontology for context-awarepervasive computing environments. Knowledge Engineering Review,18(3):197?207, 2003.[28] Harry Chen, Tim Finin, Anupam Joshi, Lalana Kagal, Filip Perich, andDipanjan Chakraborty. Intelligent agents meet the semantic web in smartspaces. IEEE Internet Computing, 8(6):69?79, 2004.[29] Stuart Cheshire. Zero configuration networking (Zeroconf).http://www.zeroconf.org/, 2007. last checked: 9-June-2008.Bibliography 158[30] Eleni Christopoulou and Achilles Kameas. GAS Ontology: An ontologyfor collaboration among ubiquitous computing devices. InternationalJournal of Human-Computer Studies, 62(5):664?685, 2005.[31] Roger L. Costello. Web services best practice, summary 3.http://lists.xml.org/archives/xml-dev/200201/msg00477.html, January 2002. last checked: 9-June-2008.[32] Cristiano Andr da Costa, Adenauer Corra Yamin, and CludioFernando Resin Geyer. Toward a general software infrastructure forubiquitous computing. IEEE Pervasive Computing, 7(1):64?73, 2008.[33] Nigel Davies and Hans-Werner Gellersen. Beyond prototypes: Challengesin deploying ubiquitous systems. IEEE Pervasive Computing, 1(1):26?35,2002.[34] Anind K. Dey. Providing Architectural Support for Building Context-AwareApplications. Phd thesis, Georgia Institute of Technology, 2000.[35] Anind K. Dey and Gregory D. Abowd. Toward a better understanding ofcontext and context-awareness. In CHI 2000 Workshop on the What, Who,Where, When, and How of Context-Awareness, The Hague, TheNetherlands, April 2000.[36] Anind K. Dey, Daniel Salber, and Gregory D. Abowd. A conceptualframework and a toolkit for supporting the rapid prototyping ofcontext-aware applictions. Human-Computer Interaction (HCI) Journal,16(2-4):97?166, 2001.[37] Anind K. Dey, Daniel Salber, Gregory D. Abowd, and Masayasu Futakawa.The Conference Assistant: Combining context-awareness with wearablecomputing. In Proceedings of the 3rd International Symposium onWearable Computers, pages 114?128, Dublin, Ireland, 1999.[38] T.B. Downing. Java RMI: Remote Method Invocation. IDG BooksWorldwide, Inc. Foster City, CA, USA, 1998.[39] Aiman Erbad, Michael Blackstock, Adrian Friday, Rodger Lea, and JalalAl-Muhtadi. MAGIC Broker: A middleware toolkit for interactive publicdisplays. In Middleware Support for Pervasive Computing (PerWare)Workshop at Pervasive Computing and Communications (PerCom 2008),pages 509?514, Hong Kong, March 2008.Bibliography 159[40] Matthias Finke, Michael Blackstock, and Rodger Lea. Deploymentexperience toward core abstractions for context aware applications. In 2ndEuropean Conference on Smart Sensing and Context (EuroSSC), Kendal,UK, 2007. Springer.[41] Bryan Ford, Jacob Strauss, Chris Lesniewski-Laas, Sean Rhea, FransKaashoek, and Robert Morris. Persistent personal names for globallyconnected mobile devices. In Proceedings of the 7th USENIX Symposiumon Operating Systems Design and Implementation (OSDI '06), Seattle,Washington, November 2006.[42] A. Fox, A. Fox, B. Johanson, P. Hanrahan, and T. Winograd. Integratinginformation appliances into an interactive workspace. IEEE ComputerGraphics and Applications, 20(3):54?65, 2000.[43] A. Friday, N. Davies, N. Wallbank, E. Catterall, and S. Pink. Supportingservice discovery, querying and interaction in ubiquitous computingenvironments. Wireless Networks, 10(6):631?641, 2004.[44] Erich Gamma. Design patterns : elements of reusable object-orientedsoftware. Addison-Wesley professional computing series. Addison-Wesley,Reading, Mass., 1995. Erich Gamma ... [et al.]. ill. ; 25 cm.[45] Paul Grace, Gordon S. Blair, and Sam Samuel. A reflective framework fordiscovery and interaction in heterogeneous mobile environments.SIGMOBILE Mob. Comput. Commun. Rev., 9(1):2?14, 2005.[46] Chris Greenhalgh. EQUIP: a software platform for distributed interactivesystems. Technical Report 02-002, Mixed Reality Laboratory, Universityof Nottingham, 2002.[47] Chris Greenhalgh, Shahram Izadi, James Mathrick, Jan Humble, and IanTaylor. ECT: a toolkit to support rapid construction of ubicompenvironments. In System Support for Ubiquitous Computing (Ubisys)Workshop at Ubiquitous Computing (UbiComp 2004), Nottingham, UK,2004. Springer.[48] R. Grimm, J. Davis, E. Lemar, A. MacBeth, S. Swanson, T. Anderson,B. Bershad, G. Boriello, S. Gribble, and D. Wetherall. System support forpervasive applications. ACM Transactions on Computer Systems,22(4):421?486, 2004.Bibliography 160[49] William G. Griswold, Robert Boyer, Steven W. Brown, and Tan MinhTruong. A component architecture for an extensible, highly integratedcontext-aware computing infrastructure. In ICSE '03: Proceedings of the25th International Conference on Software Engineering, pages 363?372,Washington, DC, USA, 2003. IEEE.[50] William G. Griswold, Patricia Shanahan, Steven W. Brown, Robert Boyer,Matt Ratto, R. Benjamin Shapiro, and Tan Minh Truong. ActiveCampus:Experiments in community-oriented ubiquitous computing. Computer,37:73?81, 2004.[51] Tao Gu, Hung Keng Pung, and Da Qing Zhang. Toward an OSGi-basedinfrastructure for context-aware applications. IEEE Pervasive Computing,3(4):66?74, October-December 2004.[52] V. Haarslev and R. M?ller. Racer: A Core Inference Engine for theSemantic Web. Proceedings of the 2nd International Workshop onEvaluation of Ontology-based Tools, pages 27?36, 2003.[53] S. Harris and N. Gibbins. 3store: Efficient Bulk RDF Storage. Proceedingsof the 1st International Workshop on Practical and Scalable SemanticSystems (PSSS03), pages 1?20, 2003.[54] Andy Harter, Andy Hopper, Pete Steggles, Andy Ward, and Paul Webster.The anatomy of a context-aware application. In MobiCom '99, pages59?68, New York, NY, USA, 1999. ACM.[55] Karen Henricksen and Jadwiga Indulska. A software engineeringframework for context-aware pervasive computing. In PervasiveComputing and Communications (PerCom 2004), page 77, Los Alamitos,CA, USA, 2004. IEEE.[56] Karen Henricksen, Jadwiga Indulska, and Andry Rakotonirainy. Modelingcontext information in pervasive computing systems. In PervasiveComputing (Pervasive 2002), Zurich, Switzerland, 2002. Springer.[57] Fritz Hohl, Uwe Kubach, Alexander Leonhardi, Kurt Rothermel, andMarkus Schwehm. Next century challenges: Nexus: an open globalinfrastructure for spatial-aware applications. In MobiCom '99, pages249?255, New York, NY, USA, 1999. ACM.[58] J. I. Hong and J. A. Landay. An architecture for privacy-sensitiveubiquitous computing. In Moble Systems, Applications and Services(MobiSys 2004), Boston, MA, USA, 2004.Bibliography 161[59] Jason I. Hong. Context Fabric: Infrastructure support for context awaresystems. In CHI '02 extended abstracts on Human factors in computingsystems, Minneapolis, Minnesota, USA, 2001. ACM.[60] A. Huang, B. Ling, J. Barton, and A. Fox. Making computers disappear:Appliance Data Services. In MobiCom '01, Rome, Italy, 2001.[61] Jan Humble, Andy Crabtree, Terry Hemmings, Karl-Petter Akesson,Boriana Koleva, Tom Rodden, and Par Hansson. Playing with the bits -user-configuration of ubiquitous domestic environments. In UbiComp2003, Seattle, WA, USA, 2003.[62] Valrie Issarny, Daniele Sacchetti, Ferda Tartanoglu, Francoise Sailhan,Rafik Chibout, Nicole Levy, and Angel Talamona. Developing ambientintelligence systems: A solution based on web services. AutomatedSoftware Engineering, 12(1):101?137, 2005.[63] B. Johanson, B. Johanson, A. Fox, and T. Winograd. The interactiveworkspaces project: experiences with ubiquitous computing rooms. IEEEPervasive Computing, 1(2):67?74, 2002.[64] Brad Johanson and Armando Fox. The Event Heap: A coordinationinfrastructure for interactive workspaces. In Proceedings of the FourthIEEE Workshop on Mobile Computing Systems and Applications. IEEEComputer Society, 2002. 837560 83.[65] Brad Johanson, Shankar Ponnekanti, Caesar Sengupta, and Armando Fox.Multibrowsing: Moving web content across multiple displays. InUbiquitous Computing (Ubicomp 2001), pages 346?353, London, UK,2001. Springer-Verlag.[66] Dimitris N. Kalofonos, Zoe Antoniou, Franklin D. Reynolds, MaxVan-Kleek, Jacob Strauss, and Paul Wisner. MyNet: A platform for secureP2P personal and social networking services. PerCom 2008, 0:135?146,2008.[67] Apu Kapadia, Tristan Henderson, Jeffrey J. Fielding, and David Kotz.Virtual Walls: Protecting digital privacy in pervasive environments. InPervasive Computing (Pervasive 2007), pages 162?179, Toronto, Canada,May 2007 2007. Springer.[68] T. Kindberg, J. Barton, J. Morgan, G. Becker, D. Caswell, P. Debaty,G. Gopal, M. Frid, V. Krishnan, H. Morris, et al. People, Places, Things:Bibliography 162Web Presence for the Real World. In Mobile Computing Systems andApplications Workshop, Monterey, CA, December 2000. IEEE ComputerSociety.[69] A. LaMarca, Y. Chawathe, S. Consolvo, J. Hightower, I. Smith, J. Scott,T. Sohn, J. Howard, J. Hughes, F. Potter, et al. Place Lab: DevicePositioning Using Radio Beacons in the Wild. In Pervasive Computing(Pervasive (2005), volume 3468, pages 116?133. Springer, 2005.[70] Rodger Lea and Michael Blackstock. Ubisys 2006 workshop report.http://www.magic.ubc.ca/ubisys/overview.htm, 2006.last checked: 9-June-2008.[71] David S. Linthicum. Next Generation Application Integration.Addison-Wesley Information Technology Series. Addison-Wesley, 2003.[72] S. Maffioletti and B. Hirsbrunner. Ubidev: An homogeneous environmentfor ubiquitous interactive devices. In Pervasive Computing (Pervasive2002), pages 28?38, August 2002.[73] B. McBride. Jena: a semantic web toolkit. Internet Computing, IEEE,6(6):55?59, Nov/Dec 2002.[74] Microsoft. Understanding Universal Plug and Play: A white paper.http://www.upnp.org/download/UPNP_UnderstandingUPNP.doc, 2000. last checked: 9-June-2008.[75] Richard Monson-Haefel. Enterprise JavaBeans. O'Reilly, 3rd edition,2001.[76] Mark W. Newman, Jana Z. Sedivy, Christine M. Neuwirth, W. KeithEdwards, Jason I. Hong, Shahram Izadi, Karen Marcelo, and Trevor FSmith. Challenge: Recombinant computing and the Speakeasy approach.In Mobicom '02, 2002.[77] Daniela Nicklas, Matthias Grobmann, Thomas Schwarz, and Steffen Volz.A model based, open architecture for mobile, spatially aware applications.In SSTD 2001: Proceedings of the 7th International Symposium on Spatialand Temporal Databases, Redondo Beach, CA, USA, 2001. Springer.[78] Daniel Oberle, Andreas Eberhart, Steffen Staab, Raphael Volz, andIn Hans-Arno Jacobsen. Developing and managing software components inan ontology-based application server. In Middleware 2004,Bibliography 163ACM/IFIP/USENIX 5th International Middleware Conference, volume3231 of LNCS, pages 459?478, Toronto, Ontario, Canada, 2004. Springer.[79] Object Management Group (OMG). The Common Object Request Broker:Architecture and Specification, Version 2.6.1, May 2002.[80] Open Services Gateway Initiative Alliance. OSGi Home Page.http://www.osgi.org/, 2008. last checked: 9-June-2008.[81] Organization for the Advancement of Structured Information Standards.OASIS Web Services Security (WSS) TC.http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss, 2008. last checked: 27-Sept-2008.[82] Shankar Ponnekanti, Brian Lee, Armando Fox, Pat Hanrahan, and TerryWinograd. ICrafter: A service framework for ubiquitous computingenvironments. In UbiComp '01: Proceedings of the 3rd internationalconference on Ubiquitous Computing, pages 56?75, London, UK, 2001.Springer.[83] S.R. Ponnekanti, S.R. Ponnekanti, B. Johanson, E. Kiciman, and A. Fox.Portability, extensibility and robustness in iROS. In B. Johanson, editor,Pervasive Computing and Communications (PerCom 2003), pages 11?19,2003.[84] A. Ranganathan, R.E. McGrath, R.H. Campbell, and M.D. Mickunas.Ontologies in a pervasive computing environment. In Proceedings of theIJCAI-03 Workshop on Ontologies and Distributed Systems, volume 71,Acapulco, Mexico, 2003.[85] Anand Ranganathan and Roy H. Campbell. A middleware forcontext-aware agents in ubiquitous computing environments. InMiddleware 2003, volume 2672/2003, pages 143?161. Springer Berlin /Heidelberg, 2003.[86] Hans Gellersen Rene Mayrhofer. Shake well before use: Authenticationbased on accelerometer data. In Pervasive Computing (Pervasive 2007),pages 144?161, Toronto, Canada, 2007. Springer.[87] Manuel Roman, Christopher Hess, Renato Cerqueira, Anand Ranganathan,Roy H. Campbell, and Klara Nahrstedt. Gaia: a middleware platform foractive spaces. SIGMOBILE Mob. Comput. Commun. Rev., 6(4):65?67,2002.Bibliography 164[88] W.A. Ruh, W.J. Brown, and F.X. Maginnis. Enterprise ApplicationIntegration: A Tech Brief. John Wiley & Sons, Inc. New York, NY, USA,2001.[89] Daniel Salber, Anind K. Dey, and Gregory D. Abowd. The ContextToolkit: Aiding the development of context-enabled applications. In CHI,pages 434?441, 1999.[90] Bill N. Schilit, Norman Adams, Rich Gold, Michael Tso, and Roy Want.The PARCTAB mobile computing system. In Fourth Workshop onWorkstation Operating Systems (WWOS-IV), pages 34?39, Napa, CA,USA, 1993. IEEE.[91] Bill N. Schilit, Marvin M. Theimer, and Brent B. Welch. Customizingmobile applications. In USENIX Symposium on Mobile andLocation-Independent Computing, 1993.[92] Evren Sirin, Bijan Parsia, Bernardo Cuenca Grau, Aditya Kalyanpur, andYarden Katz. Pellet: A practical OWL DL reasoner. Journal of WebSemantics, 5(2):51?53, 2007.[93] DK Smetters, D. Balfanz, G. Durfee, T.F. Smith, and K. Lee. InstantMatchmaking: Simple and Secure Integrated Ubiquitous ComputingEnvironments. In Ubiquitous Computing (Ubicomp 2006), volume 4206,page 477, Orange County, CA, Sept. 17-21, 2006 2006. Springer.[94] J. Pedro Sousa and David Garlan. Aura: an architectural framework foruser mobility in ubiquitous computing environments. In Proceedings of the3rd IEEE/IFIP Conference on Software Architecture. Kluwer, B.V., 2002.[95] Oliver Storz, Adrian Friday, and Nigel Davies. Towards ?ubiquitous?ubiquitous computing: an alliance with the grid. In System Support forUbiquitous Computing (Ubisys) Workshop at Ubiquitous Computing(UbiComp 2003), Seattle, 2003.[96] Sun Microsystems. The JavaBeans specification.http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html, 1997. last checked: 9-June-2008.[97] Sun Microsystems. Java 2 Platform, Enterprise Edition (J2EE) Overview.http://java.sun.com/j2ee/overview.html, 2008. lastchecked: 9-June-2008.Bibliography 165[98] Sun Microsystems. Java Enterprise Edition at a Glance.http://java.sun.com/javaee/, 2008. last checked: 9-June-2008.[99] Joo Geok Tan, Daqing Zhang, Xiaohang Wang, and Heng Seng Cheng.Enhancing semantic spaces with event-driven context interpretation. InPervasive Computing (Pervasive 2005), volume 3468/2005, pages 80?97,Munich, Germany, 2005. Springer. 3468.[100] Phil Tetlow, Jeff Z. Pan, Daniel Oberle, Evan Wallace, Michael Uschold,and Elisa Kendall. Ontology driven architectures and potential uses of thesemantic web in systems and software engineering.http://www.w3.org/2001/sw/BestPractices/SE/ODA/,2006. last checked: 9-June-2008.[101] W3C. Resource Description Framework. http://www.w3.org/RDF/,2004. last checked: 9-June-2008.[102] W3C. Web Ontology Language (OWL) overview.http://www.w3.org/TR/owl-features/, 2004. last checked:9-June-2008.[103] W3C. SPARQL Query Language for RDF.http://www.w3.org/TR/rdf-sparql-query/, 2005. lastchecked: 9-June-2008.[104] W3C. SOAP version 1.2 part 0: Primer (second edition).http://www.w3.org/TR/soap12-part0/, 2007. last checked:9-June-2008.[105] W3C. Web Services Description Language (WSDL) version 2.0 part 0:Primer. http://www.w3.org/TR/wsdl20-primer/, June 2007.last checked: 9-June-2008.[106] J. Waldo. The Jini architecture for network-centric computing.Communications of the ACM, 47(7):76?82, 1999.[107] Roy Want, Andy Hopper, Veronica Falcao, and Jon Gibbons. The ActiveBadge location system. ACM Transactions on Information Systems,10(1):91?102, 1992.[108] Mark Weiser. The computer for the 21st century. Scientific American,265(9):94?104, 1991.Bibliography 166[109] Lawrence Wilkes. ROI - the costs and benefits of web services and serviceoriented architecture.http://roadmap.cbdiforum.com/reports/roi/, 2008. lastchecked: 9-June-2008.[110] D. Wood, P. Gearon, and T. Adams. Kowari: A Platform for Semantic WebStorage and Analysis. Proceedings of the 14th International WWWConference, 2005.


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items