Target of this section is to provide a high level description of the core concepts behind the Atooma environment. Focus will be on Modules and their inner structure, with emphasis on how they can be used for building Rules to be executed.
Modules are sets of related functions packed into self-consistent software units, that are used for creating and executing rules. For example, SMS
module includes functionalities for receiving, sending and managing messages, while WiFi
module allows to control device WiFi features.
Some modules may be not available on all devices. For example, if device lacks of NFC
hardware, the corresponding module won’t be shown and, as a consequence, all rules including NFC
module won’t be executed.
Each module defines a set of components among the following: Value Type , Trigger , Condition Checker and Performer. All of them are described more in details in the following sections.
Value Type are components defining data types managed by the module. STRING
, BOOLEAN
, NUMBER
and DATE
are examples of basic value types defined in CORE
module. Regardless of their internal representation, all value types must have a serialized format, allowing them to be exchanged as byte sequences, through a convention that must be specified by the value type definition itself.
Triggers are rule activators. They are in charge of executing rules when specific events occur.
Each trigger can include parameters, allowing to configure rule activation in some conditions only. For example, SMS
module defines a trigger INCOMING
that is activated when an SMS
is received. It’s possible to filter events by monitoring only messages coming from a specific sender.
When activated, a trigger can inject values into the rule exectution context. For example INCOMING
trigger of SMS
module provides a set of information like message content, sender and so on.
Condition Checkers are boolean functions accepting one or more parameters. They are used in conditional part of the rule for checking values. One example for WiFi
module is CONNECTED
, that returns true if device is connected to WiFi
with SSID name specified as parameter.
Performers are components executing actions. For example, Facebook
module has a performer POST_ON_WALL
, allowing to post a message provided in input on a friend’s wall. Also performers can inject values into the rule execution context. Purpose is making such data avilable for the following performers.
Note
Rule performers are not executed in parallel. They are treated as a pipeline. That’s why each element can receive parameters in input and produce parameters in output.
Rules are programs defining actions to execute when a specific event occurs, according to an if-do paradigm where if part is made by one trigger and contains up to four condition checkers, while do part contains up to five perfomers.
In practice, if-do parts are contained in what is defined as rule body.
In addition to body, all rules include a header, declaring all basic rule information:
Following sections provide advanced details on the structure of Trigger, Condition Checker and Performer definitions.
Trigger definition provides the configuration for the rule trigger. It includes three elements:
Note
Since rules are activated by triggers it’s essential for them to define it.
Condition checker definition provides the configuration for a condition to be verified within the execution context of the rule after trigger activation. It includes four elements:
NOT
operator).Note
A rule can have up to four condition checkers, to be verified according to their declaration order. As soon as a condition evaluation returns false, the rule execution is interrupted. As a result, all subsequent conditions won’t be evaluated and performers won’t be executed.
Performer definition provides the configuration for a performer to be executed in case trigger is activated and all conditions are verified. It includes three elements:
Note
All rules must include at least one performer.
Defining trigger, condition checkers and performers may often require to use parameters, each one including an identifier and a value type.
There are four possible value sources for parameters:
Of course depending on component, only some parameter sources can be used:
On top of Rules Engine, Resonance SDK comes with a set of API allowing to determine user attitudes and providing to developers suitable functions for retrieving interesting user-related data.
By analyzing data coming from user devices (from smartphones to connected wearables), Resonance SDK is able to answer to questions like:
... and much more.
Resonance subsystem for Data Analysis is made of three main functional blocks:
Resonance Data Collector is the most important functional block for Data Analysis, having following responsibilities: