Ubiquitous Computing and Active Spaces The Gaia Approach

1
Ubiquitous Computing and Active Spaces The
Gaia Approach

• Fabio Kon
• kon_at_ime.usp.br
• Department of Computer Science
• University of São Paulo, Brazil
• http//www.ime.usp.br/kon

2
Ubiquitous Computing

• We believe that people live through their
  practices and tacit knowledge so that the most
  powerful things are those that are effectively
  invisible in use.
• For 30 years most interface design, and most
  computer design, has been headed down the path of
  the dramatic machine.
• Mark Weiser

3
Active Spaces

• This is a challenge that affects all of computer
  science. Our preliminary approach Activate the
  World.
• Mark Weiser
• Active Spaces Physical spaces augmented with
  computing devices and software to enhance its
  capabilities.
• Examples offices, lecture and meeting rooms,
  homes, hospitals, campuses, airports, cities,
  highways, ...

4
Priority 1Managing Dynamism

• Mobile users
• Mobile devices
• Mobile Software
• Evolving Software
• new component versions
• new configurations
• Evolving Hardware
• Replacing old devices by new ones
• Reconfiguring devices

5
Our Approach

• 2K Network-Centric OS a meta-OS that provides
  support for any kind of dynamic, heterogeneous
  environment.
• Gaia provides services directly related to
  supporting physical active spaces.

6
The 2k Network-Centric OS

• Runs as middleware on top of Solaris, Linux,
  Windows.
• Goal Facilitate the management of dynamic,
  heterogeneous systems by
• developers,
• system administrators, and
• users.

7
Scope of 2K Research

• 1. Interoperability
• (IDL, CORBA, reflective ORBS, minimal ORBs)
• 2. Naming and Trading (OMG standard)
• 3. Component-based services and applications
• 4. Dynamic (re)configuration
• 5. Security and Privacy

8
Scope of 2K Research

• 6. Distributed Resource Management
• 7. Quality of Service
• 8. Monitoring
• 9. Fault-Tolerance
• But, remember
• Not all these features are required all the time.
  So, configurability is the key.

9
Gaia Getting Physical

• In addition to the 2K functionality, must have
• Federation of Name Servers and Traders
• Framework to represent heterogeneous devices
• Data Object Service
• Location Service (for things that move)
• Event Service
• Discovery Service
• Security Service
• Bridges/adapters to other models (e.g. Jini)

10
Representing Physical Spaces
11
Using the Trader FederationTo Locate Devices

• printerOffer
• DCLTrader-gtquery(printer,
• Postscript True and
  PagesPerMinute gt 10,
• min (Price))
• myPrinter printerOffer.reference
• myPrinterProperties printerOffer.properties
• myPrinter-gtprint (myFile)
• cout ltlt Your file is being printed in room ltlt
  myPrinterPropertiesROOM ltlt endl

12
Framework for Representing Heterogeneous Devices

• Plan9 and UNIX use a single FILE interface for
  accessing all devices.
• Many times this is not appropriate.
• Other extreme having an independent interface
  for each new device.
• Difficult to manage and to program.
• Intermediate approach
• Object-Oriented Framework for Devices.

13
Inheritance Diagram for Active Space Entities
14
The Data Object Service

• Christopher Hess (Illinois) inspired by Francisco
  Ballesteros (Madrid).
• Motivation
• Growing use of heterogeneous devices connected to
  a single global network, accessing the same data.
• Some devices possess limited resources and may
  not be able to render data in original format.
• Using an Adaptable Data Service devices access
  data source in the format they require.
• Service handles complex tasks ordinarily left to
  the application developer.

15
Data Object ServiceOverview

• Applications open data as desired type
• dynamically typed file system.
• Information delivered as data objects.
• Data sources represented as containers.
• Access to data gained via iterators.
• System sets up data flow paths.
• Modules in flow path may alter data.

16
Example
Pixel2Bitmap Converter
Text2Audio Converter
GIF2Pixel Converter
Grep Processor
Pixel2Bitmap Converter
Word Container
MPEG Container
GIF2Pixel Converter
Mail Container
PowerPoint Container
MPEG
Word
Mail
PowerPoint
17
Architecture Overview
Container Manager
XML Database
Client Library
Component Repository
Application
room Layout Manager
18
Container Categories

• File containers access to native operating
  system files.
• Processor containers files with dynamic
  content.
• Converter containers transform content.
• Partition containers creates chunks for
  streamable containers.

19
Path Generator
Converter/Processor Containers
File Containers
Interface Map
.gif
GIF2PixelContainer
bitmap
Pixel2BitmapConverter
BitmapContainer
pixel
.ppt
gif
GIF2PixelConverter
PowerPointContainer
PixelContainer
PowerPointContainer
.mpg
mpeg
MPEGContainer
MPEGContainer
WordContainer
.txt
text
TextContainer
TextContainer
WordContainer
DirectoryContainer
dirent
.doc
ByteContainer
DirectoryContainer
byte

ByteContainer
20
Uses of Containers

• Data storage files and directories.
• Devices - printer, whiteboard, X10.
• Shared memory - tuple spaces.
• Proxies remote transformations.
• Change interfaces of data sources whiteboard to
  mouse.
• Services news.

21
Ongoing Work

• Port to small devices (e.g., PalmPilot).
• Dynamic placement for load balancing.
• Streaming of container contents.
• Use as location-specific storage

Layout Manager
22
Gaia Kernel Discovery Service

• Tracks entities entering and leaving the space
• Software Components
• People
• Physical entities
• Keeps information about active entities
• Exports information using the Event Service.

23
Gaia Kernel Space Repository

• Stores and exports information about entities
  contained in the space.
• Automatically updates a trading service with
  entity information (includes object reference).
• Keeps a list of entities up-to-date by listening
  on the Discovery Channel.
• At bootstrap, parses an XML file containing a
  list of entities to be started automatically.

24
Gaia Kernel Security Service

• Binny Gill and Prashant Viswanathan
• Authentication and Credentials
• Access Control
• Secure Loading of Components
• Secure Bootstrapping of Active Spaces
• Tracking and Privacy

25
Gaia Kernel Security Service

• Authentication
• In an ubiquitous computing environment different
  mechanisms of authentication will exist
• Swipe Cards.
• Smart Badges.
• Fingerprinting, Voice recognition, etc.
• Traditional login/password authentication.

26
Gaia Kernel Security Service

• Authentication
• Problems addressed
• Delegation of authority to trusted programs.
• Delegation of authority to untrusted programs.
• Simple authentication a user authenticating
  himself to a service
• Mechanisms
• Credentials Generic, Restricted and
  Non-Delegatable.

27
Gaia Kernel Security Service

• Access Control
• Users can be assigned
• Roles and Role Attributes. (student , new
  employee)
• Value Attributes. (Age 23)
• Policies for resources
• Specified in terms of roles and attributes.
• Support method-level policies.
• Associated with every resource and are used by
  the Access Control Service in conjunction with
  credentials to grant/deny access.

28
Gaia Kernel Security Service

• Secure component loading
• All components are downloaded from a Component
  Repository and are loaded in a Component
  Container.
• Policies in the Component Container determine
  which user can load components within it.
• The Component Repository also has policies
  associated with it determining which user can
  upload/download components.
• Components can be signed to verify authenticity.

29
Gaia Kernel Security Service

• Secure bootstrap (two levels)
• First Level consists of boot-strapping Security
  Services, Naming Service and other basic
  services.
• The services started in the first level
  constitute the Trusted Computing Base for GAIA.
• Second Level boots an active space after
  verifying the integrity of the first level.

30
Gaia KernelSecurity Service

• Tracking and privacy
• Tracking the system is aware of the location of
  users and devices.
• Privacy the location information should not be
  made public unless explicitly desired by the user.

31
UICUniversally Interoperable Core

• Component-based communication middleware by
  Manuel Román (Ubicore)
• Motivation
• Ubiquitous Computing requires a very flexible and
  dynamically configurable distributed object model
  (e.g. dynamicTAO).
• But
• CORBA (and dynamicTAO) is too big
• Unfortunately ? CORBA is not the only model

32
UIC and WYNIWYG

• What You Need is What You Get
• The ORB is broken small components.
• Only the required ones are loaded.
• Components can be loaded and unloaded dynamically
  to customize functionality.
• Result the middleware can fit in very small
  devices.

33
Current Approach

• Different interoperability mechanisms require
  different object implementations.

Object 1
Object 1
Object 1
Corba
Object 1
JavaRMI
SOAP
34
UIC Object is Always the Same

• Changes in the interoperability mechanisms should
  not affect the implementation of the object.

Corba
Object 1
Object 1
JavaRMI
SOAP
35
Customization

• Transport protocol and Connection establishment
• Marshaling and demarshaling strategies
• Memory Management
• Method invocation protocols
• Data streaming protocols
• Method dispatching scheduling
• Object reference generation and parsing
• Object registration and method dispatching
• Client and Server Interface
• Thread strategies

36
UIC Personalities
skeleton
UIC-RTP
UIC-SOAP
UIC-CORBA
Common infrastructure
37
Static Configuration

• Assemble the UIC at link time.
• No reconfiguration allowed.
• Best size results.

38
Dynamic Configuration

• Assemble the UIC at runtime.
• Replace components at runtime.
• Reconfigure architecture at runtime.
• Size increases (dynamic manipulation
  infrastructure).
• Recommended for dynamic scenarios.
• Service provider can update UIC remotely.

39
UIC-CORBA Sizes
40
Ongoing Work

• Integration of all current services in
  experimental Active Spaces at the U. of Illinois
• Sensing / Tracking / Visual Recognition
• Adaptive Networking
• Power Management for Mobile Devices
• Rendering Realistic 3D Models
• U. São Paulo
• Supporting Adaptive Applications
• Distributed Information Services for Mobile Users

41
Project SIDAMTraffic Information System

• São Paulo is a city of 17M people
• Street and road traffic is a complete chaos.
• Goal
• develop a prototype of a very-large-scale system
  to provide relevant information about traffic
  conditions in real-time to mobile users.

42
Research Topics

• Scalability, replication, data consistency
• Protocols for mobile computing
• Data obsolescence
• Dynamic Reconfiguration for
• fault-tolerance
• load balance
• mobility (change of context)
• promoting data locality

43
The Java Prototype

• Information Servers (traffic information).
• Location Servers (a directory service of
  Information Servers).
• ComponentConfigurators manage the dependencies
  between ISs and LSs.
• Also hold information about alternatives.
• Failure of an Information Server triggers
  automatic reconfiguration.

44
Project SIDAMOngoing Work

• Trigger automatic reconfiguration when any
  component in the system fails.
• Creation and destruction of Information and
  Location Servers according to system load.
• Migration of components according to load and
  phisical location of clients.
• Goal increase availability and response time of
  the Traffic Information System.

45
For more information

• Roy Campbell roy_at_cs.uiuc.edu
• Fabio Kon kon_at_ime.usp.br
• 2K Web site
• http//choices.cs.uiuc.edu/2K
• Gaia Web site
• http//choices.cs.uiuc.edu/gaia
• SIDAM Web site
• http//www.ime.usp.br/sidam