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

Example Model: The ICS Room Schematic Name: ICS Room Presentation Logo: Schematic: Name: ICS Room Presentation Logo: Schematic: Background Color: blue Item Font Size: 18 Items: Background Color: blue Item Font Size: 18 Items: Name: Front Downlight Location:100, 58 Entity: ICS.light.12 Name: Front Downlight Location:100, 58 Entity: ICS.light.12 Name: Laptop 2 Location: 220, 181 Entity: ICS.laptop.2 Name: Laptop 2 Location: 220, 181 Entity: 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 Replication Server ICS Display Left computer entity Server ICS Display Right computer entity Server ICS Laptop 1 computer entity Client 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 Downlight Level:100% Name: Front Left Downlight Level:100% Name: Front Left Downlight Level: 0% Name: Front Left Downlight Level: 0% Client sets “level” to 0 Light onLight off

Complex Service Example: Screen Forwarding Name: laptop 1 User: Derek Desktops: Name: laptop 1 User: Derek Desktops: Name: Projector Left AvxPort : 1 Desktop: laptop1.desktop 1 Power: on Name: Projector Left AvxPort : 1 Desktop: laptop1.desktop 1 Power: on ID: laptop 1.desktop 1 Primary: true AvxPort: 12 ID: laptop 1.desktop 1 Primary: true AvxPort: 12 ID: laptop 1.desktop 2 Primary: false AvxPort: 13 ID: laptop 1.desktop 2 Primary: false AvxPort: 13 Name: Projector Centre AvxPort : 2 Desktop: laptop1.desktop 2 Power: on Name: Projector Centre AvxPort : 2 Desktop: laptop1.desktop 2 Power: on Name: Projector Right AvxPort : 3 Desktop: display 1.desktop 1 Power: on Name: Projector Right AvxPort : 3 Desktop: display 1.desktop 1 Power: on Name: Display Server User: [none] Desktops: Name: Display Server User: [none] Desktops: ID: display server.desktop 1 Primary: true AvxPort: 6 ID: display server.desktop 1 Primary: true AvxPort: 6 Computers Displays

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