The coordination language Splice

The basic idea behind Splice [2] is that a process which consumes certain data need not know which process produces it. In fact, there may be several producers. The consumer simply registers its interest by subscribing to a certain data sort. Next it will be able to read produced data items of this sort, where it can use keys and queries to filter the data stream on certain aspects (e.g. in an air traffic management system, on flight number or distance to the airport). Similarly, the producers need not know the consumers of their data.

In the rest of this section we consider several examples of simple programs using read and write primitives. The intended meaning of these primitives will vary per example, but the basic intention is that ${\tt Write}(d)$ writes the value of $d$ to the dataspace(s) and ${\tt Read}(x, q)$ asks the dataspace a query $q$ and assigns the answer of the dataspace to its variable $x$.

Typical for the applications built with Splice is that it is often not needed to ensure that all data will be consumed or that it will be consumed in the order it is produced, since there is usually a continuous stream of data available from the sensor. Moreover, there are often no strong consistency requirements on processes that consume the same data.

Hence, Splice provides a simple but powerful coordination scheme that requires little overhead. Nothing is guaranteed about the speed or order at which data items of producers become available for consumers.

For instance, in the program

$$({\tt Write}(0) ~;~{\tt Write}(1)) ~\vert\vert~{\tt Read}(x,\mbox{\tt true})$$

where the `read' command has a $\mbox{\tt true}$ query - to be able to read all data elements, it is possible that the value $1$ is already available for the `read'-command, whereas the value $0$ cannot be read yet.

But if, for instance, ordered messages are needed, sequence numbers can be included in the data and the reader might read with a query on the next sequence number. It is also possible (and often done in practice) to include a time-stamp in the data sort and to express in the query that the data has a recent time-stamp.

Given this basic idea, there are a large number of possible variations, especially concerning the syntax and the semantics of the read operations. We list a number of questions:

1. Which queries can be formulated; a predicate on data items (e.g. ``a data item with time stamp greater than 10") or a predicate on the complete set of available data items (e.g. ``an available data item with maximal time stamp")?
2. Does the read operation return the set of all available data items that satisfy the query or just one item?
3. Does the read operation block if there is no item satisfying its query or is there an exception/error (or, e.g. the empty set in case a set is returned)?
4. Is the set of available data items the same for all consumers at any moment or can this be different?