Download TupleSpaces Revisited: Linda to TSpace

TupleSpaces Revisited:
Linda to TSpaces
Ben Y. Zhao
13 July, 1998
UC Berkeley
Computer Science Division
Overview
•
•
•
•
•
•
•
•
Linda / TupleSpace
C-Linda and Applications
JavaSpaces (Sun Microsystems)
TSpaces (IBM Almaden)
TSpaces vs. JavaSpaces
Integration with NINJA/ICEBERG
XML and TSpaces
Future directions
2
Linda and Tuplespace
• 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()
3
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)); }
4
Benefits of Linda
•
•
•
•
•
•
•
•
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
5
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
6
JavaSpaces (Sun Micro.)
•
•
•
•
•
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
7
JavaSpace Model
Identities
Client
read
write
Client
writeEvent
Transaction
write
take
notify
JavaSpace
write
JavaSpace
Event
Catcher
notify
JavaSpace
8
Key Features
•
•
•
•
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
9
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.
10
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
11
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
12
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
13
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)
14
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
15
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
16
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?
17
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?
18
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
19
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
20