Specifying_Application_Architecture

Using a customized architecture grammar, the software designer specifies an application architecture using Srijan Architecture Language (SAL) (Step 3). He specifies computational services and interactions with other components. Computational services are fueled by sensors and storages (defined in the vocabulary). They process inputs data and take appropriate decisions by triggering actuators (defined in the vocabulary specification).

For the next step - Compiling architecture specification

Srijan Architecture Language (SAL)

In the following, we describe concepts provided using SAL.

Consume and Generate: These two concepts together define publish/subscribe interaction mode that provides subscribers with the ability to express their interest in an event, generated by a publisher, which matches their registered interest. A computational service represents the publish and subscribe using generate and consume concept respectively. We describe these two concepts in details as follows:

• Consume: It represents a set of subscriptions (or consumes) expressed by computational services to get event notifications generated by sensors defined in the vocabulary specification or other computational services defined in the architecture specification. A consume of a computational service is expressed using the consume keyword. The computational service expresses its interest by an event name. For instance, a computational service RoomAvgTemp, which calculates an average temperature of a room, subscribes its interest by expressing event name tempMeasurement illustrated in Listing 2, line 4.

• Generate: It represents a set of publications (or generates) that are produced by computational services. A generate of a computational service is expressed using the generate keyword. The computational service transforms data to be consumed by other computational services in accordance with the application needs. For instance, the computational service RoomAvgTemp consumes temperature measurements (i.e., tempMeasurement), calculates an average temperature of a room, and generates roomAvgTempMeasurement (Listing 2, lines 4-5) that is used by RoomController service (Listing 2, lines 7- 10).

Command: It is a set of commands, issued by a computational service to trigger actions provided by actuators. The software designer can pass arguments to a command depend on action signature provided by actuators. Moreover, he specifies a scope of command, which specifies a region where commands are issued. A command is specified using the command keyword. An example of command invocation is given in line 9 of Listing 2. The roomcontroller service (i.e., roomController), which regulates temperature, issues a SetTemp command with a preferred temperature as an argument (i.e., settemp) to heaters (Listing 1, line 15).

In-region and hops. To facilitate the scalable operations within an IoT application, devices should be grouped to form a cluster based on their spatial relationship (e.g., “devices are in room#1”).

SAL offers scope constructs to define both the (1) service placement and (2) its data interest. The service placement (defined using the in-region keyword) is used to govern a placement of computational service in a cluster. The service placement can be in regions defined in a vocabulary specification.

The data interest of a computational service is used to define a cluster from which the computational service wants to receive data. The data interest can be in regions defined in the vocabulary specification. It is defined using the hops keyword. The syntax of this keyword is hops: radius: unit of radius. radius is an integer value. The unit of radius is a cluster value. For example, if a computational service RoomAvgTemp deployed on Room number 12 has a data interest hops: i: Room, then it wants data from all rooms starting from 12-th room to (12+i)-th room, and all rooms starting from 12-th room to (12-i)-th room .