livespace architecture. overview livespace requirements discussion of issues livespace architecture
TRANSCRIPT
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