Enlightment works.
When the interfaces match.

DVTDS Interfaces

DVTDS features the following set of interfaces:
  • The LDAP interface. Used for client interactions and OAM activities. In the context of mobile 4G applications and the new 5G standard this interface is used for the UDR. In addition this serves as well for NUDSF (unstructured data), if applications prefer LDAP instead of HTTP. Further the internal interfaces for distributed operations like replication, sharding, distributed transactions and data federation to third party systems are based on LDAP.
  • The restful HTTP interface. Used for client interactions. The NUDR (JSON over HTTP) and NUDSF (unstructured data) interfaces according to the 3GPP standard for 5G networks are available. They share the same data view technology as used for the LDAP interface. As this allows for adaptation of binary content it can even be used for unstructured data of NUDSF clients. Applications see the equivalent content regardless whether they access the database via LDAP or HTTP. Only the transfer protocol and the presentation format differ depending on the chosen interface. Further the API for the Google App Engine and Amazon DynamoDB are on the roadmap.
  • The binary ASN.1 interface. This is used to extract data from third party databases. The interface supports real time capture of ongoing transactions by coninuous read of their journals files.
  • The logfile CSV interface. Used by OAM systems.
  • The data exposure / data mining interface. This allows high speed export of selected data in various formats like LDAP, LDIF, JSON, SPML and CSV. The built in data view functionality is fully supported to shape the outgoing content according to the needs of subsequent data processing facilities. This interface is also used for full or selective backup to human readable formats.
  • The data import interface. This is used for high speed restore data from backup. The formats LDAP and LDIF are supported.
  • The binary backup and restore interface. This is used by OAM systems for full backup and restore in the DVTDS internal binary format.
  • The trigger interface. DVTDS can be configured to send notifications to remote systems upon certain events. An "event" is for instance the update of an attribute or an access to restricted data. Notification content is sent in SOAP format according to the 3GPP standard. Same as for LDAP and REST interfaces the trigger content can be shaped according to the data view of the client.
  • The software update interface. DVTDS supports online software update without affecting ongoing client interactions and connections, even under full load from multiple parallel clients. The software update process is executed via LDAP operations. It exchanges the DVTDS software modules inbetween two client requests. The action takes only between 800 micro seconds and 3 milli seconds depending on the amount of current client traffic and the number of exchanged software modules. Afterwards the very next client request is already executed with the updated software.
  • The CQL interface. Used for client interactions. This interface is on the roadmap.


Almost all of these interfaces can be used and configured in online mode. Knobs, switches and properties of the server are exported in a well organized and consistent portion of the directory information tree called the administrative area. Like this the complete administration of the server is object oriented and takes immediate effect without interruption of service. The administrative actions are performed via LDAP either using command line or graphical user interface integrated iwth standard OAM systems.
A number of GUI implementations is available from the open source world. DVTDS comes equipped with the most advanced of them, the Apache Directory studio. Further it is possible to integrate the server into any OAM platform supporting LDAP and CLI interfaces. LDAP and HTTP interfaces support SSL encryption. Backup and report data can be encrypted as well.

DVTDS Interfaces