Zum Hauptinhalt springen

OctoMesh-Lösungsarchitektur

Dieses Dokument bietet einen umfassenden Überblick über die Architektur der OctoMesh-Plattform und soll Entwicklern helfen, die Systemkomponenten, Datenflüsse und Integrationsmuster zu verstehen.

Plattformüberblick​

OctoMesh ist eine cloud-native Dateninfrastruktur-Plattform, die das Data-Mesh-Paradigma umsetzt. Sie ermöglicht Organisationen, dezentrale, skalierbare Datenarchitekturen aufzubauen, die speziell für folgende Szenarien konzipiert sind:

  • Szenarien des industriellen Internets der Dinge (IIoT)
  • Mandantenfähige (multi-tenant) Umgebungen
  • Komplexe verteilte Systeme
  • Echtzeit-Datenverarbeitung und -Analyse

Kernphilosophie​

OctoMesh behandelt Daten als Produkt mit:

  • Domänenorientierter Verantwortung: Daten werden von Domänenexperten besessen und verwaltet
  • Self-Service-Datenplattform: Die Infrastruktur ermöglicht autonome Datenoperationen
  • Föderierter Governance: Zentralisierte Richtlinien mit dezentraler Ausführung
  • Produktdenken: Datenqualität, Auffindbarkeit und Benutzbarkeit sind erstrangige Anliegen

Übersicht der Architektur​

Kernservices​

Asset Repository Service​

Der zentrale Service für die Verwaltung von Datenprodukten und Ressourcen. Er bietet:

  • Speicherung und Abruf von Runtime-Entitäten
  • Verwaltung von Construction-Kit-Modellen
  • GraphQL-API für den Datenzugriff
  • Mandantenspezifische Datenisolation

Standardport: 5001

Identity Service​

Authentifizierung und Autorisierung auf Enterprise-Niveau mit Unterstützung für:

  • OpenLDAP und Microsoft Active Directory
  • Azure Entra ID (ehemals Azure AD)
  • OAuth-Provider von Google, Meta und Microsoft
  • Benutzerdefinierte Identity Provider

Standardport: 5003

Communication Controller Service​

Die zentrale Drehscheibe für die Verwaltung der Kommunikation zwischen Geräten und Anwendungen:

  • Registrierung von Adaptern und Lifecycle-Verwaltung
  • Sicheres Message-Routing
  • Geräteauthentifizierung
  • Netzwerkerweiterungsfähigkeiten

Standardport: 5015

Bot Service​

Automatisierte Assistenten für Routineaufgaben:

  • Datenaufbereitung und -bereinigung
  • Aggregation und Anonymisierung
  • Automatisierung der Benutzerverwaltung
  • Geplantes Reporting

Standardport: 5009

Platform Services​

Stellt den mandantenbezogenen _configuration-Discovery-Endpunkt bereit, den externe Clients (Refinery Studio, Office Integration, PowerBI / Power Query) nutzen, um Service-URLs zu ermitteln, stellt schreibgeschützte Observability-Endpunkte für Tenant / Blueprint / Drift bereit und besitzt das System.UI-Construction-Kit-Modell sowie die service-verwalteten Cockpit- / TenantMode-Blueprints. Optionale Services (Reporting, AI Services, MCP) werden mit einer leeren URL angekündigt, wenn sie nicht Teil der Installation sind – Clients interpretieren die leere Zeichenkette als „nicht installiert". Er ersetzte den stillgelegten Admin-Panel-Host.

Standardport: 5024 (http) / 5025 (https)

Datenpersistenzschicht​

MongoDB​

Primärspeicher für Stammdaten mit den folgenden Eigenschaften:

  • Dedizierte Datenbank pro Tenant zur Datenisolation
  • Speichert Construction-Kit-Definitionen
  • Speichert Runtime-Entitäten (RtEntities)
  • Unterstützt komplexe Abfragen und Aggregationen

CrateDB​

Optimiert für Zeitreihen- und Streamdaten:

  • Datenaufnahme mit hohem Durchsatz
  • Echtzeit-Analysefähigkeiten
  • SQL-Schnittstelle für vertraute Abfragemuster
  • Horizontale Skalierbarkeit

RabbitMQ​

Message-Broker für asynchrone Kommunikation:

  • Messaging zwischen Adapter und Service
  • Ereignisverteilung
  • Koordination der Pipeline-Ausführung
  • Zuverlässige Nachrichtenzustellung

Mandantenfähigkeitsmodell​

OctoMesh setzt strikte Mandantenfähigkeit auf mehreren Ebenen um:

Tenant-Funktionen​

  • Datenisolation: Jeder Tenant hat eine dedizierte MongoDB-Datenbank
  • Tenant-Kaskadierung: Tenants können Konfigurationen von übergeordneten Tenants erben
  • Adapter-Pools: Tenant-spezifische Adapter-Konfigurationen
  • Rollenbasierter Zugriff: Feingranulare Berechtigungen pro Tenant

Architektur des Datenmodells​

Construction Kit (CK)​

Der Construction Kit ist das flexible Datenmodellierungs-Framework von OctoMesh:

KonzeptBeschreibung
TypesDefinieren Datenentitäten mit Attributen, Assoziationen und Vererbung
AttributesEinfache Eigenschaften (string, number, boolean) oder komplexe Records
RecordsStrukturierte eingebettete Dokumente, die mehrere Attribute enthalten
AssociationsBeziehungen zwischen Typen (1:1, 1:N, N:M)
EnumsVordefinierte kontrollierte Vokabulare

Construction-Kit-Bibliotheken​

Bibliotheken sind hierarchisch organisiert:

Alle Bibliotheken hängen von der System Construction Kit Library ab, die Basistypen und gemeinsame Definitionen bereitstellt.

Runtime-Modell​

Runtime-Entitäten sind Instanzen von Construction-Kit-Typen:

// Example: Runtime Entity structure
{
"rtId": "unique-identifier",
"ckTypeId": "Industry.Energy/EnergyMeter",
"attributes": {
"name": "Meter-001",
"location": "Building A"
},
"associations": {
"connectedTo": ["device-rtid-1", "device-rtid-2"]
}
}

Adapter-Architektur​

Adapter verbinden OctoMesh mit externen Systemen für den bidirektionalen Datenaustausch.

Adapter-Typen​

TypStandortAnwendungsfall
Edge AdapterNahe an den DatenquellenNiedrige Latenz, lokale Verarbeitung, Offline-Fähigkeit
Mesh AdapterCloud/RechenzentrumAggregation, Verarbeitung im großen Maßstab, zentrale Verwaltung

Adapter-Terminologie​

  • Plugs: Adapter, die Daten IN OctoMesh aus externen Quellen abrufen
  • Sockets: Adapter, die Daten AUS OctoMesh an externe Systeme bereitstellen

Fluss der Datenpipeline​

API-Zugriff​

GraphQL-API​

Primäre API für den Datenzugriff, verfügbar unter:

https://{host}/tenants/{tenantId}/graphql/playground

Beispiel für eine Runtime-Datenabfrage:

query {
runtime {
rtIndustryEnergyEnergyMeter {
items {
rtId
ckTypeId
name
location
}
}
}
}

Beispiel für eine Streamdaten-Abfrage:

query {
streamData {
tsIndustryEnergyEnergyMeter(
first: 100
after: "cursor"
) {
items {
rtId
timeStamp
voltage
current
}
}
}
}

Authentifizierung​

OctoMesh verwendet OAuth 2.0 / OpenID Connect für die Authentifizierung:

  1. Access Token vom Identity Service beziehen
  2. Token im Authorization-Header einfügen
  3. Das Token enthält Tenant- und Scope-Informationen

Deployment-Architektur​

Kubernetes-Deployment​

Die OctoMesh-Services sind für das Deployment auf Kubernetes ausgelegt:

Edge-Deployment (K3s)​

Edge-Komponenten laufen auf leichtgewichtigen K3s-Clustern:

  • Minimaler Ressourcen-Fußabdruck
  • Fähigkeit zum Offline-Betrieb
  • Lokale Datenverarbeitung
  • Automatische Synchronisierung mit der Cloud

Sicherheitsmodell​

Authentifizierungsablauf​

Sicherheitsfunktionen​

  • TLS/SSL: Sämtliche Kommunikation verschlüsselt
  • JWT-Tokens: Zustandslose Authentifizierung
  • Scope-basierte Autorisierung: Feingranulare Zugriffskontrolle für die API
  • Tenant-Isolation: Vollständige Datentrennung zwischen Tenants
  • Audit-Logging: Umfassende Aktivitätsverfolgung

Nächste Schritte​