1 / 22

Extending Tuplespaces for Coordination in Interactive Workspaces

Extending Tuplespaces for Coordination in Interactive Workspaces. https://graphics.stanford.edu/papers/eheap-jss/. Enrica Dente Digital Enterprise Research Institute enrica.dente@deri.org 2004/07/26. Objective. To understand: What is Tuplespace computing?

donald
Download Presentation

Extending Tuplespaces for Coordination in Interactive Workspaces

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. Extending Tuplespaces for Coordination in Interactive Workspaces https://graphics.stanford.edu/papers/eheap-jss/ Enrica Dente Digital Enterprise Research Institute enrica.dente@deri.org 2004/07/26

  2. Objective • To understand: • What is Tuplespace computing? • Event Heap Implementation for Interactive Workspaces • Relevance to WSMO

  3. Overview • Interactive Workspaces Requirements • Tuplespace Model • Event Heap: Tuplespace Model + Extensions • Summary • Relevance to Semantic Web Services • Deri Triplespace Computing Projects

  4. What is an Interactive Workspace? • Interaction with or ensembles of applications/computers • No clear coordination model at the application level • IRoom prototype “It is an ubiquitous computing environment where groups come together to collaborate on solving problems”.

  5. What is an Interactive Workspace?(cont.) • It is a dynamic environment for integration and coordination • It contains : • Embedded devices: • Permanent computational and I/O resources embedded into the environment • Mobile devices: • Allows portable devices brought into the space to be used in conjunction with embedded facilities (i.e ongoing) • Interoperability • Autonomy (of participating organizations) • Trust, privacy and security.

  6. Interactive Workspace Factors (learning from iRoom prototype) • Technology factors: (i.e coordination, integration, dynamism) • Changing environment (i.e short and long term change) • Heterogeneity (i.e rapid integration of heterogeneous hardware, software and software platforms) • Human factors: (i.e problem solving, collaboration) • Bounded Environment (i.e only within IW’s physical space ) • Human Centred Interaction (i.e can reconfigure tools depending on problems arising) • Human Level Performance needs (i.e can set constraints).

  7. Interactive Workspace Requirements • Must facilitate common IW Usages: • Moving data between devices • Controlling devices and applications from other devices • Coordinating applications. • Must meet these requirements: • Heterogeneity of devices in the workspace, and new devices being added over time • Easy integration of legacy devices, using whatever communication mechanisms they provide. • Robustness and availability despite software/hardware failure • Portability across installations.

  8. Interactive Workspace Desired Properties • Limited Temporal Decoupling • Data relevance until needed • Communication continuity • Referential Decoupling • Limited inter-dependency, still interaction possible • Location independence • Extensibility • Snooping • Interposability • Stream transformation • Expressiveness • Coordination and distribution patterns

  9. Interactive Workspace Desired Properties (cont.) • Simple and Portable client API • Reduced number of API calls and amount of code • Easy Debugging • Easy to figure out and debug interactions • Perceptual Instantaneity • Coordinations and actions instantaneous to user • Latencies minimized (i.e 50 ms for round trip) • Failure Tolerance and Recovery • Mechanisms for coping with failures • Application Portability • Coordination infrastructure independent from IW. • Scalability to Workspace-sized Traffic loads • Load limited by number of entities connected and rate of updates

  10. Properties Supported by Coordination Infrastructures • In Pub-Sub and MOM: • Application portability • Query persistence and notification via subscription • In RMI/RPC: • Perceptual Instantaneity only • In Tuplespace Model and Pub-Sub: • Referential Decoupling • Simple and Portable Client API • Perceptual Instantaneity • Extensibility (limited support) • Easy debugging (limited support) • Further Reading: • InfoBus system • Eugster et al. overview • Siena system • Tuplespace Modelhas most properties needed for Interactive Workspaces. • In Tuplespace Model also: • Limited Temporal Decoupling • Expressiveness • Failure Tolerance and Recovery (limited support)

  11. Linda Tuplespace Model*for parallel computing • Goal: add concurrent programming capability to sequential programming • Need strong decoupling of processes in space, time and reference • Solution: place data as tuples in the space for process coordination • Tuple: • object named by tag and key (similar to content addressable memory) • symbolic name + an ordered list of typed values • equally accessible to all processes but bound to none • Tuplespace: • “shared memory" for accessing, modifying and deleting tuples • data fields in space matched with elements in requesting template • must have same number of fields, same types of fields in same order, (possibly identical values as in the template) • retrieval made blocking when there is no match • actuals assigned to formals when match found. *Carriero and Gelernter, 1986 *Carriero and Gelernter, 1986 *Carriero and Gelernter, 1986 *Carriero and Gelernter, 1986

  12. In () Receiver 1 Read () Out () Receiver 2 Sender Linda Tuplespace Model*for parallel computing (cont.) • 6 funtions: • out(<tuple>) -inserts a tuple in the space. It never blocks a tuple. • rd(<template(tag, list)>) - retrieves all tuples which match a given template from the TS. It can be both blocking and non blocking. • in<template(tag, list)> - retrieves and removes all tuples which match a given template from the space. This function blocks. • eval(<function-tuple>) - creates an active tuple and evaluate its entries. The results are stored as a passive tuple(i.e data) in the space. Tuplespace Figure 1 Tuplespace Model for parallel programs *Carriero and Gelernter, 1986

  13. Linda Tuplespace Model*for parallel computing (cont.) Process 1: Ping () { loop { out("PriceOfBook", "100") in("PriceOfBook", "200") } } Process 2: Pong () { loop { in("PriceOfBook", "100") out("PriceOfBook", "200") } }

  14. Tuplespace Model for Interactive Workspaces • Routing and Content Addressing provides reference decoupling • Persistence providestemporal decoupling • Limited Transparency providesextensibility and debugging • Centralization providestime and reference decoupling • Simple and general infrastructure API: 6 functions in any programming language.

  15. Event Heap:Tuplespace Model + Extensions • Limitations: • For processes designed to work together (parallel programming) • Extensibility and application portability not supported • Push not supported.No guarantee for receipt of events • Benefits • Integration and Extensibility • Application Portability • Easy debugging • Anonymous Coordination • Interposability • Snooping • Expressiveness • Failure Tolerance + Recovery. • Extensions: • Self-Describing Tuples • Flexible Typing • Typed Tuples • Tuple Sequencing • Tuple Expiration • Standard Routing fields • Query registration + notification • At Most Once Ordering (FIFO) • Modular Restartability.

  16. Extensions Supported in Tuplespace Implementations • GigaSpaces and TSpaces • Self-Describing Tuples • Flexible Typing (limited support) • Tuple Expiration • Query Registration • L2mbo • Flexible Typing • Tuple Expiration • LIME • Registration • At Most Once Ordering • Modular Restartability • Standard Routing Fields (limited support) • Known implementations support few extensions

  17. Event Heap ExtensionsSource: http://graphics.stanford.edu/papers/eheap3/ • Event standard fields • User fields (EventType, TimeToLive) • Routing fields (target and source fields) • Internal user fields (SessionID, SequenceNum, EventHeapVersion) • Field structure: • Type • Name • Post Value • Template Value • Permitted values: • Actual • Formal • Virtual • Auto-set, auto-set overrideable Figure 2: Example operation showing placed events, and using template events for matching

  18. Summary • IWsrequire reusable, portable and robust software infrastructure • Need uniform, useful, abstraction, that automatically manages shared data and state. • Tuplespace Model, RMI/RPC, Pub-Sub, MOM don’t have all properties required • Tuplespace Model best suited to Interactive Workspaces: • Supports limited temporal decoupling and expressiveness • least amount of extensions needed, compared to the other models (i.e portability) • Event Heap: Tuplespace Model + Extensions address issue of portability • General applicability to ubiquitous computing and to the web to be demonstrated.

  19. Open Issues • Centralization reduces scalability (not suitable for the web) • Extensions support heterogeneity but sacrifice performance • Improving performance (more events per second at latency of less than 50 ms for round trip) • Content-based matching with streaming of high bandwidth data (e.g sound or video) not suitable • Extensibility and easy debugging versus security and privacy (i.e transparency of data communication) • More coordination and communication types • Tuple types and fields names collisions (i.e if they have the same permitted values) • Each value expressed as an RDF type? (i.e semantic typing) • Use URI to give address to tuple and group related triples?

  20. Relevance toSemantic Web Services • Web Services are about coordination and integration: • Extensibility and application portability • Failure tolerance and recovery • Easy debugging and communication (e.g receipt of all events) • Performance and scalability • Need a set of policies (i.e ontologies) from specialised middleware: • Routing compatibility • Ordering • Limited Data Persistence, Query Persistence and registration • Communication transparency (address security and privacy issues) • Distributed Infrastructure (address performance and scalability issues) • Modular restartability • Spaces can store triples, triples can store data on spaces.

  21. Deri Triplespace Computing Projects • D21: Triplespace computing and WSMX • State of the art and implementation issues • Relationship with WSMX Event Manager? • Relationship with WSMX Invoker? • Develop sets of components outside WSMX? • FIT-IT project (in collaboration with Eva Kuehn from Tecco) • Corso extensions to publish and retrieve triples • Proposal and work packages in draft status • Architecture in draft status.

  22. References • [Fense,l 2004] DERI Research Report 2004-05-31, Triple-based Computing, http://www.wsmo.org/2004/tp-computing/ , 2004 • [Gelernter, 1992] D. Gelernter, Mirrorworlds, Oxford University Press, 1992 • [Johanson, 2002] Brad Johanson and Armando Fox The Event Heap: A Coordination Infrastructure for Interactive Workspaceshttp://graphics.stanford.edu/papers/eheap3/ , 2002 • [Fenwick, 1996] James B. Fenwick Jr., Lori L. Pollock. Issues and Experiences in Implementing a Distributed Tuplespace. Technical Report TR 9706, University of Delaware, 1996. http://www.eecis.udel.edu/~pollock/papers/spe_deli.ps • [Kühn, 2001] Kühn Eva, Virtual Shared Memory for Distributed Architecture, Nova Science Publishers, 2001

More Related