Service

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

Example XML code Notes

<service 
  name="Expr" 
  provision="expr">
  <prop 
    name="expr.src" 
    content-type="text/x-erlang"><![CDATA[
    NextDiv = fun
      (2) -> 3;
      (Div) -> Div + 2
    end.
  ]]></prop>
</service>
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.

Attributes

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

name

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

provision

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.
phidget Optional extension The Phidget extension allows you to map Phidgets sensors, motors and interfaces to fields.

dependencies

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.

Children

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

prop

A property can contain a script, bind fields to parameters, and so on. Most properties are specific to a SPARKL extension.