Livespace Architecture

Overview

Livespace requirements Discussion of issues Livespace Architecture

The Livespace Framework

A software framework to support provision of the services that constitute a Livespace

Livespace services include: Lights, volume, screen forwarding, room

schematic, session configuration, projector control, room configuration, shared clipboard, information repository, VTC, …

Requirements For Livespace Framework Must support complex services Accessible from multiple hosts Dynamically extensible Allow inter-service dependencies Support multi-room federation Provide management of distributed services High reliability and robustness: service failure

should have minimal effect on room function

Complex Service Example:The Room Schematic

Not a flat tuple: requires nested data objects and lists of objects

Fields are dynamic

Not a flat tuple: requires nested data objects and lists of objects

Fields are dynamic

-logoImage

RoomPresentation

-backgroundColour-backgroundImage-itemFontSize

RoomSchematic

1

-schematic

1-location-isLive-referencedID-icon

SchematicItem1

-items

*

Entity

Example Model:The ICS Room Schematic

Name: ICS Room PresentationLogo: http://ics/ics_logo.gifSchematic:

Name: ICS Room PresentationLogo: http://ics/ics_logo.gifSchematic:

Background Color: blueItem Font Size: 18Items:

Background Color: blueItem Font Size: 18Items:

Name: Front DownlightLocation:100, 58Entity: ICS.light.12

Name: Front DownlightLocation:100, 58Entity: ICS.light.12

Name: Laptop 2Location: 220, 181Entity: ICS.laptop.2

Name: Laptop 2Location: 220, 181Entity: ICS.laptop.2

…

Federating Livespaces

Need to bridge Livespaces across organisations E.g. multi browse remote screens

Need fine-grained control over what information is bridged Especially important when going across

classifications

Service Management

Many services required Lights, volume, screen forwarding, …

Usually small amounts of code (10K - 60K) Do not want to launch a 10MB Java VM for each one

Need to reside on multiple hosts, different services for different hosts

Need to be updated and restarted individually Have multiple dependencies (e.g. screen

forwarding depends on displays, AVX and computers)

The Livespace Architecture

Three keys areas to address Service provision Service deployment and control Multiple room federation

Architecture: Service Provision

The Livespace bus provides a distributed space where information models can be published

Extends the tuple space concept Provides composite, dynamic distributed data models

Services publish models of their state Changing service model triggers the service to act to

“make it so” Visibility: services easily monitored and browsed

Includes service status

How Clients Access Services

Clients issue a query to match service entities they want to find E.g. “find all computer entities”

Services respond by sending copies of matching entities to the client

Client now has a local replica of the desired entities Client replicas are synchronized in both directions

Changes on server are replicated on client Changes on client are sent to server Client always accesses its local copy

Client / Server ReplicationServer

ICS Display Left

computer entity

ServerICS Display Right

computer entity

ServerICS Laptop 1

computer entity

Client

computer entity

computer entity

computer entity

Client discovers and replicates entities of interest

Livespace Service Example

The ICS light service discovers C-Bus light devices publishes representative light entities on the livespace bus

Light state, such as the “level” property, can be seen and changed by any bus client

The Livespace/C-Bus hardware interface synchronises the actual light state with this property

Name: Front Left DownlightLevel:100%

Name: Front Left DownlightLevel:100%

Name: Front Left DownlightLevel: 0%

Name: Front Left DownlightLevel: 0%

Client sets “level” to 0

Light on Light off

Complex Service Example:Screen Forwarding

Name: laptop 1User: DerekDesktops:

Name: laptop 1User: DerekDesktops: Name: Projector Left

AvxPort : 1Desktop: laptop1.desktop 1Power: on

Name: Projector LeftAvxPort : 1Desktop: laptop1.desktop 1Power: on

ID: laptop 1.desktop 1Primary: trueAvxPort: 12

ID: laptop 1.desktop 1Primary: trueAvxPort: 12

ID: laptop 1.desktop 2Primary: falseAvxPort: 13

ID: laptop 1.desktop 2Primary: falseAvxPort: 13

Name: Projector CentreAvxPort : 2Desktop: laptop1.desktop 2Power: on

Name: Projector CentreAvxPort : 2Desktop: laptop1.desktop 2Power: on

Name: Projector RightAvxPort : 3Desktop: display 1.desktop 1Power: on

Name: Projector RightAvxPort : 3Desktop: display 1.desktop 1Power: on

Name: Display ServerUser: [none]Desktops:

Name: Display ServerUser: [none]Desktops:

ID: display server.desktop 1Primary: trueAvxPort: 6

ID: display server.desktop 1Primary: trueAvxPort: 6

Co

mp

ute

rs Disp

lays

Architecture: Service Management

All services are packaged as components Using OSGi v3.0 standard

Versioning and dependency management Deployment to all hosts from a single point Lightweight - OSGi is designed for mobile

platforms Many existing components (HTTP servlets,

web services, etc)

Architecture: Service Management

An OSGi core (“Knopflerfish”) is deployed as a Windows or Unix service Always running – no logon required for services to be

active Reduced resource usage – a single Java VM Increased fault tolerance – automatic restart on crash

All components are network-loaded from the repository

Centralised configuration determines: Which services run on what hosts Service configuration parameters

Approach: Multiple Rooms

The framework explicitly models multiple rooms as livespace entities

The “local” room is easily discoverable Can federate with other rooms selectively

using Elvin federation rules E.g. allow read-only access to room resources

except the shared clipboard

Other Benefits: Visibility

All services on the bus can be browsed

Other Benefits: Rapid Development We can rapidly develop new services

Define a shared clipboard entity:

Publish it:

public class ClipboardEntity extends Entity{ public String text;}

ClipboardEntity sharedClipboard = new ClipboardEntity ("Default"); EntityServer server = new EntityServer (room, "clipboard");

server.entities.add (sharedClipboard);

Relation To Other Technologies

A number of new technologies take a similar distributed service model approach Service Data Objects (SDO) Joint Battlespace Infosphere (JBI)

Acknowledge limitations of RPC + static data models (e.g. SOAP)

Complex service provision benefits from a looser, model-centric architecture

Comparison With iROS Tuple Space Architecture The data model used by iROS is a flat tuple

space All data is described by name/value pairs Not designed to support compound values

e.g. values that are themselves tuples or lists of tuples

Does not support fine-grained change Changes effected by adding/removing whole tuples

Does not allow fields to be added at runtime

Current Status

The following slides show examples of the new ICS Session Configuration Manager and Ignite Room Control Panel

Session Configuration:Choose Session

Session Configuration:Edit Session

Ignite: Room Control Panel

Demo & Discussion