Модель распределенной информации

Question

Я работаю в области робототехники, и у нас есть центральный сервер, который отслеживает целую кучу данных, связанных с состоянием транспортного средства, состоянием окружающей среды, задачами, группировкой задач и т. Д. Существуют процессы, которые касаются различных частей этих данных и пользовательских интерфейсов, которые необходимо обновлять при изменении отдельных частей.

Я хочу, чтобы системы подключались к центральному серверу и подписывались на часть данных. Они получают все данные, переданные им, и любые изменения, отправленные по мере их возникновения. Кроме того, я хотел бы иметь возможность назначить, что некоторые обновления могут быть объединены: если транспортное средство переместилось 3 раза, но подключенный интерфейс не имеет большой пропускной способности, чем отправляется только последняя позиция.

В настоящее время я думаю о базе данных в памяти, которая отслеживает запросы на подписку клиентов и вычисляет дельта для отправки им. Есть ли лучший способ или существующее решение для распространения модели данных?

Answer 1

Возможно, вам понадобится tuple space. В java есть JavaSpaces, который является частью Jini. Я не знаю, поддерживает ли это уведомление об изменении из коробки, или вам придется добавлять какие-то уведомления самостоятельно.

Answer 2

Возможно, я использовал бы (тип ab-) для этого сценария Apache ServiceMix. Использование ориентированного на сообщения промежуточного программного обеспечения может принести пользу только вашему проекту.

Описывая свое решение с очень высокой точкой зрения уровня:

Как я вижу это, когда абстрагирования проблемы немного, мы говорим о событиях, которые происходят, которые должны быть обработаны в соответствии с (бизнесом) правилами , В зависимости от этих бизнес-правил другие партнеры по связи должны быть синхронно или асинхронно уведомлены.

Таким образом, ваши различные станции могут отправлять довольно простые сообщения JMS в компонент ActiveMQ ServiceMix, когда происходит событие. Затем бизнес-логика, работающая на ApacheCamel, будет читать эти сообщения и обрабатывать их. Компонент Camel предлагает богатый набор функций для корпоративных интеграционных шаблонов. Реализация бизнес-логики здесь довольно проста и понятна. Станции, которые должны быть уведомлены, могут подписаться на очереди или темы JMS в зависимости от варианта использования или синхронно через пользовательский или один из many existing connectors и data formats. Подсказка: отправка protocol buffers через JMS или AMQP может быть реализована на C или C++ с относительной легкостью. Это должно обеспечить высокоэффективный код на станциях, одновременно устраняя зависимость от JVM.

При использовании установки ServiceMix, у вас есть различные преимущества:

• Прочные уведомления и подписки как для событий и расчетных данных, при использовании JMS для асинхронной связи - если установлен должным образом, ни одно событие не будет потеряно , что может быть не так с решением на основе ОЗУ.
• battle tested environment, готовый к использованию
• Простота обслуживания: обновления для бизнес-логики может быть развернута с небольшими (доли секунды) до без простоев, если приложение правильно спланированная. Это связано с тем, что бизнес-логика будет реализована как OSGi bundles, и замена этих пакетов может быть выполнена изящно.
• Простота разработки: вместо того, чтобы разрабатывать целое приложение, вам нужно всего лишь реализовать бизнес-логику, программное обеспечение, которое отправляет сообщения в ActiveMQ и ваши модели домена.
• Бесшовная интеграция в существующей SOA
• Конструктивно сложные задачи разделены на различные мелкие, которые, вероятно, повышают стабильность и идеально соответствует гибким процедурам разработки