Livespace Architecture

1. Livespace Architecture

2. Overview • Livespace requirements • Discussion of issues • Livespace Architecture

3. 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, …

4. 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

5. Complex Service Example:The Room Schematic Not a flat tuple: requires nested data objects and lists of objects Fields are dynamic

6. Example Model:The ICS Room Schematic Name: ICS Room Presentation Logo: http://ics/ics_logo.gif Schematic: Background Color: blue Item Font Size: 18 Items: Name: Front Downlight Location:100, 58 Entity: ICS.light.12 … Name: Laptop 2 Location: 220, 181 Entity: ICS.laptop.2

7. 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

8. 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)

9. The Livespace Architecture • Three keys areas to address • Service provision • Service deployment and control • Multiple room federation

10. 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

11. 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

12. Client / Server Replication Server ICS Display Left Server ICS Display Right Server ICS Laptop 1 computer entity computer entity computer entity Client discovers and replicates entities of interest Client computer entity computer entity computer entity

13. 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% Client sets “level” to 0 Name: Front Left Downlight Level: 0% Light on Light off

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

15. 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)

16. 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

17. 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

18. Other Benefits: Visibility • All services on the bus can be browsed

19. 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);

20. 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

21. 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

22. Current Status • The following slides show examples of the new ICS Session Configuration Manager and Ignite Room Control Panel

23. Session Configuration:Choose Session

24. Session Configuration:Edit Session

25. Ignite: Room Control Panel

26. Demo & Discussion