Modèle de données distribuées

Question

Je travaille dans le domaine de la robotique de terrain et nous avons un serveur central qui garde un tas de données concernant l'état du véhicule, l'état de l'environnement, les tâches, le groupe de tâches, etc. Il existe des processus qui traitent de différentes parties de ces données et des interfaces utilisateur qui doivent être mises à jour lorsque des pièces spécifiques changent.

Ce que je veux, c'est un moyen pour les systèmes de se connecter au serveur central et de s'abonner à une partie des données. Ils reçoivent toutes les données et tout changement est envoyé au fur et à mesure. De plus, j'aimerais être en mesure de proposer que certaines mises à jour peuvent être fusionnées: si un véhicule s'est déplacé 3 fois mais que l'interface utilisateur connectée n'a pas beaucoup de bande passante, seule la dernière position est envoyée. Actuellement, je pense à une base de données en mémoire qui garde une trace des requêtes d'abonnement client et calcule les deltas à envoyer à eux. Existe-t-il un meilleur moyen ou une solution existante de distribuer un modèle de données?

Answer 1

Vous voudrez peut-être tuple space. En Java, il y a JavaSpaces, qui fait partie de Jini. Je ne sais pas si la notification de changement est prête à l'emploi, ou si vous devez ajouter vous-même des notifications.

Answer 2

Je serais probablement (sorte de ab-) utiliser Apache ServiceMix pour ce scénario. L'utilisation d'un middleware orienté message ne peut que profiter à votre projet.

décrivant ma solution d'une vue de très haut niveau:

La façon dont je le vois, quand abstraire le problème un peu, nous parlons d'événements qui se produisent, qui doivent être traitées selon les règles (d'affaires) . En fonction de ces règles métier, les autres partenaires de communication doivent être notifiés de manière synchrone ou asynchrone. Ainsi, vos différentes stations peuvent envoyer des messages JMS plutôt simples au composant ActiveMQ de ServiceMix lorsqu'un événement se produit. La logique métier exécutée sur le ApacheCamel lira ensuite ces messages et les traitera. Le composant Camel offre un riche ensemble de fonctionnalités pour les modèles d'intégration d'entreprise. La mise en œuvre de la logique métier est plutôt simple et directe. Les stations qui doivent être notifiées peuvent s'abonner à des files d'attente JMS ou à des rubriques, selon le cas d'utilisation, ou de manière synchrone via une coutume ou l'une des many existing connectors et data formats. Astuce: L'envoi de protocol buffers sur JMS ou AMQP peut être implémenté en C ou C++ avec une relative facilité. Cela devrait permettre un code très efficace sur les stations, éliminant la dépendance sur une JVM en même temps.

Avec l'utilisation de la configuration ServiceMix, vous avez différents avantages:

• notifications durables et les abonnements à la fois pour des événements et des données calculées, lors de l'utilisation JMS pour la communication asynchrone - si mis en place correctement, aucun événement ne sera perdu , ce qui pourrait ne pas être le cas avec une solution basée sur RAM.
• A battle tested environment, prêt à l'emploi
• Facilité d'entretien: mises à jour de la logique métier peut être roulé avec peu (fractions de secondes) à aucun temps d'arrêt, si l'application est prévue correctement. Cela est dû au fait que la logique métier sera implémentée en tant que OSGi bundles et que le remplacement de ces bundles peut être géré avec élégance. Facilité de développement: Au lieu de devoir développer une application complète, il suffit de mettre en œuvre la logique métier, le logiciel qui envoie les messages à ActiveMQ et à vos modèles de domaine.
• Intégration transparente dans la SOA existante
• De par sa conception, des problèmes complexes sont divisés en plusieurs plus petits, ce qui améliorera probablement la stabilité et correspond parfaitement à des procédures de développement agile