Extending Tuplespaces for Coordination in Interactive Workspaces https

  • Slides: 22
Download presentation
Extending Tuplespaces for Coordination in Interactive Workspaces https: //graphics. stanford. edu/papers/eheap-jss/ Enrica Dente Digital

Extending Tuplespaces for Coordination in Interactive Workspaces https: //graphics. stanford. edu/papers/eheap-jss/ Enrica Dente Digital Enterprise Research Institute enrica. [email protected] org 2004/07/26

Objective • To understand: – What is Tuplespace computing? – Event Heap Implementation for

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

Overview • • • Interactive Workspaces Requirements Tuplespace Model Event Heap: Tuplespace Model +

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

What is an Interactive Workspace? “It is an ubiquitous computing environment where groups come

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

What is an Interactive Workspace? (cont. ) • It is a dynamic environment for

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. Enrica Dente 5

Interactive Workspace Factors (learning from i. Room prototype) • Technology factors: (i. e coordination,

Interactive Workspace Factors (learning from i. Room 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). Enrica Dente 6

Interactive Workspace Requirements • Must facilitate common IW Usages: – Moving data between devices

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

Interactive Workspace Desired Properties • Limited Temporal Decoupling – Data relevance until needed –

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 Enrica Dente 8

Interactive Workspace Desired Properties (cont. ) • Simple and Portable client API – Reduced

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 Enrica Dente 9

Properties Supported by Coordination Infrastructures • • In RMI/RPC: In Pub-Sub and MOM: –

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

Linda Tuplespace Model* for parallel computing • Goal: add concurrent programming capability to sequential

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. Enrica Dente *Carriero and Gelernter, 11

Linda Tuplespace Model* for parallel computing (cont. ) • 6 funtions: - out(<tuple>) -

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. In () Receiver 1 Tuplespace Sender Read () Out () Receiver 2 Figure 1 Tuplespace Model for parallel programs *Carriero and Gelernter, 1986 Enrica Dente 12

Linda Tuplespace Model* for parallel computing (cont. ) Process 1: Ping () { loop

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

Tuplespace Model for Interactive Workspaces - Routing and Content Addressing provides reference decoupling -

Tuplespace Model for Interactive Workspaces - Routing and Content Addressing provides reference decoupling - Persistence provides temporal decoupling - Limited Transparency provides extensibility and debugging - Centralization provides time and reference decoupling - Simple and general infrastructure API: 6 functions in any programming language. Enrica Dente 14

Event Heap: Tuplespace Model + Extensions • • Limitations: - For processes designed to

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 Extensions: • Benefits – Self-Describing Tuples - Integration and Extensibility – – – – Flexible Typing Typed Tuples Tuple Sequencing Tuple Expiration Standard Routing fields Query registration + notification At Most Once Ordering (FIFO) Modular Restartability. - Application Portability - Easy debugging - Anonymous Coordination - Interposability - Snooping - Expressiveness - Failure Tolerance + Recovery. Enrica Dente 15

Extensions Supported in Tuplespace Implementations • Known implementations support few extensions • Giga. Spaces

Extensions Supported in Tuplespace Implementations • Known implementations support few extensions • Giga. Spaces and TSpaces – – Self-Describing Tuples Flexible Typing (limited support) Tuple Expiration Query Registration • L 2 mbo – Flexible Typing – Tuple Expiration • LIME – – Registration At Most Once Ordering Modular Restartability Standard Routing Fields (limited support) Enrica Dente 16

Event Heap Extensions Source: http: //graphics. stanford. edu/papers/eheap 3/ • Event standard fields -User

Event Heap Extensions Source: http: //graphics. stanford. edu/papers/eheap 3/ • Event standard fields -User fields (Event. Type, Time. To. Live) -Routing fields (target and source fields) -Internal user fields (Session. ID, Sequence. Num, Event. Heap. Version) • Field structure: -Type -Name -Post Value -Template Value • Permitted values: - Actual - Formal - Virtual Figure 2: Example operation showing placed events, and using template events for matching - Auto-set, auto-set overrideable Enrica Dente 17

Summary • IWs require reusable, portable and robust software infrastructure • Need uniform, useful,

Summary • IWs require 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. Enrica Dente 18

Open Issues – Centralization reduces scalability (not suitable for the web) – Extensions support

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? Enrica Dente 19

Relevance to Semantic Web Services • Web Services are about coordination and integration: –

Relevance to Semantic 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. Enrica Dente 20

Deri Triplespace Computing Projects • D 21: Triplespace computing and WSMX – State of

Deri Triplespace Computing Projects • D 21: 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. Enrica Dente 21

References • [Fense, l 2004] DERI Research Report 2004 -05 -31, Triplebased Computing, http:

References • [Fense, l 2004] DERI Research Report 2004 -05 -31, Triplebased 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 Workspaces http: //graphics. stanford. edu/papers/eheap 3/ , 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 Enrica Dente 22