2.3. Architecture: requirements

The software stack should be built from four high level components:

  1. a Perspectives Runtime (PR);

  2. a persistent store of information (Store);

  3. a user interface (UI);

  4. an authentication provider (AP).

2.3.1. Perspectives runtime

Please note that in this paragraph we discuss Perspectives runtime in terms of requirements, rather than the actual Perspectives Distributed Runtime that is the main topic of this technical documentation. See Actual architecture and underlying technologies for a first introduction of the actual system.

A runtime serves a number of functions:

  1. It provides answers to requests sent in by (a single instance of) the User Interface. There is a limited number of requests that is accepted, answered in terms of role instances, context instances and property values.

  2. It handles commands sent in by the UI. Again, the number of commands is very limited and allows the end user to add or remove role instances to contexts, to create and remove context instances, and to modify, add or remove property values. It also allows the user to bind some role to another.

  3. When we say the PR handles commands we mean that it ensures that subsequent requests reflect the changes ordained before. In practice, this means it stores contexts, roles and property values (or rather causes them to be stored, see Persistent store of information).

  4. For each elementary change effected by a command, it constructs one or more Deltas. A Delta is like a remote procedure call. It contains enough information for another PR to reproduce the change. Deltas are collected in Transactions. Transactions are sent to other PR installations.

  5. It handles incoming Transactions. After checking whether the sender is authorised to effect the change, each Delta is executed. This allows PR’s to synchronise their stored contexts, roles and property values.

All these are governed by one or more models that authorise user roles to perform some actions (and that includes requesting contexts, roles and property values through the ui). Models are written in the Perspectives Language.

A PR is not expected to be active at all times. Assuming so would simplify some aspects of the architecture.

2.3.2. Persistent store of information

The Store can be thought of as a list of all elementary changes sent in by a single end user, including endorsed changes sent to it by other end users. In practice, it will contain an accurate accumulation of all those changes. It does not allow ‘time travel’, that is, one cannot ask it to revert to a previous state.

It is important to realise that each Store will be updated by exactly one PR, just as a PR will be used by exactly one end user.

We consider the structure of the persistent form of contexts and roles to be internal, even though they are exchanged between PR and Store. This is because the Purescript data definitions are leading. The serialised forms derive from those data structures. The type of serialisation deployed is an implementation choice. Consequently, we only stipulate that these persistent forms are JSON.

Concretely, the store should

  1. Provide the ability to create named compartments to store items in;

  2. Be able to store and produce on request JSON documents in such a compartment;

  3. Be able to provide a list of the documents in a compartment

There is a number of self-evident desired non-functionals, such as reliability, lots of capacity, etc.

Performance is important in the sense that the PR will very frequently request documents and update them. To some extent this requirement is relaxed because the PR caches each document it has requested. This cache is transparent with respect to updates. User Interface

There are hardly requirements for the user interface other than in the most general of terms: it should enable a single end user to

  1. Enter requests and inspect the answers sent by the PR;

  2. Enter commands;

  3. Identify him- or herself to the PR.

A UI will often be a graphical UI presenting screens and forms. As of version v0.4.0 of Perspectives, a JavaScript proxy library is available through which a process can interface with the PR. Also, built on top of that, a ReactJS library of data containers is available that provides higher level abstractions to deal with the PR.

2.3.3. Authentication provider

The end user authenticates him- or herself through the UI to the PR. Currently, we have taken a very simple approach to authentication. The authentication provider is not a separate component. The required functionality is provided by the PR. User credentials are kept in the Store.

← Previous: About Perspectives | ↑ Up: Introduction to the PDR | ⌂ Home: Perspectives Technical Documentation | Next: Connections between components →