The Object Memory Sever (OMS) is a service for centralized storage and management of digital object memories (DOMe). The server provides a memory storage based on the OMM+-Model and is able to serve such memories via a RESTful HTTP-interface. Apart from the actually storage capability, enabling sophisticated role-based memory access and revision control functionalities, the server provides additional features for integrating activity and inference components. The implementation is done in Java7 enabling the server to run on Windows, Mac and Linux systems.
The following figure shows all components of the OMS ecosystem. Below the figure you find some details about each component.
All memories stored in an Object Memory Server are kept in file-based Object Memory Models.
We support three different types of data representation:
In addition other backends can be easily integrated. For further information about the file formats, take a look at the OMM+ page.
The OMS provides revision control capabilities for storage of memory lifetime changes and access, for revert to earlier memory state (e.g. for demonstration purposes), and for access to older memories.
Object memories may contain sensitive data (e.g. private or confidential data). The OMS allows defining access restriction to entire memories or single memory blocks. Restrictions can be bound to simple secrets (like username/password) or X.509 certificates (including certificate chains). An additional use-case has been realized with the RFID-based new German ID card (nPA eID).
Interaction with the OMS is done via a RESTful http-interface. This interface is separated into several functional parts each providing some specific actions. These functional parts consist of two mandatory parts and additional enhanced modules that are not available for all OMS incarnations. The mandatory parts are the feature negotiation, indicating which optional modules are availible, and the storage interface for direct access to the object's memory.
The OMS provides a declarative description of all available feature sets, their parameters, and their access conditions. This allows applications to detect the available features and to adapt the interaction with the memory functions.
This storage interface is responsible for the following actions:
For further information how to use this interface, please take a look to our developer section.
This approach contains the idea of activity modules based on LUA-scripts that extend memory functionality and are triggered by external calls or periodically. OMS operators can upload scripts to memories and end users can enable and configure scripts for each memory. In addition data inference based on in-memory rules will be achieved. Memories can bring with a set of rules (e.g. alerts on threshold exceedance) that should be monitored during its lifetime and the conclusions may trigger external events (e.g. e-mail) or generate new block data.
The RESTful interface described above is tailored for external applications and visualization frameworks. In addition end-users can access memories via an HTML5 web application. This application can be used to take a raw look on the memory and for all actions that can also be done with the RESTful interface. The web interface also provides access to the management of build-in functions like revision control and role-based access.
Please take also a look to the web interface of a sample memory.