Example Primitives for

Higher-Order Active Tuple Spaces (ATS)

This page has some ideas from last year which we have taken further now. Please see the other pages.

Most computing in the long-term future will be performed on top of a
Universal or Ubiquitous Computing Substrate (UCS). This is the ultimate
network PC. A number of predictions are that this substrate will consist
of a global, eternal active tuple space (ATS).

This web page gives an outline of a typical system as currently
envisaged. Please note that this is only one layer in the final
application systems. This layer is pasted as universal jam between the
Internet (or future evolution thereof) and major middleware functions,
such as asynchronous eventing or synchronous RPC. The middleware functions
will, in general, be far more strongly typed, but use localised or
application-specific type schemas. The ATS layer is the only component
with a global, eternal type schema and semantics.

Prior work on tuple spaces has emphasised the associative lookup
facilities, but these are not emphasised here. Most lookup will be on the
primary key (e.g. URI) and only rarely will associative lookup on
arbitrary fields be required.

We first define primitive operations for the active tuple space (ATS)
in terms of their operational semantics and then using a a number of
applications as examples, we show how to use them in real-time, under
simulated faster than real time execution and formal analysis.

ATS - Basic Design Decisions

A tuple space is a top-level universe consisting of named tuples. Each
tuple may contain further tuples, implying heirarchic naming overall. Each
tuple has a number of fields. XML is one possible representation. In an
active tuple space (ATS), certain of the fields of a tuple may contain
running software. The system is higher-order in that tuples can spawn
further tuples.

There are a number of possible flavours of ATS within this definition.
We make a number of basic design decisions to define our own flavour:

Every tuple has associated credit and when its credit runs out, the
tuple can be deleted by the substrate.

Creating a new tuple costs according to the initial credit provided
to the new tuple and the admin charges made by the hosting substrate
entity.

Every tuple has a unique name and address understood by the
substrate. The substrate primitively supports redirection to automate
the tracking of migrated tuples, but such operations inveitably cost
more.

There is no global type schema for tuple contents. Tuples must
explicitly or implicitly refer to their own schema.

The only datatypes are credit, date/time, tuple addresses/storage
locations and ASCII strings. The aggregating or abstract datatype is
the tuple itself. Consequently, all software in active tuples is
represented as strings, which is essentially normal practice anyway.

A tuple may only be accessed if its address is known. This gives
security. Tuples may have multiple, different addresses to provide a
capability system for restricted access to different operations or
revokable capabilities to different clients. The substrate defines a
restricted wildcard address resolution facility to provide associative
look-up without compromising security.

The primitive operations between active tuples and an active tuple
and the substrate are listed below.

Primitive Tuple Operations

The substrate models an attractive force that causes tuples to
encounter each other and can trigger method or function application. Under
the biotic matrix model, this represents the behaviour of catalysts and
enzymes. In addition, tuples can peform explicit operations on other
tuples.

The Pi Calculus and the Ambient Calculus are process algebras of
sufficient power to provide a useful ATS. However, the concepts of cost,
power and expiry are not natively implemented. Also, these slightly older
process calculi support rather abstract named and relative (respective)
addressing modes for peer-to-peer communication. To make a practical ATS,
we make various extensions and prescribe the addressing and powering
aspects. (Addressing has to relate to the Internet and powering has to
relate to money).

The internal operation of an active tuple is not a primary
architectural issue: it can be coded in any programming language or style.
Therefore, active tuples can vary in trustworthyness, from those that are
transparent in their behaviour (e.g. using obvious or proof-carrying
coding) to those that are opaque. Trust may also be widely interpreted
with respect to an authenticated signatorary system, as in 'this code was
signed at MS Redmond'. However, such trust is an overlay on the basic
architecture with no special primitives.

Power Supply

A major aspect of an eternal, global ATS is who pays for it. Using the
biotic matrix paradigm, we need to define and provide the heart, lungs,
kidneys and so on. The system is powered through the provision of
storage, network and process cycles.

In the fullness of time, all money and electronic funds transfer will
probably be handled within the ATS, but perhaps with a residual level of
shipping gold bars between corporations. But in the short term, we will
continue to see all large electronic fund transactions being carried out
by our current banking techniques and various systems for turning such
`hard cash' into credit to power the tuple space. The funding of the
mobile phone system by top-up of smart cards is a seeding scenario,
although currently, electronic cash is not widely transfered between
handsets etc..

Credit drain is through the substrate into the pockets of the substrate
providers (SPs). This is very natural. All decisions to spend credit will
ultimately originate from human actions, since no sane person ever
authorises anything that has an unlimited cost liability. Therefore,
energy supply in the form of credit injection will occur at any time a
person requires a service, perhaps paid in advance. For instance, to send
an email, an electronic stamp is required. (This wipes out spammers too,
so is a very good idea!). This stamp can be a tuple. Equally, a whole
financial service, such as an insurance company, can be a tuple.

There are two essential forms of electronic credit: both are suitable
for use. The first is a hard currency which can be exchanged for real
money at various places, whereas the second is a deterrent coinage,
which can be minted by servers that wish not to be subject to denial of
service attacks through excessive traffic. An example form of deterrent
currency is the `recognise characters' test implemented by certain web
search engines, but a more suitable version of this for peer-to-peer
computing is simply to issue credit in return for prime factorisation.

Address Format

Most active objects will refer to each other using local, dynamic or
relative addressing, but Internet/WWW style URIs will also be needed.

The Internet provides a valuable and almost inveitable infrastructure
for the global ATS. Therefore, absolute addresses will be built largely on
Internet URIs. However, intelligent, active, policy-driven NAT is bound to
have big consequence. Address translation and directory services will
eventually become the most strategic and important services, where new
policies and schemes can be applied to modify the behaviour of older
applications.

Advanced Reservation and Provisioning

An essential aspect of any system is availability. People will spend
money to have the required levels of service available at short notice
(e.g. I own a car and drive less than 500 miles a year). As well as
private ownership, the equivalent of today's networking VPN as an active
object substrate will therefore evolve: it has the advantage of easy
management. In principle, provision and reservation systems will provide a
less brutal mechanism for this, but its hard to say when they might be
successful.

Current Status

These ideas were written as a strawman middleware for the Pebbles
project, although currently the main project is using XML RPC directly at the API
without the active object layer. The ideas are now being developed separately
as shown on the accompanying web pages.