Alan N. Shapiro, Technologist and Futurist

The hypothetical time traveler whom Michael Stal wrote about in his 2006 article “From the Future” would be disappointed to learn that “prehistoric computer science,” as the temporal traveler termed it, has not changed much as of 2011, five years down the road.¹ Market analysts and IT experts still report that only about 20 percent of all software development projects reach a successful conclusion. The remaining 80 percent of projects overrun their budgets, go on longer than expected, do not implement all desired functional requirements, or are prematurely terminated out of frustration. We are still faced with the burning question: how can software more effectively be made?

One possible answer has been suggested by software developers in the “Object Spaces” (also called simply “Spaces”) community. According to Wikipedia, Object Spaces is a paradigm for distributed computing and “global” (system-wide) object coordination.² Our view is that Object Spaces is the start of the right road towards making a qualitative revolution in computer science: a major upgrade in how software is made, and in the power of what it can do. Improving the overall situation of software development will be made possible through adapting an Object Spaces approach which can be described as holistic, since it takes on infrastructural challenges with an application-centered unified programming paradigm.

Yale University computer science professor David Gelernter, with his tuple space coordination model, is regarded as being the originator of Object Spaces. In mathematics and computer science, a tuple is an ordered list of elements. In a “Tuple Space,” a repository of tuples is accessed concurrently by many processes. A Tuple Space is an example of an Object Space. Together with Yale University colleague Nicholas Carriero, Gelernter laid the foundations of the Tuple and Object Space paradigms in the late 1980s with the development of the Linda programming language. The importance of the approach was already recognized back then, but it is only recently that large-scale implementations of Object Spaces in production software systems have begun.

In our view, the potentially wide-ranging impact of Object Spaces has been deferred in time due to a somewhat narrow (and hopefully temporary) channeling of the paradigm into the two technologies of “Grid Computing” and JavaSpaces. Josef Ottinger, a proponent of the movement of Grid Computing, defines Object Spaces as the setting up of a sort of memory map for Client/Server applications: a network or Grid in which data resides that can be read and written.³ The Sun Microsystems technology known as JavaSpaces has also tried to implement a Spaces concept. JavaSpaces uses an infrastructure called “Distributed Virtual Shared Memory.” The dimension of distribution is added to shared memory. As the Wikipedia article on the subject states, JavaSpaces provides a “distributed object exchange and coordination mechanism (which may or may not be persistent) for Java objects.”⁴ JavaSpaces is a part of the Java Jini technologies for distributed systems. Jini has not been a commercial success. Chief Jini architect Bill Joy has attributed this failure in part to the fact that the dream of distributed systems will require a “quantum leap in thinking.”⁵

In his groundbreaking book Mirror Worlds (1992), David Gelernter explains that Mirror Worlds (a higher-level term related to Object Spaces) are software ensembles, “glued-together out of many separate programs all chattering at once.” An ensemble is “a group of objects that interact; a group, accordingly, that is more than the sum of its parts.”⁶ Asynchronous ensembles are the critical technology for the realisation of Gelernter’s dream of Mirror Worlds. On the application level, Mirror Worlds are information-intensive software models monitoring and reflecting the reality of some large institution like a hospital, city, or corporation. Gelernter’s dream has arguably now already been partially realized in social software applications like Facebook.

On the technological computer science level, the emphasis in Object Spaces is on the communication and coordination among various running programs. This is fundamentally different from what the conventional emphasis in computer programming has almost always been: the individual processes themselves. Beyond the functional-procedural paradigm of the program as executing a sequence of instructions (languages like Pascal and C), beyond the object-oriented paradigm of the unity of data and code in software objects (languages like Java and C++), a software ensemble – as envisioned by Gelernter – coordinates the simultaneous activities of many independently operating software agents, and furnishes an environment where these agents can receptively obtain real-time systemic information in a way that advances their autonomous intelligence. “Coordinated programs are the future of computer science.”⁷ Objects acquire even more power as object-orientation is taken a significant step further.

Object Spaces add major new design and deployment patterns to the infrastructure of a running system, and to the business application. Similar to time travelers of the future who will need a decoupling of space, time, and Newtonian geo-physical referentiality to embark on their history rewriting adventures, software agents in Object Spaces will have such a decoupling – in principles of software design and engineering put into practice in the very near future – and the freedom that goes with it. An application-side “Blackboard” communication is the basis of this. Software agents get their own space in which to write and log their data. Other programs which have registered an interest in this information receive notifications and can read from the commonly shared Object Space as they like.

Any interaction in an Object Space software system has a triadic structure which has a strong affinity with the core concept of the original semiotics of Charles Sanders Peirce. Peirce was a nineteenth-century “American pragmatist” who is indisputably the most important figure in the history of semiotics. Peirce’s idea of the triadic sign relation occasioned the definition of semiosis as an “action or influence, which is, or involves, a cooperation of three subjects, such as a sign, its object, and its interpretant, this tri-relative influence not being in any way resolvable into actions between pairs.”⁸ The representations of an object operates as a sign, and meaning emerges from the triadic relation among sign, object, and interpretant. Every human thought is a sign, the mediation between an object and an idea. Reasoning or cognition is the interpretation of signs.

The triadic relationship – as opposed to any diadic relationship between a sign and an object, or an object and an interpretant – is the breakthrough to a new paradigm in computer science. A nineteenth-century seminal idea is already two centuries ahead of the seventeenth-century ideas of René Descartes and Francis Bacon on which existing computer science is based. Meaning emanates and flows from the “thirdness” of a genuine triadic relationship. There is also an echo here of something from the psychoanalysis of Jacques Lacan: the third participant provides a mirror illuminating the reality of the relationship between the first and the second peers. Concepts from the humanities lead to a qualitative upgrade in computer science.

In Object Spaces software systems, peers communicate with each other:

- without directly knowing anythng about each other (reference decoupling)

- without being located on the same physical machine (space decoupling)

- without any agreement in scheduling (time decoupling)

This decoupling in all three degrees of freedom is an ideal situation from the perspective of component and application designers. The less the linkages and rigid dependencies, the better for the software development project in terms of development costs, debugging effort, and the reusability of software code.

Another decisive point is the implicitly held coordination among processes. A program asks for information about another process by creating a Request Object within the shared Space. The Request Object generates a Message in another location. After the second process has carried out a certain action, an appropriate Reply to the Message is posted in the Space. If a Reply is not yet available, then the Agent responsible waits for its arrival. This is called “blocking” (not returning the result, or news that there is no result, immediately). The software developer is spared dealing in a painstaking way with the usual workflow issues.

It is a given that sequential processes will always be a part of software development. Nothing that is of utility and value is going to go away or be thrown away. But processes will become secondary. The emphasis on communication and coordination will simplify many aspects of the design and implementation of systems. Most everything can be accomplished by writing into and reading out of the Object Space. It does not matter if a single Agent, or hundreds of Agents, is/are waiting for the arrival of the Message. Complexity for the developer does not increase as a function of the number of participants.

A convergence of three design/implementation technology projects will later take place: the Object Spaces API (Application Programming Interface), quantum computing in software, and the radicalization of the object-oriented software development paradigm in the direction of “power to the objects.”

And lots of support will come from the community of humanities scholars who earlier brought forward the project of “the deconstruction of the power of the subject” (French theory, Varela and Maturana’s “The Embodied Mind”, Lacanian psychoanalysis, third-wave cybernetics, feminism, postcolonial studies, queer studies, etc.) without ever having become aware for even a single instant of the now obvious fact that computer science is an eminently subject-centered field of knowledge crying out to be revolutionized in the direction of “power to the objects.”

In the design of the Object Spaces API, developers will strive to achieve a radical simplicity and clarity. The API will essentially consist of three methods and an extra module: write, read, read-and-simultaneous-delete (take), and the Event Handler. The Event Handler handles the arrival of incoming Messages, and the initialization of processes which they trigger.

The following three techniques make up the essentials of the Object Space-based programming paradigm:

- Template Matching: A read operation provides a template (an instance of an object passed). Object attributes that have not been initialized are to act as wild cards. Specific attribute values constrain and determine in this way the returned result. The attribute values can be easily and flexibly navigated in an Object Graph.

- Leases: A lease time specifies an expiration time, thus limiting the lifecycle of an object in the Space. The responsibility to delete objects from the Space in order to conserve resources is delegated to the Object Space Engine. Leases has already been implemented as part of the Sun Microsystems Jini technology.

- Timeouts: They are, of course, common to many systems. They are important in our context because they support the workflow of the Object Spaces API. A Communications Object can be made to wait on the arrival of a certain Event Object. If many “Subscriber” participants wait on an event that was generated by one individual “Publisher” participant, this is called the Master / Worker design pattern. The Master hands out tasks to the Object Space, and these are read, processed, and written back to the Object Space by the workers.

Here are some additional programming features of the Object Space, and what they correspond to in traditional software technologies:

+ Write-Take: corresponds to Parallel Processing (Remote Procedure Call)
+ Read-Write: corresponds to Caching (Put, Get)

+ Write + Notify: corresponds to Messaging (Publish, Subscribe), Distributed Virtual Shared Memory
Two keywords – In-Memory and Replication – play a crucial role in the design of how the Space Engine creates the appearance of a distributed, shared memory.

A time traveler in an Object Space-based universe would exist logically only once, but physically in several locations. The Object Space ensures that the application physically recognizes each object as a singularity. However, it stores the object in a distrbuted way across a network or on multiple computers. Although this sounds simple, it is very difficult to implement in practice, since an application must use resources economically, and it cannot distribute all objects to all users (nodes). Replication protocols must be “intelligent” and propagate or partition objects depending on their use. That is, an object is explicitly to be replicated only for one node, if it actually consumes its data. An Object Space Cluster is “application aware,” and not merely a technical infrastructural mechanism. This is a significant departure from traditional clustering approaches in networking. Clustering techniques usually attempt to achieve a virtualisation of resources in a transparent way.

Skeptics sometimes complain that an Object Space-based system does not scale when many computers are involved, and many software clients try to access the same object simultaneously (change locking mechanisms are known to be very expensive). One solution to this for Space systems is not to introduce any locking mechanism in a “pessimistic” way, but rather to implement “optimistic” locking with an internal version counter. In optimistic locking, if a conflict occurs among different software clients trying to lock the same object, the second client still obtains information from the failed write operation.

The Object Space Engine works internally with what is known in the database world as the Primary-Copy method. In this procedure, only one object (the Primary Copy) must be modified in a write operation. All other replica objects are updated synchronously after the conclusion of the transaction. The time during which the writing client blocks on the transaction is minimal (with the compromise that the tailoring of the replica object is postponed). This prevents a bottleneck from occurring. The storing of primary copies of singular objects takes place at different nodes. What is created is a “virtual server” that does not institute any centralized control, and instead practices a peer-to-peer virtualisation. In the application design of this very application-friendly technology, several logical Spaces (hence the plural in the name “Spaces”) are addressed, resulting in an additional segmentation that makes the efficient handling of distributed transactions much more feasible.

Efficient database transaction logs are an important topic of research in computer science, generally considered to be a Holy Grail of the practical-spiritual journey of the software developer. “A transaction log (also database log or binary log) is a history of actions executed by a database management system to guarantee ACID properties over crashes or hardware failures. In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties that guarantee database transactions are processed reliably.”⁹

The question of “levels of abstraction” is very related to the quest for truly efficient database transaction logs. Much has been learned in recent years about levels of abstraction in software systems design. In his article “Laws of Leaky Abstractions,” Joel Spolsky coined the term “leaky abstraction.” “All non-trivial abstractions,” writes Spolsky, “to some degree, are leaky.”¹⁰ Here we hear an echo of Kurt Gödel’s two Incompleteness Theorems (especially the second one, first published in 1931). According to Alexis Clancy, this mathematically proven Theorem (pertaining to second order logic, i.e., the logic of types), can be paraphrased as follows: No matter how sophisticated a logic “machine” is, if it is founded on strict axioms, there will always exist, somewhere in the universe, a statement that will “break” the machine, i.e., an unprovable statement, a paradigm smasher.¹¹

Thanks to researchers like Spolsky, some software developers are now aware of a trade-off game of Performance vs. Functionality/Comfort. They proceed willingly by means of a compromise in which the problem is explicitly considered in the building of the system. They no longer try to tough out the bad compromise – by any means necessary – of abstracting in relation to the above-mentioned issue of “concurrent write resolution.” In an Object Space-based system, the entire configuration shifts to reflect this scheme undertaken with awareness. The system designer informs the Object Space about different requirements in different application circumstances in an explicit and declarative way. He or she can, for example, distinguish among the effects of write-most and read-most objects. Different implementations of the Space Engine will deliver specific optimal results for different application domains.

To achieve transactional security, storage is not done on the hard drive or in the database. Data rather remains memory-resident in other replicated nodes. In the case of system failure, the Object Space Engine knows about the redundant data in other data locations and can preserve the overall consistency (the strategy of in-memory fail-over).

In the radicalized distributed application scenario, which the IT research and advisory firm Gartner Inc. has termed XTP (Extreme Transaction Processing), data is made available at different sites, and an asynchonous communication is established between Space Engine and database. There is an advance to new performance levels thanks to the intensified availability scaling afforded by the new Space-based architecture.

Typically, a higher abstraction level is only achieved through the addition of a new software layer. This does not really reduce the complexity of software development, but merely displaces it. In an Object Space-based architecture, an actual reduction in complexity occurs (or rather, it is a “deconstructionist-Buddhist-quantum” architecture where simplicity and complexity are not in contradiction to each other). By merging the communication, coordination, and replication mechanisms, one achieves what can almost be described as the occurrence of a “technological singularity.” There is a folding problem space, similar to what Gilles Deleuze wrote about in The Fold, his book on the philosopher Leibniz. ¹² The same infrastructure enables parallel processing and concurrency on both single processor computers and across networks.

A new (technical) architectural design paradigm with these features:

Stateful Programming: Traditional distributed systems have followed the principles of stateless programming. In that scenario, an application handles each query or request independently from previous ones. There is no memory or recording of a state. The Object Space is stateful, and creates the illusion of a single (virtual) machine.

Deferred Execution: A Space-based system processes all calls asynchronously. This opens up completely new opportunities in temporal processing and in the prioritization of tasks. Opportunities for delegation and decoupling multiply. It becomes much easier to keep response times for an initial response to an event low, with additional tasks running simultaneously parallel in the background (for example with the deployment of Ajax).

Agent-Based: In general, agents are fine-grained components which have their own lifecycle, and they perform specific tasks. Due to the asynchronous and decoupled architecture of the Space based-system, each component in the system “mutates” into an agent. The application becomes a flexible “collection” of services (service orchestration). Components can be tested in a highly decoupled environment. All agents run entirely asynchronously, and their execution occurs in parallel.

Monitoring: The message-based communications and coordination in a Spaces system provide the developer at the application level with transparent introspection into the current process without negatively affecting the total performance. Monitoring and controlling at the application level comprise an additional special agent.

Scaling: All aspects of and responsibilities for scaling and distribution are removed from the application code, and are moved to the configuration of the Space. This includes performance, as well as availability scaling. Multi-core systems, which are often supported in currently existing middleware by explicit multi-threaded programming, are set up declaratively with .ini and .cfg files, and according to the parameter semantics of a 5GL programming language.

If the time traveler would do a reality check in 2011, and s/he stumbled upon the first Space-based systems that are in production in large companies, s/he would make surprising discoveries. In most cases, applications are up and running whose complexity significantly exceeds the possibilities of the established Application Servers on the market. These Application Servers work with separate clustering for the application, data, and message layers, and a separate module for parallel arithmetic.

Discussion of Spaces in the computer industry press focuses almost exclusively on the topic of Grid computing. There is little mention of a broader environment, the possibility that the Spaces approach responds directly to the challenges of the problems of software engineering in general. Some space-based techniques and programming patterns have been gradually and incrementally accepted and adapted into established Applications Servers. But the promise of the many advantages that Object Space technology has to offer can only be realized with a holistic vision.

Will time travel be required to initiate a new beginning? No, this is not necessary. Quantum leaps are already possible, available in the here and now by merging computer science with other academic fields of knowledge. The triadic structure of the sign, as conceptualised by Charles Sanders Peirce, will upgrade Spaces into what might be called Triple Spaces. The entire middleware industry is focused on a cautious and incremental approach. Our approach  – the interdisciplinary approach of bringing in ideas from the sciences and the humanities – from mathematics, semiotics, philosophy, art, sociology, biology, linguistics – will bring about a revolution in computer science to systems of great financial and human value. We may look like the underdogs now, but I, Alan Neil Shapiro, guarantee a great upset victory, just like Joe Namath guaranteed victory by the New York Jets over the 19-point favorite Baltimore Colts during the two weeks leading up to Super Bowl III on January 12, 1969.

NOTES

1 – Michael Stal, “Aus der Zukunft; Auf dem Weg zu besserer Software”.

2 – Wikipedia article on Tuple Space and Object Spaces.

6 – David Gelernter, Mirror Worlds: The Day Software Put the Universe in a Shoebox… How It Will Happen and What it Will Mean (New York: Oxford University Press, 1992).

7 – Ibid.

8 – Charles Sanders Peirce, The Essential Philosophical Writings, Volume 2 (1893 – 1913) (edited by the Peirce Edition Project) (Bloomington, IN: Indiana University Press, 1998); p. 411.

9 – Wikipedia article on Transaction Log.