La SOA basada en eventos es una forma de arquitectura orientada a servicios (SOA) que combina la inteligencia y la proactividad de la arquitectura basada en eventos con las capacidades organizativas que se encuentran en las ofertas de servicios . Antes de la SOA basada en eventos, la plataforma SOA típica organizaba los servicios de forma centralizada, a través de procesos empresariales predefinidos, asumiendo que lo que ya debería haberse activado está definido en un proceso empresarial. Este enfoque más antiguo (a veces llamado SOA 1.0) no tiene en cuenta los eventos que ocurren en procesos empresariales específicos o fuera de ellos. Por lo tanto, los eventos complejos, en los que un patrón de actividades (tanto programadas como no programadas) debería activar un conjunto de servicios, no se tienen en cuenta en la arquitectura SOA 1.0 tradicional.
La arquitectura SOA 2.0 («SOA basada en eventos») permite a los usuarios empresariales supervisar, analizar y enriquecer eventos para establecer conexiones entre eventos dispares que a primera vista no parecen intuitivamente obvios. Esto hace que estos eventos enriquecidos sean visibles para otros, especialmente analistas empresariales o directores de marketing, y también permite que el sistema SOA 2.0 automatice las acciones que se deben tomar para abordar algún patrón único. [1]
SOA 2.0 es la capacidad de crear eventos empresariales de alto nivel a partir de numerosos eventos de sistema de bajo nivel. Los eventos se crean filtrando datos en tiempo real (de middleware, aplicaciones, bases de datos y servicios web, por ejemplo) e infundiéndoles detalles definitorios, como dependencias o relaciones causales descubiertas al correlacionar otros eventos.
Si resulta evidente, a través de los eventos enriquecidos que produce un entorno SOA 2.0, que la tasa de abandono de carritos de compra por parte de los clientes ha aumentado en los últimos días, una notificación al departamento de marketing podría iniciar una investigación sobre lo que han hecho los competidores para que los clientes compren productos en otro lugar. ¿Había un producto común en la mayoría de los carritos de compra? Si es así, ¿cuáles son los precios que ofrece la competencia?
En la práctica, esta relación de eventos transmitidos se procesa a través de un motor de vectores causales, que realiza una búsqueda basada en eventos vistos recientemente y asigna un vector causal a un evento si se descubre una relación. Si A causa B, el motor de vectores causales verifica si el índice de regla de vector causal de B contiene una referencia a A. El motor puede manejar eventos para diferentes transacciones simultáneamente, quizás en un orden diferente al que ocurrieron.
A diferencia de los sistemas secuenciales o procedimentales (en los que los clientes deben consultar las solicitudes de cambio), la SOA basada en eventos permite que los sistemas y componentes respondan de manera dinámica, en tiempo real, a medida que ocurren los eventos. La SOA 2.0 complementa y amplía la SOA 1.0 al introducir capacidades de procesamiento de larga duración.
La capacidad de procesamiento de larga duración permite que la arquitectura recopile varios eventos asincrónicos durante un largo período de tiempo y correlacione estos eventos en relaciones causales. Los patrones de eventos de SOA 2.0 se pueden diseñar e implementar para buscar relaciones de eventos que abarquen días, semanas o meses; y cuando se cumplan ciertos criterios, activar un proceso comercial para abordar el patrón de eventos.
La programación basada en eventos de SOA 2.0 se estructura en torno al concepto de relaciones desacopladas entre productores y consumidores de eventos: a un consumidor de eventos no le importa dónde o por qué ocurre un evento; más bien, le preocupa que se lo invoque cuando el evento haya ocurrido. Los sistemas y aplicaciones que separan a los productores de eventos de los consumidores de eventos generalmente dependen de un despachador de eventos o canal. Este canal contiene una cola de eventos que actúa como intermediario entre los productores de eventos y los controladores de eventos.
El paradigma prototípico SOA 2.0 contiene cuatro elementos esenciales:
Los servicios web SOA 2.0 se pueden componer de dos formas: orquestación y coreografía. En la orquestación, un proceso central toma el control de los servicios web involucrados y coordina la ejecución de diferentes operaciones en los servicios web involucrados en la operación. Los servicios SOA 2.0 involucrados no saben (y no necesitan saber) que son parte de una composición o un proceso de negocio superior. Solo el coordinador central de la orquestación lo sabe, por lo que la orquestación está centralizada con definiciones explícitas de operaciones y el orden de invocación de los servicios SOA 2.0.
Por otra parte, la coreografía no depende de un coordinador central, sino que cada servicio SOA 2.0 que participa en la coreografía sabe exactamente cuándo ejecutar sus operaciones (según criterios de activación definidos) y con quién interactuar. La coreografía es un esfuerzo colaborativo centrado en el intercambio de mensajes. Todos los participantes de la coreografía deben conocer el proceso empresarial, las operaciones que se deben ejecutar, los mensajes que se deben intercambiar y el momento en que se deben intercambiar los mensajes.
BPEL sigue el paradigma de orquestación. La coreografía está cubierta por otros estándares, como WSCI (Web Services Choreography Interface) y WS-CDL (Web Services Choreography Description Language).
Las relaciones causales son inherentes al mundo que nos rodea y son intrínsecas a nuestra toma de decisiones. La inteligencia humana procesa y recopila estas relaciones más rápido que la capacidad computacional artificial actual. Uno de los obstáculos fundamentales de la inteligencia artificial es la ausencia de una capacidad automatizada para relacionar eventos entre sí, como ocurre cuando un ser humano utiliza la intuición humana.
Mediante un motor de vectores causales, la percepción de causalidad se puede mejorar en condiciones espaciotemporales adecuadas según reglas estructurales y temporales escritas en el motor. La percepción de semánticas causales complejas, como causalidades aditivas, mediadas y bidireccionales, debe codificarse de modo que el motor pueda distinguir entre eventos que están relacionados y aquellos que solo parecen estar relacionados pero, de hecho, no lo están.
El motor utiliza la propagación de la tasa de cambio del vector causal preponderante para codificar la relación entre los eventos y establece un orden parcial en el que valida la causalidad percibida entre múltiples ocurrencias. El motor reproduce y repite la secuencia de eventos en un orden temporal diferente para inferir lo que podrían ser conexiones topológicas relacionadas y compara estas repeticiones con reglas preprogramadas por un analista .
El motor de vectores causales procesa varios eventos de sistema de bajo nivel y los compara con estas reglas para activar eventos comerciales de nivel superior. Esto se hace a través de una aplicación de consola del motor de vectores causales (CVE) que muestra los eventos en tiempo real a los analistas comerciales. Mientras que los flujos de eventos se pueden observar a medida que ocurren, de manera muy similar a un indicador bursátil, la aplicación de consola CVE tiene varias ventanas que enumeran los mismos eventos en diferentes contextos, de modo que los analistas comerciales pueden ver lo que hace el CVE con las relaciones entre ellos.
La ventana secuencial muestra los eventos en orden de fecha y hora, y una o más ventanas más en distintos órdenes a medida que CVE trabaja con la lista de reglas y crea relaciones implícitas entre los eventos. Existen varios botones y controles en la aplicación de consola que permiten a los analistas comerciales crear relaciones entre eventos sobre la marcha y definir reglas que respondan a estas relaciones.
Los analistas de negocios pueden agregar detalles de definición adicionales mediante una declaración de consulta SQL adjunta a una regla o contexto de evento. La aplicación CVE funciona de manera muy similar a una aplicación de negociación de acciones moderna que los administradores de fondos mutuos utilizan para gestionar el riesgo. Un ejemplo de una aplicación y un motor CVE se puede ver en SILK. [2]
La mayoría de las implementaciones de bus de servicios empresariales (ESB) contienen una función denominada " mediación ". Por ejemplo, los flujos de mediación forman parte de la intercepción del bus de servicios empresariales de WebSphere . Mule también admite flujos de mediación. Los flujos de mediación modifican los mensajes que se transmiten entre los servicios existentes y los clientes que utilizan esos servicios. Un flujo de mediación media o interviene para proporcionar funciones, como el registro de mensajes, la transformación de datos y el enrutamiento; normalmente, las funciones se pueden implementar utilizando el patrón de diseño de intercepción. [3]
A medida que los mensajes pasan por el ESB, este enriquece los mensajes destinados a un canal que está monitoreando un evento comercial de alto nivel. Es decir, para cada mensaje, el ESB puede consultar una base de datos para obtener información adicional sobre alguna entidad de datos dentro del mensaje. Por ejemplo, en función del ID del cliente, el flujo de mediación del ESB podría obtener el código postal en el que reside el cliente. O, en función de la dirección IP de la solicitud de origen del usuario final, el flujo de mediación del ESB podría buscar en qué país, estado o condado se encuentra esa dirección IP.
Estos ejemplos representan el enriquecimiento de datos, el concepto de agregar valor adicional a los datos existentes, en función de la intención del evento comercial de alto nivel que finalmente se desencadenará.
Un flujo de mediación ESB es uno de los tipos de componentes de una arquitectura de componentes de servicio (SCA). Como cualquier componente SCA, el programa accede a un flujo de mediación a través de las exportaciones que proporciona, y el flujo de mediación reenvía mensajes a otros servicios externos a través de importaciones. Los tipos especiales de importaciones y exportaciones para JMS , denominados enlaces JMS, permiten a los desarrolladores especificar la configuración de enlaces y escribir código de manejo de datos. El flujo de mediación consta de una serie de primitivas de mediación que manipulan los mensajes a medida que fluyen a través del bus .
Una vez que los desarrolladores han codificado el enlace personalizado tanto para la exportación como para la importación, pueden comenzar a centrarse en el componente de flujo de mediación. En el editor de ensamblajes de WebSphere Integration Developer, esto se realiza mediante el componente de mediación de enlaces personalizados de JMS, donde cada operación en la interfaz del componente de flujo se representa mediante una solicitud y una respuesta.
El marco de trabajo de Objetos de datos de servicio (SDO) proporciona un marco unificado para el desarrollo de aplicaciones de datos. Con SDO, los desarrolladores no necesitan estar familiarizados con ninguna API específica para acceder a los datos y utilizarlos. A través de SDO, los desarrolladores simplemente trabajan con datos de múltiples fuentes de datos, como bases de datos relacionales, componentes EJB de entidad, páginas XML, servicios web, la arquitectura de componentes de servicio y páginas JavaServer Pages.
Los flujos de mediación son completamente independientes de los enlaces que se utilizan en las importaciones y exportaciones. De hecho, el propósito de tener una conversión en una instancia de SDO DataObject fuera de la implementación del flujo es que los flujos de mediación se pueden crear sin conocimiento del protocolo y el formato con el que se envían los mensajes hacia y desde el módulo de mediación.
Una condición de activación a nivel de negocio permite que la arquitectura SOA 2.0 establezca inteligencia de clientes en tiempo real , automatización de marketing y soluciones de fidelización de clientes, entre otras funciones. Los objetos de negocio modelan entidades del mundo real en la arquitectura, como clientes, cuentas, préstamos e itinerarios de viaje. Cuando el estado de uno de estos objetos cambia y un agente de monitoreo nota que este cambio es significativo (en comparación con la lista de criterios a monitorear), se crea un evento y se pasa a otros agentes de monitoreo.
Por ejemplo, la detección de un problema o una oportunidad de negocio real podría generar un aumento de los ingresos. Si un cliente cancela un pedido, la capacidad de fabricación adicional podría reducir la rentabilidad de la producción. Un evento SOA 2.0 podría notificar al departamento de marketing para que cree una campaña de ventas especial que revenda la capacidad excedente, recuperando así el costo por unidad rentable original.
Monitoreo automático de eventos en las actividades de los procesos operativos de negocios a medida que se ejecutan los procesos para ver si es necesario tomar alguna acción inmediata, ya sea dentro o fuera de la empresa. Estos agentes de monitoreo prueban continuamente las condiciones comerciales específicas y los cambios en las operaciones comerciales. Si es necesario, los agentes alertan a las personas, hacen recomendaciones, envían mensajes a otras aplicaciones o invocan procesos comerciales completos cuando ocurren dichas condiciones o cambios.
Un proceso de negocio activado debería respaldar directamente el crecimiento de los ingresos con contención de costos, capacidad de respuesta a las condiciones comerciales o capacidad para buscar nuevas oportunidades de mercado. Los procesos de negocio resultantes también podrían medir el progreso operativo hacia el logro de objetivos, controlar los costos operativos comunicando solo lo que se necesita a quienes necesitan saberlo o informar el estado del desempeño de los procesos clave a los principales tomadores de decisiones.
Por ejemplo, podría crear un evento de CRM a partir de un mensaje de "carrito de compra abandonado" (analizando la transacción, el ID del cliente y la hora), utilizando otros filtros para extraer el valor de los productos en el carrito y aprovechando las capacidades de correlación del sistema para agregar indicadores causales, como si el sitio de comercio estaba sufriendo problemas de rendimiento. Su evento de CRM también podría incluir el valor del cliente o la clasificación de la base de datos de clientes...
Como otro ejemplo, basándose en los tipos de llamadas de servicio independientes recibidas, la plataforma SOA 2.0 podría identificar un defecto del producto detectando el patrón subyacente de las quejas separadas y luego activando una alerta a ingeniería o producción sobre el posible defecto.
Un mecanismo que se puede utilizar en la mayoría de las implementaciones de Enterprise Service Bus de SOA 1.0 es la función de publicación/suscripción . Al implementar la funcionalidad de ESB como mensajes de publicación/suscripción, no se necesita ningún conocimiento avanzado de los eventos del sistema para crear patrones de mensajes de SOA 2.0. Una vez que una empresa ha implementado muchas funciones de publicación, los analistas de middleware de SOA pueden dedicarse a la tarea de diseñar estrategias para determinar cuáles de los mensajes de publicación disponibles se podrían ensamblar en un patrón único para detectar un disparador enriquecido con SOA 2.0.
La mecánica del motor de vectores causales (CVE) se implementa de manera sencilla, con una vista expandible de las construcciones SQL escritas en procedimientos almacenados . [4] Si A causa B y la causalidad debe ocurrir dentro de N número de transacciones, entonces la cláusula de marca de tiempo ORDER BY de SQL crea un conjunto de resultados que incrementa un contador de todas las transacciones que ocurrieron dentro de un período de tiempo, N número de transacciones coincidentes de B con la ocurrencia de A. La creación de procedimientos almacenados adicionales se logra a través de la aplicación de consola CVE o utilizando cualquier kit de herramientas de desarrollador de bases de datos estándar. [5]
Los algoritmos de dominio, como la lógica de dominio de fiebre/gripe/infección en la referencia citada, se utilizan para derivar código SQL que aplica las reglas de negocio seleccionadas al caso de uso. El uso de CVE en entornos SOA mejora la agilidad empresarial porque la aplicación de los principios de SOA 2.0 identifica oportunidades de negocio que de otro modo se habrían pasado por alto o se habrían identificado mucho más tarde. [6]
La resonancia magnética funcional (fMRI) mediante el análisis de causalidad de Granger (GCA) detecta efectos causales entre regiones cerebrales. Los resultados de una prueba de muestra demostraron un efecto causal positivo entre la rFIC y la corteza cingulada anterior dorsal (dACC). [7]
El motor analítico Oracle CVE utiliza un conjunto de modelos teóricos, cada uno de los cuales evalúa algunos o todos los datos. Cuando un analista de negocios configura factores causales, especifica criterios que indican qué modelos deben considerar qué factor causal. [8]