WIP MOST-Server

MOST-Server (Munich Open Sensor Things API Server) implements an opinionated version of the OGC Sensor Things API. Alternative to FROST Server

Based on

• Spring Reactive Familiar and modern development platform
• OData Standard for interaction
• Apache Olingo OData handling
• OAuth 2.0 General user and device authentication and authorization
• UMA Resource based authorization
• MQTT Sparkplug B TBD

Features

• Permission-based authorization
• OData compatible API
• Object auditing
• Optimistic locking
• TimescaleDB support

Design Targets

• Use of existing standards - Easy integration into custom environment
• Extensive use of already existing libraries - Keep code-base small. Less code, means less code to maintain and less code to understand data flow*
• Permission-based access control - allow fine granular control over resources and flexible user patterns
• Offer interface for commonly used data interactions out-of-the-box
• Extendability of data interface for custom use cases
• Scalability - native support for clustering
• High-availability - native support for distributed deployment
• Functional programming style approach - easy understanding of code flow and testability

Divergence from Open Sensor Things API

• Sensors, things and datastreams are assigned to one project (new type). The thing and sensor a datastream belongs to have to be in the same project.
• Odata defines the id field with @id. Open Sensor Things API redefines it as @iot.id breaking compatibility with odata libraries. This project sticks with @id
• This project won't support directly ingesting data via MQTT. It does not make sense to create objects like project, sensors, things etc. via MQTT. Ingesting observations is not supported either, because sensors may not publish data in the required format, so some kind of ingestionware is needed. The ingestionware can use the http api. This is the recommended default
• Open Sensor Things API MQTT specification allows $filter and $expand options on the topics. This does not conform to the MQTT standard and is not implementable with a standalone MQTT Broker without additional communication which is not specified by the standard, so this project won't support it
• The observation type OM_Measurement is generally unconstrained. Creating a datastream with this type will require a JSON Schema. Created observation results will be validated against this schema and rejected if they do not match