Verteiltes Datenmodell

Question

Ich arbeite in Feldrobotik und wir haben einen zentralen Server verfolgt einen ganzen Haufen von Daten mit Fahrzeugzustand, Umgebungszustand, Aufgaben, Aufgabengruppierung und so weiter zu tun. Es gibt Prozesse, die sich mit verschiedenen Teilen dieser Daten befassen, und Benutzeroberflächen, die aktualisiert werden müssen, wenn bestimmte Teile sich ändern.

Was ich möchte, ist eine Möglichkeit für Systeme, eine Verbindung zum zentralen Server herzustellen und einen Teil der Daten zu abonnieren. Sie erhalten alle Daten, die an sie weitergeleitet werden, und alle Änderungen, die gesendet werden, wenn sie passieren. Zusätzlich möchte ich in der Lage sein zu nominieren, dass bestimmte Updates zusammengeführt werden können: wenn ein Fahrzeug 3 Mal bewegt wurde, aber die angeschlossene Benutzeroberfläche nicht viel Bandbreite hat, wird nur die letzte Position gesendet.

Momentan denke ich eine In-Memory-Datenbank, die Clientabonnementabfragen verfolgt und Deltas berechnet, die an sie gesendet werden. Gibt es einen besseren Weg oder eine bestehende Lösung für die Verteilung eines Datenmodells?

Answer 1

Sie möchten vielleicht eine tuple space. In Java gibt es JavaSpaces, die Teil von Jini ist. Ich weiß nicht, ob es die Änderungsbenachrichtigung standardmäßig unterstützt oder ob Sie selbst Benachrichtigungen hinzufügen müssen.

Answer 2

Ich würde wahrscheinlich (Art von Ab-) Apache ServiceMix für dieses Szenario verwenden. Die Verwendung einer nachrichtenorientierten Middleware kann nur Ihrem Projekt zugute kommen.

meine Lösung aus einer sehr hohen Niveau Sicht beschreiben:

So wie ich es sehe, wenn das Problem ein wenig zu abstrahieren wir von Ereignissen sprechen, die geschehen, die verarbeitet werden müssen, um nach (Geschäfts-) Regeln . Abhängig von diesen Geschäftsregeln müssen andere Kommunikationspartner synchron oder asynchron benachrichtigt werden.

So könnten Ihre verschiedenen Stationen beim Auftreten eines Ereignisses eher einfache JMS-Nachrichten an die Komponente ActiveMQ von ServiceMix senden. Die Geschäftslogik, die auf der ApacheCamel ausgeführt wird, liest dann diese Nachrichten und verarbeitet sie. Die Camel-Komponente bietet umfangreiche Funktionen für Enterprise-Integrationsmuster. Die Implementierung der Geschäftslogik ist hier einfach und unkompliziert. Die Stationen, die benachrichtigt werden müssen, können JMS-Warteschlangen oder -Themen abonnieren, abhängig vom Anwendungsfall, oder synchron über eine benutzerdefinierte oder eine der many existing connectors und data formats. Hinweis: Das Senden von protocol buffers über JMS oder AMQP kann relativ einfach in C oder C++ implementiert werden. Dies sollte hocheffizienten Code auf den Stationen ermöglichen, wodurch die Abhängigkeit von einer JVM zur gleichen Zeit eliminiert wird.

Mit dem Einsatz von ServiceMix Setup haben Sie verschiedene Vorteile:

• Durable Benachrichtigungen und Abonnements sowohl für Veranstaltungen und berechnete Daten, wenn für die asynchrone Kommunikation JMS verwenden - wenn richtig eingerichtet ist, wird kein Ereignis verloren , was bei einer RAM-basierten Lösung nicht der Fall ist.
• A battle tested environment, bereit
• Einfache Wartung verwenden: Updates für die Business-Logik mit wenig (Bruchteilen von Sekunden) ausgerollt, um ohne Ausfallzeiten werden kann, wenn die Anwendung richtig geplant ist. Dies liegt an der Tatsache, dass die Geschäftslogik als OSGi bundles implementiert wird und der Austausch dieser Bundles ordnungsgemäß gehandhabt werden kann.
• Einfache Entwicklung: Anstatt eine ganze Anwendung zu entwickeln, müssen Sie nur die Geschäftslogik implementieren, die Software, die die Nachrichten an ActiveMQ und Ihre Domänenmodelle sendet.
• Nahtlose Integration in bestehende SOA
• Durch Design werden komplexe Probleme in verschiedene kleinere aufgeteilt, die wahrscheinlich die Stabilität verbessern und passt perfekt zu agilen Entwicklungsverfahren