Page History

This template should be used to implement the majority of the services, there might be exceptions that are not known yet.

The following table gives an overview which services are required.

Service name	description	implementation status
user service	this is a crud-service whicht maintains the user base for the whole eco-system. It allows user to onboard, change data and be deleted. It requires a database to store the data permanently
data store service	is a crud service that allows the management of a data source.
data source management	This is a crud service to onboard a data source. This can be a car or another IoT device. These sources needs to be linked with an individual (the owner) and the corresponding data store usually the manufacturer owns.
registry	is used to register components of the system (nodes and services) and is used for runtime resolution of requests
audit trail	legal compliance needs proof. This service writes an audit trail of events that can be used in trials as a proof
usage service	this service simply counts the usage of resources as a metrik. This can be used for billing later.
billing	based on usage and negotiated rates, a monthly bill can be generated.
monitor	this service monitors the system and based on thresholds will trigger alarms or countermeasures
logging	this services receives log messages from all services (per node) and will store them within the node

As for all µ-service based architectures it is important to cut the services in a way that on one hand the

size of the service stays maintainable but on the other hand that they are not too simple (too many services).

A concept called orchestration makes out of the services a workflow. For example, if a user from the type of a

data collector is onboarding the orchestrator will ask to onboard a data source as well. These workflows

will be described in the following sections.

Space shortcuts