SOA impulsada por eventos es una forma de arquitectura orientada a servicios (SOA), que combina la inteligencia y la proactividad de la arquitectura impulsada por eventos con las capacidades organizativas que se encuentran en las ofertas de servicios . Antes de SOA impulsada por eventos, la plataforma SOA típica orquestaba los servicios de forma centralizada, a través de procesos de negocio predefinidos, asumiendo que lo que ya debería haberse activado se define en un proceso de negocio. Este enfoque más antiguo (a veces llamado SOA 1.0) no tiene en cuenta los eventos que ocurren dentro o fuera de procesos comerciales específicos. Por lo tanto, los eventos complejos, en los que un patrón de actividades, tanto programadas como no programadas, deben desencadenar un conjunto de servicios, no se tienen en cuenta en la arquitectura SOA 1.0 tradicional.
SOA 2.0
La arquitectura SOA 2.0 ("SOA impulsada por eventos") permite a los usuarios comerciales monitorear, analizar y enriquecer eventos para establecer conexiones entre eventos dispares que al principio no parecen ser intuitivamente obvios. Esto hace que estos eventos enriquecidos sean visibles para otros, especialmente analistas de negocios o directores de marketing, y también permite que el sistema SOA 2.0 automatice posiblemente las acciones a tomar para abordar algún patrón único. [1]
SOA 2.0 es la capacidad de crear eventos comerciales de alto nivel a partir de numerosos eventos del 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éndolos con detalles definitorios como dependencias o relaciones causales descubiertas al correlacionar otros eventos.
Si está claro, a través de los eventos enriquecidos que son producidos por un entorno SOA 2.0, que la tasa de abandono del carrito de compras 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 los competidores han hecho para hacer que los clientes compren. productos en otros lugares. ¿Había un producto común en la mayoría de los carritos de la 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 vector causal, 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 del vector causal verifica si el índice de la regla del 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 sondear las solicitudes de cambio), la SOA controlada por eventos permite que los sistemas y componentes respondan dinámicamente, en tiempo real, a medida que ocurren los eventos. SOA 2.0 complementa y amplía SOA 1.0 al introducir capacidades de procesamiento de larga duración.
La capacidad de procesamiento de larga duración permite a la arquitectura recopilar varios eventos asincrónicos durante un período prolongado y correlacionar 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 cumplen ciertos criterios, desencadenar 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 de eventos y consumidores de eventos: al consumidor de eventos no le importa dónde o por qué ocurre un evento; más bien, le preocupa que se invoque cuando se produzca el evento. Los sistemas y aplicaciones que separan a los productores de eventos de los consumidores de eventos generalmente dependen de un canal o despachador de eventos. Este canal contiene una cola de eventos que actúa como intermediario entre los productores de eventos y los controladores de eventos.
Paradigma prototípico de SOA 2.0
El paradigma prototípico de SOA 2.0 contiene cuatro elementos esenciales:
- múltiples eventos del sistema de bajo nivel que, por separado, no parecen tener ninguna relación, pero a través de la detección de patrones al comparar estos muchos eventos, se hace evidente una correlación inusual o menos obvia;
- cierta cantidad de enriquecimiento de datos mediante la infusión de información relacionada con cada evento para ilustrar más claramente cómo se relacionan los muchos eventos;
- una condición de activación que, cuando no se cumple, no se crea el evento de nivel empresarial, pero cuando se cumple la condición de activación, se crea el evento de negocio de nivel superior;
- algún proceso humano o automatizado que se invoca cuando se alcanza el evento desencadenante.
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 empresarial 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.
La coreografía, por otro lado, no depende de un coordinador central. Más bien, cada servicio SOA 2.0 involucrado en la coreografía sabe exactamente cuándo ejecutar sus operaciones (según los 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 de negocio, las operaciones a ejecutar, los mensajes a intercambiar y la sincronización de los intercambios de mensajes.
BPEL sigue el paradigma de la orquestación. La coreografía está cubierta por otros estándares, como WSCI (Interfaz de coreografía de servicios web) y WS-CDL (Lenguaje de descripción de coreografía de servicios web).
Múltiples eventos del sistema de bajo nivel
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 de lo que puede hacerlo la capacidad computacional artificial actual. Uno de los obstáculos fundamentales en la inteligencia artificial es la ausencia de una capacidad automatizada para relacionar eventos juntos como cuando un humano usa la intuición humana.
Al utilizar un motor de vector causal, la percepción de la causalidad se puede mejorar en condiciones espacio-temporales apropiadas basadas en reglas estructurales y temporales escritas en el motor. La percepción de la semántica causal compleja, como las causalidades aditivas, mediadas y bidireccionales, debe codificarse para 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 reproduce 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 vector causal procesa varios eventos del sistema de bajo nivel y los compara con estas reglas para desencadenar eventos comerciales de nivel superior. Lo hace a través de una aplicación de consola Causality Vector Engine (CVE) que muestra eventos en tiempo real a los analistas de negocios. Donde se pueden observar flujos de eventos a medida que ocurren, al igual que un indicador de cotización, la aplicación de la consola CVE tiene varias ventanas que enumeran los mismos eventos en diferentes contextos, por lo que los analistas de negocios pueden ver qué está haciendo el CVE con las relaciones entre ellos.
La ventana secuencial muestra los eventos en orden de fecha y hora, una o más ventanas en varios órdenes mientras el CVE trabaja a través de la lista de reglas y crea relaciones implícitas entre los eventos. Existen varios botones y controles en la aplicación de la 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 infundir detalles de definición adicionales a través de 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 administrar el riesgo. En SILK se puede ver un ejemplo de aplicación y motor CVE. [2]
Enriquecimiento de datos
La mayoría de las implementaciones de bus de servicios empresariales (ESB) contienen una función llamada " mediación ". Por ejemplo, los flujos de mediación son parte de la intercepción del bus de servicios empresariales de WebSphere . Mule también apoya los 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; por lo general, las funciones se pueden implementar mediante el patrón de diseño de interceptación. [3]
A medida que los mensajes pasan por el ESB, el ESB enriquece los mensajes destinados a un canal que está monitoreando un evento empresarial 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, según el ID de cliente, el flujo de mediación de ESB podría obtener el código postal en el que reside el cliente. O, según la dirección IP de la solicitud de origen del usuario final, el flujo de mediación de ESB podría buscar en qué país, estado o condado en el que se encuentra la 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 empresarial de alto nivel que finalmente se desencadenará.
Flujos de mediación
Un flujo de mediación de ESB es uno de los tipos de componentes en 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 del enlace 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 por el bus .
Una vez que los desarrolladores hayan codificado el enlace personalizado tanto para la exportación como para la importación, pueden empezar a centrarse en el componente de flujo de mediación. En el editor de ensamblado de WebSphere Integration Developer , esto lo realiza el componente de mediación de enlace personalizado de JMS, donde cada operación en la interfaz del componente de flujo está representada por una solicitud y una respuesta.
El marco de Service Data Objects (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 y utilizar los datos. A través de SDO, los desarrolladores simplemente trabajan con datos de múltiples fuentes de datos, como bases de datos relacionales, componentes de entidad EJB, páginas XML, servicios web, la arquitectura de componentes de servicio y páginas de JavaServer Pages.
Los flujos de mediación son totalmente independientes de las vinculaciones 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 porque los flujos de mediación se pueden construir sin conocer el protocolo y el formato con el que se envían los mensajes hacia y desde el módulo de mediación.
Condición de activación a nivel empresarial
Una condición de activación a nivel empresarial permite que la arquitectura SOA 2.0 establezca soluciones de inteligencia de clientes , automatización de marketing y fidelización de clientes en tiempo real , entre otras características. 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 supervisión nota que este cambio es significativo (en comparación con la lista de criterios para supervisar), se crea un evento y se pasa a otros agentes de supervisión.
Por ejemplo, la detección de un problema u oportunidad empresarial 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 crear una campaña de ventas especial que revendería el exceso de capacidad, recuperando así el costo por unidad rentable original.
Monitoreo automático de eventos en las actividades operativas de los procesos comerciales a medida que se ejecutan los procesos para ver si es necesario tomar alguna acción inmediata dentro o fuera de la empresa. Estos agentes de supervisión 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 tales condiciones o cambios.
Proceso empresarial resultante
Un proceso comercial desencadenado debe 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 comerciales resultantes también podrían medir el progreso operativo hacia el logro de los objetivos, controlar los costos operativos comunicando lo que se necesita a quién necesita saberlo, o informar el estado de desempeño de los procesos clave a los tomadores de decisiones clave.
Ejemplos conceptuales de SOA 2.0
Carrito de compras abandonado
Por ejemplo, puede crear un evento de CRM a partir de un mensaje de "carrito de compras 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 tocando las capacidades de correlación del sistema para agregue indicadores causales, como si el sitio de comercio estaba sufriendo problemas de rendimiento. Su evento de CRM también puede incluir el valor del cliente o la clasificación de la base de datos de clientes ...
Defecto de ingeniería
Otro ejemplo, basado 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 la ingeniería o producción del posible defecto.
Implementaciones SOA 2.0
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 ESB como mensajes Pub / Sub, no se necesitan conocimientos avanzados de los eventos del sistema para crear patrones de mensajes SOA 2.0. Después de que una empresa ha implementado muchas funciones de publicación, los analistas de middleware de SOA pueden comenzar la tarea de diseñar una estrategia sobre 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 de Causal Vector Engine (CVE) se implementa de forma sencilla, con una vista ampliable de 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 B coincidentes con transacciones de ocurrencia A . La creación de procedimientos almacenados adicionales se logra a través de la aplicación de consola CVE o mediante el uso de un juego de herramientas estándar para desarrolladores de bases de datos. [5]
Aplicaciones médicas
Los algoritmos de dominio, como la lógica de dominio de fiebre / gripe / infección en la referencia citada, se utilizan para derivar el código SQL que aplica las reglas comerciales seleccionadas al caso de uso. El uso de CVE en entornos SOA mejora la agilidad empresarial porque la aplicación de los principios SOA 2.0 identifica oportunidades de negocio que de otro modo se habrían perdido o identificado mucho más tarde. [6]
La resonancia magnética funcional (fMRI) que utiliza el análisis de causalidad de Granger (GCA) detecta los efectos causales entre las regiones del cerebro. Los resultados de una prueba de muestra demostraron un efecto causal positivo entre rFIC y la corteza cingulada anterior dorsal (dACC). [7]
Inteligencia empresarial de Oracle
El Oracle CVE Analytical Engine utiliza un conjunto de modelos teóricos, cada uno de los cuales evalúa algunos o todos de los datos. Cuando un analista de negocios configura factores causales, especifica criterios que indican qué modelos deben considerar qué factor causal. [8]
Ver también
- Arquitectura orientada a Servicios
- Lenguaje de marcado de mashup empresarial (EMML)
Referencias
- ^ http://www.infoworld.com/t/architecture/make-way-soa-20-420
- ^ http://silk.semwebcentral.org/gui-ruleml-2010.pdf GUI de Causal Vector Engine como complemento de Eclipse.
- ^ E. Curry, D. Chambers y G. Lyons, "Ampliación del middleware orientado a mensajes mediante interceptación", presentado en el tercer taller internacional sobre sistemas distribuidos basados en eventos (DEBS '04), ICSE '04, Edimburgo, Escocia, Reino Unido 2004.
- ^ http://bicep.dei.uc.pt/images/5/58/FINCoS_DEBS2008.pdf Diseño de motor vectorial causal.
- ^ http://people.cis.ksu.edu/~bbp9857/bbp_hicss05.pdf Kit de herramientas algorítmicas de Causal Vector Engine.
- ^ http://people.cis.ksu.edu/~bbp9857/bbp_hicss05.pdf Lógica de dominio médico del motor vectorial causal.
- ^ Zang, ZX; Yan, CG; Dong, ZY; Huang, J; Zang, YF (2012). "Implementación del análisis de causalidad de Granger en MATLAB: un kit de herramientas de interfaz gráfica de usuario para el procesamiento de datos de fMRI". J. Neurosci. Métodos . 203 : 418-26. doi : 10.1016 / j.jneumeth.2011.10.006 . PMID 22020117 .
- ^ http://docs.oracle.com/cd/E18727_01/doc.121/e05136/T485796T488110.htm El motor de Oracle Business Intelligence hace un uso extensivo de datos temporales en intervalos de tiempo históricos y futuros.