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

Example XML code Notes

    NextDiv = fun
      (2) -> 3;
      (Div) -> Div + 2
Depending on the SPARKL extension you use to provision them, services can have many functions, such as orchestrating transactions, containing scripts, or reading sensors.
Note: The example is from a version of the Primes demo using the Expressions extension.


Services must have a name. The other attributes are optional.


The name of the component. Other components use this name to reference the component.


The SPARKL extension used for provisioning the service.

Table 1. Service provisioning with SPARKL extensions
Attribute value Core or optional Description
tabserver Core extension Services provisioned using the Tabserver extension run in your browser.

Services provisioned on Tabserver depend on a tabserver_connection service being up.

tabserver_connection Core extension Services provisioned using tabserver_connection accept connections from browsers.

Services provisioned using tabserver depend on such a service.

sequencer Core extension Services provisioned using the Sequencer extension can process transactions.
expr Core extension The Expressions extension supports the use of Erlang expressions in SPARKL.
subr Core extension The Subroutine extension supports subroutine transactions called by a caller operation.
Note: The subroutine specification is defined on the caller and callee operations on the svc_subr service.
lambda Core extension This service extension integrates AWS Lambda functionality into SPARKL mixes allowing you to run Node.js and Python scripts in a serverless architecture.
Note: See Lambda AWS documentation for further details.
phidget Optional extension The Phidget extension allows you to map Phidgets sensors, motors and interfaces to fields.


A space-separated list of one or more services. The service depends on these being up. Services that depend on each other execute in a common process.


The actual implementation of a service is defined in its properties. A service can take one or more properties as its children.


A property defined for the component. For example, a Python or Erlang script. Most properties are specific to a SPARKL extension.