La mejor manera de implementar la verificación de reglas durante la comunicación con el dispositivo GPS

Question

Estamos desarrollando un sistema de rastreo de vehículos. Al igual que todos los VTS, tenemos dispositivos GPS instalados en los vehículos que siguen enviando información de ubicación al servidor. En el servidor, nuestro proceso de comunicador TCP sigue leyendo esos datos y los guarda en la base de datos. Ahora, necesitamos verificar si existe un conjunto de reglas para activar alertas para los vehículos, por ejemplo, necesitamos alertas cuando el vehículo llega a una ubicación particular, si el vehículo cruza un límite de velocidad específico, etc. ¿Puede sugerirnos la mejor manera de implementarlo? Hemos pensado en algunas formas de implementarlo, 1. Nuestro comunicador TCP, cuando recibe la ubicación, debe verificar las alertas. 2. Habrá un proceso que seguirá ejecutándose cada 15 minutos y verificará los detalles de la ubicación en esos 15 minutos para recibir alertas.

Estoy buscando las sugerencias para implementarlo, lógicamente, así como a nivel de tecnología. p.ej. Si debemos usar Drools o no ?, etc.

Answer 1

Alguien de FedEx presentó algo así en una conferencia de JavaOne a la que asistí hace un par de años.

Básicamente, la idea era, sí, utilizando Drools experto + Fusión para realizar CEP (eventos complejos de procesamiento) en los datos de localización de vehículos.

Por lo que recuerdo, un vehículo enviaba periódicamente (cada dos o tres segundos) sus coordenadas GPS al motor (un evento) que luego sería digerido por el motor de reglas, y dependiendo de las reglas podría disparar ciertas acciones como levantar alertas ("el vehículo está atascado" o "fuera de curso") o enviar notificaciones ("el vehículo llegará a destino en ~ 15 minutos").

(Google para "drools fusion cep vehicle tracking" destapa this presentación que se debe dar algunos detalles más, o al menos proporcionar una cierta penetración.)

Answer 2

la manera en que funciona Drools, es que llenas muchos objetos en la "Memoria de trabajo" de Drools. Mientras llenas los objetos, Drools descubrirá qué reglas "disparan" sobre los objetos y almacena los objetos en un Rete-Tree. Cuando termine de colocar los objetos en la memoria y dispare todas las reglas, Drools procesará el código que escribió correspondiente a la regla.

Sugeriría que haga un objeto con todos los datos recibidos del vehículo necesarios para sus reglas y los ponga en la memoria de trabajo.

En Drools debe hacer muchas pequeñas reglas, cada una de las cuales solo verifica una cosa y actúa sobre el resultado.

No es una buena práctica dejar que Drools obtenga los datos necesarios para la evaluación, pero no veo ningún problema en dejar que Drools active algunos eventos, que envían mensajes a un vehículo u otro sistema. (Supongo que debería ocurrir de manera asincrónica, para que no disminuya la velocidad de Drools) De hecho, Drools le ofrece conectar un eventlistener.

Answer 3

No hay ninguna razón para ejecutar cada 15 minutos. Eso introducirá demoras en los factores desencadenantes y también provocará ráfagas de carga cada 15 minutos, seguidas de períodos sin carga.

Puede tener un indicador en su base de datos para nuevas reglas de alerta y nuevos datos de ubicación. Cuando escanea eventos, puede usar un enfoque de dos pasos. Verifique todas las reglas nuevas contra todos los datos de ubicación y márquelas como no nuevas. Luego, compruebe todos los datos de ubicación nuevos contra las reglas existentes y márquelas como no nuevas.

Puede ejecutar esto tantas veces como desee. Idealmente, no esperarías tanto porque cuanto más esperas, más trabajo acumulas.

En cuanto a que el comunicador TCP verifique las alertas relevantes sobre el escaneo, la base de datos se acerca periódicamente, la principal ventaja sería que las alertas serían inmediatas. La desventaja sería que el procesamiento de alertas ralentizaría la ruta del comunicador TCP y estaría bloqueado en un modelo de "una actualización significa un cheque para alertas".

En el enfoque de "escanear la base de datos", si la carga es demasiado alta, puede terminar buscando alertas solo en cada una de las tantas actualizaciones de fuentes de actualización de alta frecuencia. Esto, naturalmente, se ocupa de la carga al reducir la cantidad de trabajo necesario, pero podría dar lugar a una alerta perdida.

Creo que todos los enfoques que está considerando funcionarán bien.