TupleSpaces Revisited: Linda to TSpaces Ben Y. Zhao 13 July, 1998 UC Berkeley Computer Science Division

2 Linda / TupleSpace C-Linda and Applications JavaSpaces (Sun Microsystems) TSpaces (IBM Almaden) TSpaces vs. JavaSpaces Integration with NINJA/ICEBERG XML and TSpaces Future directions Overview

3 Parallel coordination language Virtual shared memory system on heterogeneous networks Associative addressing through efficient hashing Simple language primitives allow minimal code rewriting: –Tuple = basic element, list of literals and vars –In(), Out() moves “tuples” to/from T.S. –Eval() spawns processes in Tuplespace –Rd() does non-destructive reads in T.S. –Inp(), Rdp() are non-blocking versions of In() and Rd() Linda and Tuplespace

4 Linda-App Examples Implementing Semaphores: –P() { out(“sem”); } V() { in(“sem”); } Master-Worker Program –master() { for (i=1;i<=workers;i++) eval(“worker”, worker()); for (i=0;work exists;i++) out (“task”, taskify(work)); while (i>0) { if ((inp(“done”,?(Int *)ans)) !=0) { printf(“%d “,ans); i--; } –worker() { while (1) { in(“task”,?(Char *)task; out(“done”, dotask(task)); }

5 Portability (supports heterogeneous networks) Scalability Dynamic load balancing Anonymous and asychronous communication Associative addressing / pattern matching Data persistence independent of creator Simple API --> less and easier coding Ease of code transformation Benefits of Linda

6 Linda Limitations High system overhead Designed as a parallel computing model, primarily for LANs –lack of security model –lack of transactional semantics Language specific implementation Blocking calls, but no notification mechanism

7 Lightweight infrastructure for network applications Distributed functionality implemented through RMI Entries written to/from JavaSpace with “write, read” “notify” notifies client of incoming entries w/ timeout Pattern Matching done to templates with class type comparisons, no comparison of literals. Transaction mechanism with a two phase commit model Entries are written with a “lease,” so limited persistence with time-outs JavaSpaces (Sun Micro.)

8 JavaSpace Model Identities Client JavaSpace Event Catcher take write notify write writeEvent notify write read Transaction

9 All entry fields are strongly typed for matching Object model associates behavior with entries Matches can return subtypes of template types Entries are “leased”; persistence is subject on renewal in order to reduce garbage after failures Multiple JavaSpaces cooperate, and transactions span multiple spaces. Partitions provide minimal protection. “Eval” functionality is not supported, in order to reduce complexity and overhead Transaction model preserves ACID properties Key Features

10 JavaSpace Mechanisms Each JavaSpace server exports an object that implements the JS interface locally on the client, and communicates through an implementation specific interface Objects are stored as implementation specific representations, with the serialized class and fields Templates match entries if each field in template is either null or match the entry field via MarshalledObject.equals. This occurs when the serialized forms of the objects match exactly.

11 JavaSpace Limitations Simplicity of or lack of security model Transactions required for reliable entry reads Java RMI = performance bottleneck? High overhead from repetitious object serialization Currently only a specification exists, but no implementation

12 TSpaces (IBM Almaden) A set of network communication buffers that work primarily as a global lightweight database system or data repository Operators include blocking and non-blocking versions of read and take, write, set operators scan and count, and synchronization operator Rhonda Interfaces with data management layer to provide persistent storage and data indexing and query. Dynamically modifiable behavior

13 Key Features Database indexing and arbitrary “match, index, and, or” queries Transaction layer for data consistency Matching available on simple types New operators can be downloaded to TSpace and used immediately User and group permissions can be set on a Tuplespace and operator basis Event register informs clients of events HTTP server interface for debugging and maintenance purposes Support for large objects through URL reference

14 TSpace Applications Goal: To provide a common platform for linking all system and application services Printing services example: –heterogeneous machines search in set of TSpaces for a print server of the desired type. –Jobs are then “written” as tuples to the local TSpace. –Printer client “takes” tuples off local TSpace to process Collaboration services: –whiteboard: single or multiple clients “write” changes in tuples to one TSpace while all clients “read” tuples –video/audio conferencing: discretize multimedia stream into tuples, and “read” or “taken” via central TSpace TCP/SLIP Proxy for thin-clients (PalmPilot)

15 TSpaces vs. JavaSpaces Simple types and objects as tuple fields No replication, 1 server per TSpace Access Control Lists on users and groups Event Register invoked on all events Database indexing and range queries Downloadable operators Only serializable objects allowed Servers can be replicated across nodes Protective partitioning using multiple JSpaces Notify () is only invoked for committed writes

16 TSpace + NINJA/ICEBERG? Implement ISpace as a layer above TSpaces, using TSpaces for persistent storage and data consistency Path creation: –Specify Operator input and output types as tuples –Path creation agent uses queries to create desired IO path Service discovery: –services export interfaces and properties (i.e. “color,” “postscript,” “room 384”) as tuples to an interface storage TSpace –SDS works by making database queries to find matching interfaces or properties

17 XML and TSpaces What is the optimal model for leveraging TSpace functionality while keeping XML descriptive features? Composing XML into TSpaces tuples: –Service interface description written in XML –Encapsulated as individual fields in service description tuples –Will we lose the XML flexibility with encapsulation? Use XML as query specifiers –TSpaces can parse XML documents, and form intelligent queries as a result, replacing missing fields with wildcards Is there a better solution?

18 Limitations and Future Work Lack of scalability –modify TSpaces to span multiple nodes –necessary if we want to migrate services across nodes Limited availability / fault-tolerance –add redundant TSpace replication and/or logging/backup systems Will performance be an issue? –If so, is it inherent in the model? –Is Tspaces too heavy for active routers? What is the caching model? –How do we implement a cache model within TSpaces to retrieve optimized paths?

19 Future Work cont… Incremental performance: –can we modify TSpaces to get allow for performance knob? Queries can be non-optimal, yet give high performance Queries can be high latency, yet return optimal results Functionality: is there anything we can’t do? Consider alternatives: –TSpace communication vs. COINS model ( –TSpace service description vs. RDFs in XML

20 Further information TSpace examples and tutorials: – Specifications on Java Leasing, Transactions, and Distributed Events: – The Linda Project at Yale: – Tuplespace used in scientific computing: –