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.


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
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.
REST Core extension The REST extension lets users integrate external service implementations written in JavaScript or Python.


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 can contain a script, bind fields to parameters, and so on. Most properties are specific to a SPARKL extension.