Architecture of the Application and Services solution.

The following figure show the components that perform the functionalities of the interoperability solution. It also presents the communication that exists between these components.

Service Catalogue and Service Discovery are in charge of storing and managing the information and description of the services available on IoT Platforms. To interact with these components, we have the modules that are part of the Graphical Environment (GUI): Modeller and Register Client. The Register Client provides users a tool to register new native IoT platform services and new composite services (also known as subflows). During the registration of one of these elements, it is possible to add a description about its features. Once the registration of the service occurs, it will be stored in the Service Catalogue.

The Modeller is a graphical environment that has access to the services which have been registered (using the Service Discovery module, through which it calls the Service Catalogue) and internal functions to execute a particular process (for example, functions to perform transformations in the data resulting from the execution of a service, to display information, to determine a timeout between calls, to repeat a call to a service ‘x’ number of times…). With this tool the AS2AS users can design a solution based on the composition of services. The visual editor lets user drag and drop the services (visually represented as nodes) onto the design surface and then join them together by dragging lines between them. A solution based on Flow Based Programing will be designed.

Once the design made by the Modeller is validated, the generated flow is stored in the Flow Repository. This component manages the information of all flows created. The Orchestrator is the engine of the solution. It is responsible for loading the flows created with the Modeller and stored in the Flow Repository. Once the design is loaded, it makes the necessary calls to the service APIs of the IoT Platforms Services and executes the internal functions, in the order indicated in the model to run the service composition. It collaborates with the IPSM, which is responsible for performing semantic translation of data exchanged between artifacts...

Finally, the API is responsible for making the interaction tools to manage the Orchestrator and the flows stored in the Flow Repository available to the AS2AS user. For example: it would be like a process manager; where a user can start/stop a flow of execution, view its status, load a flow in the orchestrator and so forth.