1 / 26

Livespace Architecture

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:

wilmer
Télécharger la présentation

Livespace Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related