Die d.velop AG setzt auf eine moderne Software-Architektur, die u.a. auf Microservices basiert.

Beispielsweise ist d.3one eine Sammlung einzelner Microservices, die interagieren und Anwendenden die DMS-Funktionalitäten an der Benutzeroberfläche bereitstellen. Jeder Microservice ist eine eigenständige Anwendung.

In der d.3-Architektur wird ein Microservice als App bezeichnet.

Jedes d.velop-Produkt besteht aus eigenen Apps, die spezifisch für das Produkt sind und mit einem eigenen Setup installiert werden. Wenn beispielsweise von einer App mehrere App-Instanzen installiert sind (z.B. im Clusterbetrieb oder zwecks Skalierung), müssen alle Apps die gleiche Version aufweisen.

Mit diesem Architekturdesign können Sie den Anforderungen Ihrer Serverumgebung entsprechend flexibel entscheiden, welche App Sie wie häufig auf welchem Host in einer d.3-Umgebung installieren. Sie haben mit diesem Architekturdesign die größtmögliche Freiheit, Ihre speziellen Anforderungen der IT-Umgebung zu berücksichtigen.

Neben den produktspezifischen Apps gibt es die zentralen Apps, die Sie immer separat berücksichtigen müssen.

Zentrale Apps in der d.3-Architektur 

In der d.3-Systemlandschaft gibt es eine Reihe von Apps, die eine zentrale Bedeutung für viele Produkte der d.velop AG haben. Alle folgenden Apps werden als Produkt Infrastruktur mithilfe von d.velop software manager installiert und sind nicht Gegenstand anderer d.velop-Produkte:

d.ecs http gateway 

Die d.ecs http gateway-App ist die zentrale HTTP-Schnittstelle zu allen Apps in einer d.3-Umgebung. Die gesamte HTTP-Kommunikation findet über diese App statt. Technisch gesehen ist es ein Reverse Proxy. Jede App registriert sich bei der d.ecs http gateway-App. Anschließend ist die neu registrierte App unter https://<BaseUri>/<App-Name> für alle anderen Apps erreichbar. Sollen in einer d.3-Umgebung mehrere d.ecs http gateway-Apps ausgeführt werden, müssen alle d.ecs http gateway-Apps unter derselben Basisadresse erreichbar sein. Pro d.3-Umgebung darf es nur eine Basisadresse geben.

d.ecs jstore 

Die App d.ecs jstore ist eine NoSQL-Datenbank, die häufig vom d.3-Server angefragte Daten, wie z.B. Eigenschaftswerte für häufig gesuchte Dokumente, im Speicher des Anwendungsservers zwischenspeichert. Die erforderlichen Datenbankzugriffe auf die d.3-Datenbank werden auf diese Weise reduziert und somit wird die Leistungsfähigkeit des gesamten Systems erhöht.

Zudem wird d.ecs jstore von den unterschiedlichen d.velop-Komponenten (z.B. d.3one, d.ecs monitor) genutzt, um Daten zu persistieren.

d.ecs jstore basiert auf Redis (Remote Dictionary Server) und ersetzt Couchbase als Zwischenspeicher, das bis zur d.3-Version 8.0 eingesetzt wurde. Die App ist unter anderem leichter zu konfigurieren und bietet damit deutliche Vorteile gegenüber der bisherigen Lösung.

Die App d.ecs jstore wird pro Windows-Host installiert, auf dem eine d.velop-App ausgeführt wird.

In einer d.3-Umgebung müssen die einzelnen d.ecs jstore-Instanzen, die sich jeweils auf einem Windows-Host befinden, zu einen Cluster zusammengeführt werden, damit ein Datenaustausch stattfinden kann.

d.ecs identity provider 

Die App d.ecs identity provider übernimmt stellvertretend für die einzelnen Apps die Authentifizierung von Benutzern. Zur Authentifizierung können Systeme wie z.B. der Windows Active Directory-Dienst genutzt werden. Die Autorisierung des Benutzers ist Aufgabe der jeweiligen App.

d.ecs shell 

Die d.ecs shell-App stellt den gemeinsamen Rahmen für die HTML-Oberflächen der einzelnen Apps bereit und implementiert ein einheitliches Bedienkonzept, sodass die Oberflächen der Apps konsistent sind und wie aus einem Guss wirken. Die App bietet darüber hinaus Zugriff auf die nativen Funktionen des Hosts. Mit einem Host ist in diesem Zusammenhang z.B. eine E-Mail-Anwendung, eine ERP-Anwendung oder auch ein Browser gemeint.

Mögliche Szenarien für eine d.3-Umgebung mit d.3one 

Sie können Ihre d.3-Umgebung ganz speziell gemäß den Anforderungen Ihres Unternehmens oder Ihrer Organisation gestalten. Sie haben die Möglichkeit, mindestens einen zentralen Anwendungsserver zu nutzen oder die Apps auf verschiedene Anwendungsserver zu verteilen. Es bleibt Ihren Ansprüchen und Anforderungen an die IT-Umgebung überlassen, wie Sie Ihre d.3-Umgebung organisieren.

Beispiel 1 

Die zentralen Apps wurden auf einem Anwendungsserver installiert, während die produktspezifischen Apps auf einem anderen Anwendungsserver installiert wurden.

Beispiel 2 

Die zentralen Apps wurden auf zwei Anwendungsservern verteilt, und die d.ecs http gateway-App ist in der d.3-Umgebung zweimal vorhanden.

Wenn Sie Fragen zum Clusterbetrieb oder zur Skalierung haben, wenden Sie sich an Ihren d.velop-Ansprechpartner.