stream - wso2/ws02 CEP, ESPER u otra cosa?
(2)
Tengo un caso de uso en el que se produce / completa una transacción del sistema durante un período de tiempo y con varios pasos de "creación". cada paso en el proceso genera uno o más eventos (hasta 22 eventos por transacción). Todos los eventos dentro de una transacción tienen una ID de correlación compartida y única (uuid).
Un ejemplo es para una transacción X: tendrá los bloques de construcción de EventA, EventB, EventC ... y todos etiquetados con un identificador de correlación único.
El objetivo final aquí es pasar de persistir todos los eventos separados en un RDBMS y consultar una vista consolidada (muchas uniones) Para: poder mantener solo 1 registro de transacción que consolidará los atributos de cada paso de la transacción.
Mi investigación hasta ahora me llevó a leer sobre Esper (Java stack aquí) y WSo2 / WS02 CEP. En mi caso, cada evento es enviado / en cola a JMS, y me pregunto si una solución como WS02 / WSo2 CEP puede usarse para consolidar eventos / mensajes JMS (streams) y basada en la ID de correlación (y límite de tiempo máximo de 30 min) un registro consolidado y enviarlo a JMS para finalmente persistir en un DB.
Como todavía estoy en modo de investigación, me preguntaba si estoy en el camino correcto para encontrar una solución.
Alguien ha logrado tal cosa usando WS02 / WSo2 CEP, o es over kill? otras recomendaciones?
Gracias -S
Puede usar WSO2 CEP integrando eso a JMS para enviar y recibir eventos y usando consultas Siddhi Pattern [1] para consolidar eventos que llegan de la misma transacción.
30 minutos es un período de tiempo razonable y se recomienda probar el escenario con algún conjunto de datos de prueba porque debe necesitar suficiente memoria en los servidores para que el CEP maneje los estados. Esto dependerá en gran medida de la tasa de eventos.
AFAIK esto no es una muerte excesiva en una implementación empresarial.
Te recomendaría que pruebes patrones Esper . Para el sistema basado en varios proyectos donde se recopila información particular, los patrones funcionan de la mejor manera.
Un ejemplo de muestra sería:
select * from TemperatureEvent
match_recognize (
measures A as temp1, B as temp2, C as temp3, D as temp4
pattern (A B C D)
define
A as A.temperature > 100,
B as (A.temperature < B.value),
C as (B.temperature < C.value),
D as (C.temperature < D.value) and D.value >
(A.value * 1.5))
Aquí, tenemos 4 eventos y 5 condiciones que involucran estos eventos. El ejemplo se toma del proyecto de demostración.