Лучший способ реализовать проверку правил при общении с устройством GPS

Кто-то из FedEx представил нечто подобное на конференции JavaOne, которую я посетил пару лет назад.

По сути, идея заключалась в том, чтобы использовать Drools Expert + Fusion для выполнения CEP (комплексной обработки событий) данных о местонахождении транспортного средства.

Насколько я помню, транспортное средство периодически (даже каждые пару секунд) отправляло свои GPS-координаты в двигатель (событие), которые затем обрабатывались механизмом правил и, в зависимости от правил, могли запускать определенные действия, такие как создание предупреждений («автомобиль заглох» или «не по курсу») или отправка уведомлений («автомобиль прибудет в пункт назначения через ~ 15 минут»).

(Google для "отслеживание транспортных средств drools fusion cep" обнаруживает эта презентация, которая должна дать вам несколько дополнительных деталей или, по крайней мере, дать некоторое представление .)

способ работы Drools заключается в том, что вы заполняете множество объектов в «Рабочей памяти» Drools. Пока вы заполняете объекты, Drools узнает, какие правила «срабатывают» для объектов, и сохраняет объекты в Rete-Tree. Когда вы закончите помещать объекты в память и активируете все правила, Drools обработает написанный вами код в соответствии с правилом.

Я бы посоветовал вам сделать объект со всеми данными, полученными от транспортного средства, необходимыми для ваших правил, и поместить его в рабочую память.

В Drools вы должны создать множество маленьких правил, каждое из которых просто проверяет что-то одно и действует в зависимости от результата.

Не рекомендуется позволять Drools получать данные, необходимые для оценки, но я не вижу никаких проблем в том, чтобы позволить Drools инициировать некоторые события, которые отправляют сообщения транспортному средству или какой-либо другой системе. (Думаю, это должно происходить асинхронно, чтобы не замедлять работу Drools). Фактически, Drools предлагает вам подключить прослушиватель событий.

Нет смысла бегать каждые 15 минут. Это приведет к задержке срабатывания триггеров, а также к скачкам нагрузки каждые 15 минут, за которыми следуют периоды отсутствия нагрузки.

У вас может быть флаг в вашей базе данных для новых правил предупреждений и новых данных о местоположении. При сканировании событий можно использовать двухпроходный подход. Проверьте все новые правила по всем данным о местоположении и отметьте их как не новые. Затем проверьте все новые данные о местоположении на соответствие существующим правилам и отметьте их как не новые.

Вы можете запускать это так часто, как вам нравится. В идеале вы не стали бы ждать так долго, потому что чем дольше вы ждете, тем больше работы накапливаете.

Что касается того, что коммуникатор TCP периодически проверяет наличие соответствующих предупреждений при сканировании базы данных, основным преимуществом будет немедленное получение предупреждений. Недостатком будет то, что обработка предупреждений замедлит путь коммуникатора TCP, и вы будете привязаны к модели «одно обновление означает одну проверку предупреждений».

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

Я думаю, что все подходы, которые вы рассматриваете, будут работать нормально.