Software Requirements Specification - GoranErdeljan/TINF19C-Team-4-Service-Registry GitHub Wiki
SRS created by Daniel Baumann
1. Introduction
The goal of the project is to add service discovery functionalities to the existing Oi4-Service-Registry, developed by the OI4-Alliance. To be added features are the registration of devices, which are announced via DNS-SD but also to take the services, which are already registered at the OI4-Service-Registry and announce them to the network using the DNS-SD mechanism. These features shall be implemented in an application running in a Docker-Container. The project shall also contain a Docker-Application for testing the functionalities of the system.
The project consists of two main parts: the Docker-Container connecting the DNS-SD mechanism with the OI4-Service-Registry and the Docker-Container, which tests and showcases the functionalities of the system. To realize a working system, there need to be other applications running in the environment. These are the OI4-Service-Registry developed by the OI4-Alliance and a MQTT-Broker on which the communication with the OI4-Service-Registry takes place. The communication using the MQTT-Protocoll is specified by the OI4-Alliance.
Conceptually the main Docker-Container is just another MQTT-Client. The OI4-Service-Registry also acts as a MQTT-Client. Both communicate with each other over the MQTT-Broker. In most cases the MQTT-Broker of choice will be Eclipse-Mosquitto, as it is available as a Docker-Image and therefore easy to deploy. All Communication over MQTT must be conform with the specifications published by the OI4-Alliance. In the context of the systems specified by the OI4-Alliance this way of communicating is called the OI4-MessageBus. Services can use the MessageBus to be registered at the OI4-Service-Registry. The Test Application shall also be able to connect to the MessageBus, if it is configured to register itself at the OI4-Service-Registry.
The DNS-SD mechanism on the other hand is used to announce important information about a service in the network. It is not limited to services, which are part of the OI4-ecosystem. In this use-case it is not only used to announce the services registered at the Service-Registry, but if configured to, also collect information about not yet registered services, which may announce themselves to the network and register them at the OI4-Service-Registry.
2. Use Cases
2.1 UA-001 Registering Services, that are found using DNS-SD
| Related Business Process: | - |
|---|---|
| Use Cases Objective: | Registering all available services at the OI4-Service-Registry |
| System Boundary: | OI4-Service-Registry, Services, which announce themselves using DNS-SD, Docker-Application |
| Precondition: | The to be registered services must use TXT-records conform with the specification published by the OI4-Alliance |
| Postcondition on success: | The services will be registered at the OI4-Service-Registry |
| Users: | - |
| Triggering Event: | Any new DNS-SD entries on the network. |
2.2 UA-002 Announcing registered Services on the network
| Related Business Process: | - |
|---|---|
| Use Cases Objective: | Announcing registered Services on the network |
| System Boundary: | OI4-Service-Registry, Services registered at the OI4-Service-Registry, Docker-Application |
| Precondition: | The services have to be registered at the OI4-Service-Registry |
| Postcondition on success: | The services will be announced to the network using the DNS-SD mechanism. |
| Users: | - |
| Triggering Event: | Any new service registered at the OI4-Service-Registry |
2.3 UA-003 Deployment
| Related Business Process: | - |
|---|---|
| Use Cases Objective: | Simple software deployment as target |
| System Boundary: | - |
| Precondition: | The Docker-Images needed to start the Docker Container from shall either be built from the source-code that is contained in the GitHub-Repository or be downloadable from the 'docker-hub' |
| Postcondition on success: | The Docker-Images needed to start the Docker Container from shall either be built from the source-code that is contained in the GitHub-Repository or be downloadable from the 'docker-hub' |
| Users: | - |
| Triggering Event: | - |
3. Non-Functional Requirements
3.1 /NF10/ User Documentation
The Project should contain extensive documentation for all parts of it. Using this documentation, a user should be able to install and use all components and features, the application provides. The documentation shall be distributed using a PDF file contained in the GitHub-Repository.
3.2 /NF20/ Exemplary Docker Test-Applications
The Project should contain simple Docker applications, which use and test the basic functionalities of the system. This is necessary in order to optimally check the system for faults and to eliminate them.
3.3 /NF30/ Easy Deployment
An easy deployment shall be targeted, as the system is based on Docker-containers. The Docker-Images needed to start the Docker container from shall either be built from the source-code that is contained in the GitHub-Repository or be downloadable from the 'docker-hub'.
4. Functional Requirements
4.1 /LF10/ Running in Docker
The Application has to be able to run in the context of a Docker Container for all functions to work properly. The instructions to build and configure such a container shall be included in the User documentation.
The master asset model described in the document (https://github.com/GoranErdeljan/TINF19C-Team-4-Service-Registry/files/5407856/Open.Industry.4.0.Alliance.-.Development.Guideline_v0.11.pdf) is mapped to the TXT records. The TXT records is the data model for DNS-SD entries. This data model is divided into several strings, since the length of a TXT records string may only have a maximum length of 255 bytes (see https://tools.ietf.org/html/rfc6763#section-6.1) section 4 "The format of each constituent string within the DNS TXT record is a single length byte, followed by 0-255 bytes of text data"). Each of these strings always consists of a key and a value. The key is the attribute name in the master asset model and the value is a JSON string for the corresponding object. The prerequisite for the system to work well is that all specifications and required attributes mentioned by the OI4 are set. In addition to the data contained in the MAM, "oi4=true" should be entered there as a key-value-pair. This value tells the interface that it should register the given MAM in the registry. The key "DataSetWriterId" is used to check whether the interace of this MAM was sent by itself via DNS-SD. Example for TXT Records:
4.2 /LF20/ Listening to DNS-SD Entries
The Main Docker application should listen to any upcoming DNS-SD Services. It should then decide, whether the entries are from services, which need to be published to the OI4-Service Registry.
4.3 /LF30/ Registering Services at the OI4-Registry
The data that is collected from the DNS-SD entries should be taken and published on the OI4-MessageBus. Published messages have to fulfill the specifications put up by the OI4-Alliance.
4.4 /LF40/ Listening to Services registered at the OI4-Service-Registry
The main Docker application shall listen to any changes in the services registered at the OI4-Service-Registry. When there are new services registered it shall announce them to the network via DNS-SD. In this case, the service is entered in the OI4 service registry.