Configuration components

A SPARKL configuration - called a mix - handles interactions between services. It comprises a set of operations implemented by services, and fields of data sent from one operation to another. Related components are organised into folders.

Folders

A folder is a way of organizing a set of related SPARKL configuration components. A folder may contain other folders, as well as services, fields and operations.

Mix folders

A mix folder is a subtype of folder. Operations normally have to be defined inside a mix folder. At transaction runtime, SPARKL ignores operations that are not inside a mix folder.

In most cases, a SPARKL configuration has a single mix folder.

Complex configurations can include additional subroutine mixes.

The operations that are inside the same mix folder are used to generate a Sequencing Graph.

Services

Services are service end-points connected by SPARKL. They communicate with each other with the help of operations.

Depending on the SPARKL extension used to provision them, services can orchestrate transactions, contain scripts and so on.

When SPARKL starts a service at execution time, it starts an instance of that service.

Operations

The operations can be thought of as channels through which the services send data.

These channels are opened and closed on demand by the SPARKL® Sequencing Engine.

The operations never interact directly. SPARKL is always the intermediary.

The following four operation types are supported by SPARKL:

  • Notify
  • Solicit/response
  • Consume
  • Request/reply

Figure: SPARKL operations


As shown in Figure 1, each operation can be used by a service, or a client service;

  • To send output - fields of data - to the SPARKL® Sequencing Engine (green arrows)
  • To receive input - fields of data - from the SPARKL® Sequencing Engine (blue arrows)
  • To do both

When a service implements an operation, it results in a data event.

Fields

Fields are sent to and from operations. They either hold data of a pre-defined type, or are FLAGs - empty fields used only for sequencing purposes.

Table 1. Field types
Type Description
FLAG Default value if no other is taken.

The field serves only sequencing purposes.

integer The field can contain data of the type integer.
float The field can contain data of the type float.
string The field can contain data of the type string. These strings are Erlang character lists.
utf8 The field can carry a UTF-8 encoded string.
binary The field can contain data of the type binary.
boolean The field can contain data of the type boolean.
term Fields of type term can carry any Erlang data types including Erlang maps, tuples and lists.
json Fields of type json can carry JSON objects and other valid JSON terms.

When a transaction starts, SPARKL creates a field set and keeps adding fields to it until it can satisfy all goals in the transaction - or do nothing more with the fields it has.

Permissions

Permission grants give permission rights to a particular user or group of users.

The root of every user's configuration tree is the home folder of the user.

Users have full access to everything within their own home folder. By default, no one else has any access to another user's resources.

Access rights can be specified for every folder or mix folder. Access rights apply to all content inside the folder, unless they are overridden.

Permissions hierarchy

Access rights have priorities based on the closeness of the match and the level where they are specified. For example, you can specify access rights to a wider target group on the top level of the Navigation Tree panel and narrow it down on a lower level, or vice versa.

A user's rights are decided by the permission that has the highest priority. The priority is decided by:

  • The closeness of the match. For example, in the case of the user bar@foo.com, an exact match has higher priority than a match to users in the @foo.com domain.
  • The closeness to the subject. For example, if a user is exactly matched on two levels of the configuration tree, the grant closer to the subject takes precedence.

Figure: Permissions hierarchy

As shown in Figure 2:

  • admin@sparkl.com
    This user has full access to the Home folder.
    The grant on Folder1 does not apply to this user, as users default rights to their own home folder cannot be overridden.
  • bar@foo.com
    This user has read-only permission to Folder2 and all of its content.
    Since the grants on Mix2 and Subfolder2 match this user more closely, the user also has read and execute rights to Mix2, and full access to Subfolder2.
  • foo@foo.com
    This user has read-only permission to Folder2, and read and execute rights to Mix2.
    Since the grant on Subfolder1 matches this user exactly, the none permission on that folder takes higher priority, leaving foo@foo.com with no rights to Subfolder1.