TupleSpaces Revisited: Linda to TSpaces

Ben Y. Zhao13 July, 1998UC BerkeleyComputer 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

IdentitiesClient

Client

JavaSpace JavaSpace

JavaSpace

EventCatchertake

writenotify

write

writeEvent

notify

writeread

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 (www.jxml.com)

– TSpace service description vs. RDFs in XML

20

Further information

• TSpace examples and tutorials:– http://www.alphaWorks.ibm.com/examples/tspaces/

• Specifications on Java Leasing, Transactions, and Distributed Events:– http://java.sun.com/products/javaspaces/specs

• The Linda Project at Yale:– http://www.cs.yale.edu/HTML/YALE/CS/Linda/

linda.html

• Tuplespace used in scientific computing:– http://www.sca.com