Abc Architectural Support for Activity- Based and Ubiquitous Computing Jonathan Bunde-Pedersen Ph.D. student Centre for Pervasive Healthcare Aarhus University

abc

Architectural Support for Activity-Based and Ubiquitous

Computing

Jonathan Bunde-PedersenPh.D. student

Centre for Pervasive HealthcareAarhus University

Jonathan Bunde-Pedersen

Doctoral Colloquium 2

abc

Activity-Based Computing – Objects

• Activities– Carrying out a task,

unit of work

• Services– Application or

service, partial runtime-state

• Data– File, portions of a

file, simple values

”Viewing X-Rays”

Simple text data

X-Ray data ”proxy”

Meta-information about X-Ray

Info

rmat

ion

Con

trol

Data

Service

ActivityConnectors



abc

Activity-Based Computing – Operations

• Suspend– Gathering runtime state– “Exiting” all services

• Resume– Fetching runtime state– Starting each service– Re-establishing state

• Share– Duplicating state (via server)– Events– Collaboration widgets



abc

Related projects

• Project Aura– Garlan et. al., CMU

• Gaia OS– Román et. al., Univ. of Illinois at Urbana-Champaign

• Microsoft Groupbar– Microsoft Research

• one.world– Grimm et. al., NYU

• iRoom– Johanson et. al., Stanford Univ.

• MobileSpaces – Satoh, National Institute of Informatics, Tokyo



abc

Current State – Generally

• Migration of applications, data• Applications and devices

– Many-to-one (window systems, threads)– One-to-many (teaching-tools)– Many-to-many (agents, mobile code)

• People and devices– Many-to-one (public displays (?))– One-to-many (remote desktop, chat, etc.)– Many-to-many (public displays)



abc

Current State – v4 implementation

• Client-server– Server is required for

collaboration– Server scales nicely

(for our purposes)– Cache works locally

• Front-ends– UIs for different needs– Wearable– Wall– Desktop

ActivityController

ServiceController

CollaborationController

ActivityBar UIWidgets

Collaboration Widgets

UI layer

Client layer

ActivityManager CollaborationManager

ContextService

ActivityStore

Infrastructure layer

StateManager



abc

Current State - v4 user interface



abc

Current State - v4 user interface



abc

Architecture – Overview

• Activity Manager• Components

– Agent-like components

– System– Functionality

• Connectors

OS

Activity Manager

Migration component

Persistency Component

Service/ Resource Discovery

Component

Etc.

”Proxy” for Component A

OS

Activity Manager

A

Device 1 Device 2

”Rubberband” connectors

System component

Activity components

Proxy for a component

Act

ivity

Hie

rarc

hy



abc

Architecture – “Rubberbands”

• Migration policy• “Self-organizing”• Elasticity, stretch (distance) and weight



abc

Architecture – Programming model

• Annotations

• Migration is provided• Intra-activity communication is provided

– E.g. patient switcher– Templates for activities

[StatefulField(“my_scrollbar”)]public ScrollBar MyScrollBar;

[StatefulField(“my_string”)]public string MyString;



abc

Architecture – Visibility

• AMAP– Hierarchical map showing off inner

workings of architecture

• “Global” variables• Event-handlers …

– as communication tool– as monitoring tool



abc

Contributions – Collaboration

• Exploring …– one application many devices– one person many devices– many people one device



abc

Contributions – Collaboration

Device 1(surgeon)

Device 3(anesthesiologist)

Device 2(shared wall-sized display)

OS

Activity Manager

A

OS

Activity Manager

Activity 1

Device 1 Device 2

OS

Activity Manager

Device 3

A B

Split-screen component B

Activity 2



abc

Contributions – Migration

• Data and applications– Different types of

data– Applications

likewise

• Exploring …– many people

many devices– many-applications

many devices

Device 1(palm-sized display)

Device 2(wall-sized display)

Activity is partitioned between two devices



abc

Contributions – Serverlessness

• Electable server-role (super-peer system)

• Obvious advantage: Single point of failure

• Configuration(less)– Writing a Jini or uPnP system component

• Challenges– Migration of data– Consistency, synchronization issues



abc

Approach – Project scope

• Centre for Pervasive Healthcare– Scandinavian tradition of participatory

design

• ABC project (4 years)• ElderTech project (6 months)• Ph.D.s

– Sensor networks– Novel user interfaces– Architecture (me)



abc

Approach – User involvement

• Original concepts based on user input• Architecture ideas + requirements

from experiences with v4

• ElderTech (senior citizens, nurses, care-staff)

• Falck (emergency rescue personnel)• Horsens Hospital (doctors, nurses)



abc

Approach – Prototyping

• Architectural prototype• Services

– Picture/Video Album (ET)– Hospitals (aware)

• X-Ray viewer• Journal

– Emergency medicine (palcom)• Injury-charts• ER organizer

• Merge concurrent projects into ABC



abc

Evaluation – Technical

• Performance

• Reliability (improvement over single point of failure)• Scalability (How many peers, services and how much

data can we sustain?)• Complexity (How hard is it writing services?)



abc

Evaluation – ElderTech

• Co-operation w. kommune, IBM, “nursing home”

• Utility (Have we enabled others to be successful?)– Architecture as a framework

for building services– Sensor network

• Completeness (Can we build useful services?)



abc

Open issues

• Current status– Related research– Implementation

• Approach• Evaluation

– Activity as concept?– Activity operations?– Privacy concerns (shared activities)

Documents

Abc Architectural Support for Activity- Based and Ubiquitous Computing Jonathan Bunde-Pedersen Ph.D. student Centre for Pervasive Healthcare Aarhus University