The LighTS Tuple Space Frawework and its Customization for Context-Aware Applications
LighTS is a Java implementation of the tuple space concept proposed by the Linda model of communication. LighTS essentially provides:
In Linda, processes communicate through a shared tuple space that acts as a repository of elementary data structures---the
tuples. A tuple space is a multiset of tuples that can be accessed concurrently by several
processes. Each tuple is an ordered list of typed parameters, such as <"foo",9,27.5>, and contains the actual information being
Tuples are added to a tuple space by performing an out(t) operation on it. Tuples can be removed from a tuple space by executing in(p). Tuples are anonymous, thus their selection takes place through pattern matching on the tuple contents. The argument p is often called a template, and its fields contain either actuals or formals. Actuals are values; the parameters of the previous tuple are all actuals, while the last two parameters of <"foo", ?integer,?long> are formals. Formals are like "wild cards", and are matched against actuals when selecting a tuple from the tuple space. For instance, the template above matches the tuple defined earlier. If multiple tuples match a template, the one returned by in is selected non-deterministically and without being subject to any fairness constraint. Tuples can also be read from the tuple space using the rd operation. in and rd are blocking , i.e., if no matching tuple is available in the tuple space the process performing the operation is suspended until a matching tuple becomes available. A typical extension to this synchronous model is the provision of a pair of asynchronous primitives inp and rdp, called probes, that allow non-blocking access to the tuple space.
Some Java-based implementations of the Linda tuple space already exists, among which
IBM's TSpaces and Sun's JavaSpaces are probably the most known. Hence, the
question is why to create a separate package.
My motivations stems from the observation that available tuple space implementations, e.g., TSpaces and JavaSpaces, tend to provide a wealth of features, including persistence, security, remote access, transactions, and so on. In my projects, instead, I did not need these additional features, and/or I wanted to implement them with my own mechanisms. I ended up using only a fraction of the power these systems provide, thus wasting a lot of resources, obtaining lower performance, and being limited in my capability to extend the system itself---let apart license issues.
Instead, LighTS has exactly the characteristics I was looking for:
lights.extensionscontains some of the extensions I already found useful in my projects.
On the other hand, I did not want to completely prevent my applications from using the additional features of commercial tuple space implementations, as they become handy in some situations. Hence, I provided an adaptation layer that has the same interface of the tuple space implementation provided in LighTS but allows for loading different implementations of the adapters at startup, each converting the operations provided by the LighTS interface into those of other tuple space implementations.
LighTS is made of several separate packages:
lights. Contains the lightweight implementation of the Linda tuple space.
lights.interfaces. Defines a set of interfaces to represent Linda's tuples and tuple spaces. This interfaces are implemented by the implementation in the lights package as well as by those in the adapter layer.
lights.adapters.Defines the adapter layer that allows for independence of the underlying runtime support.
lights.adapters.builtin.The adapter for the built-in tuple space implementation contained in the
lights.adapters.tspaces.An adapter for TSpaces 2.1.1.