next up previous
Next: Examples of non-equivalent variations Up: Introduction Previous: The coordination language Splice

The goal of this work

The last question above addresses an important point; conceptually Splice can be seen as a large global dataspace, where producers write data items and subscribers can select items to read, see figure 1.

Figure 1: Processes communicating via a global dataspace.
\begin{figure}
\centering \epsfig{file=global.eps,height=4cm} \end{figure}

However, in a distributed implementation each process has a local dataspace with its locally available items, see figure 2.

Figure 2: Processes communicating via local dataspaces.
\begin{figure}
\centering \epsfig{file=local.eps, height=4cm} \end{figure}

Then, a write action is non-atomically distributed to all local dataspaces (as is done in the current distributed implementation of Splice); consequently the order of the updates at local dataspaces might be different.

Often there is a large stack of protocols to guarantee consistency of the local dataspaces. A design choice of Splice is to avoid these consistency protocols by carefully designing syntax and semantics such that the conceptual model of a single global dataspace can be implemented by distributed local dataspaces without much overhead.

The aim of our work is to formalize these ideas, that is, to define a simple but powerful Splice language with a denotational semantics based on a global dataspace and to prove that this semantics is equivalent to an interpretation with distributed local dataspaces.


next up previous
Next: Examples of non-equivalent variations Up: Introduction Previous: The coordination language Splice
Roel Bloo 1999-11-26