5 Tuple architecture
The final approach to developing distributed systems is based on a radical view of such systems. The approach is based on work carried out by two American academics, Nicolas Carriero and David Gelerntner. These two academics developed a language known as Linda in the 1980s. The language, and its associated technology, has always been thought of highly by other academics within the distributed systems area, but has never taken off in terms of commercial use. However, in the late 1990s Sun developed a version of the Linda technology as part of its JINI programme. This programme has, as its main aim, the interfacing of disparate technologies into a distributed system: JINI envisages hardware such as burglar alarms, coffee machines, refrigerators, video recorders and mobile phones being seamlessly integrated into distributed systems using uniform interfaces.
The part of JINI which has been inspired by Linda is known as JavaSpaces. It views a distributed system as consisting of one or more spaces each of which contains objects that can be read from or written to. This is shown in Figure 6.
A distributed system can consist of a number of spaces which do not have to be allocated individually to each computer on a network: the spaces could be shared by a number of computers.
In Figure 6 the distributed system is split up into three areas; each of these is known as a space. A space is a persistent object store in which objects exist; theoretically they can exist forever. Clients can access these spaces using three operations. They are:
Write. Clients can write new objects to a space.
Read. Clients can read an object's contents from a space.
Take. Clients can read an object from a space and remove it completely from the space.
There are a number of important points to make about JavaSpaces technology. The first is that data can be held in a space permanently; in effect this makes JavaSpaces a rudimentary implementation of a distributed persistent object store.
The second point is that spaces are shared: client objects can access the same space concurrently. Concurrent access to shared objects brings with it a number of advantages, but also some rather tricky programming problems. A major advantage of JavaSpaces technology is that many of these programming problems are hidden under the bonnet and the programmer does not have to worry about them.
The third point that is worth making about JavaSpaces is that the objects stored in a space are associative. This means that they are retrieved using some unique attribute or sets of attributes. For example, if the objects were credit cards then they would be retrieved using the unique credit card number associated with each card. Programming using JavaSpaces involves using associative lookup, where a key is used to read, take or write to an object stored in a space. The effect of this is that the JavaSpaces API is very simple consisting of a very small number of methods. The consequence of this is that using a JavaSpaces system, while still challenging, tends to be a lot easier than developing a system using more complicated technologies.
A fourth point to make about this technology is that it is transactionally secure. All that is necessary to say here is that a transaction is a set of operations which are applied to a state (usually some data stored in a database). For example, a transaction in a retail e-commerce system might consist of changes to a sales database, stock database and a credit card transaction database. The key idea about a transaction is that it either succeeds, or totally fails in that none of its operations will succeed if a problem occurs during its execution. When a technology enforces this property then it is known as transactionally secure. The implication here is that the programmer does not have to write complicated code to ensure this property every time a transaction is executed. In JavaSpaces transactions are supported on a single space or over a number of spaces.
The main disadvantage of a tuple-space-based approach is that it is somewhat inefficient compared, for example, with a message passing architecture. In gaining conceptual simplicity it has lost performance.