IBM ISII Complex Event Processing: De la detección de eventos a la acción inmediata

Analizando el impacto en la detección de eventos complejos

Este artículo tiene como propósito describir los conceptos alrededor de IBM InfoSphere Identity Insight Complex Event Processing (Antes conocido como Entity Analytic Solutions – EAS), así como de demostrar con un ejemplo práctico, el potencial que este motor de procesamiento de eventos y/o situaciones representa para cualquier organización interesada en aportar mayor valor a su información, detectando diversas operaciones/transacciones en tiempo real como pueden ser : transferencias de dinero sospechosas, detección de fraude, análisis de tendencias de mercado, satisfacción al cliente, protección de ataques cibernéticos, entre muchos otros casos más.

Ricardo Barranco Fragoso, IT Specialist for Information Management, IBM Software Group México

Photo of Ricardo Barranco FragosoRicardo Barranco Fragoso es IT Specialist para Information Management de IBM Software Group México, a partir de Diciembre de 2010. De las principales soluciones en las que está enfocado se encuentran: MDM, MDM for PIM, Identity Insight, Initiate MDS, GNR e Infosphere Streams; y como este rol participa activamente apoyando las actividades de preventa. Con más de 7 años de experiencia y previo a su incorporación a IBM, Ricardo ha participado en diversos proyectos de software como Desarrollador Senior, Líder Técnico y Arquitecto Jr. utilizando principalmente tecnología Java Enterprise Edition y Rich Internet Applications. Ricardo cuenta con una Licenciatura en Computación por la Universidad Autónoma Metropolitana - Iztapalapa.



25-07-2011

1. Introducción

Existen muchas aplicaciones hoy en día en las cuales se opta por procesar eventos de manera aislada. Ejemplos de eventos se encuentran en la mayoría de las acciones generadas diariamente: una transacción bancaria, una llamada telefónica, una reservación de un vuelo,etc. Sin embargo, gran parte de los motores de reglas de negocio permiten que las aplicaciones respondan a un único evento, no existen muchos sistemas disponibles para manejar la correlación entre múltiples eventos, especialmente cuando dichos eventos son de varios tipos, y mejor aún, si son originados de diversas fuentes.


2. Complex Event Processing

2.1 Definición

Identity Insight Complex Event Processing™ (CEP) es un motor ágil y ligero para el procesamiento complejo de eventos. CEP extiende el paradigma de un mensaje a la vez, detectando situaciones complejas que involucran una composición de mensajes y eventos en diferentes contextos (contexto semántico, contexto temporal, contexto espacio-temporal); lo que permite observar y actuar en tiempo real no sólo en un único evento, sino en una composición compleja de eventos, que suceden en distintos momentos y contextos. Por ejemplo, se podría definir una regla de negocio que vaya acumulando las transferencias de dinero por un cliente sobre un determinado periodo de tiempo, y generar una alerta si la cantidad total excede el límite legal permitido.

Es preciso indicar que al hablar acerca de un motor de reglas y del procesamiento de reglas específicas de negocio, se pueda confundir entre BEP (Business Event Processing) y CEP; ambos términos corresponden a significados distintos, mientras que el primero se refiere a la orquestación de procesos, el segundo está orientado a la detección de situaciones complejas; no obstante, es posible que CEP como parte de la respuesta a la detección del evento invoque un workflow de BEP.

Figura 1. Estructura de una aplicación utilizando CEP[4]
Estructura de una aplicación utilizando CEP[4]

2.2 Componentes básicos de CEP

Identity Insight CEP™ incluye una herramienta de desarrollo basada en Eclipse (build-time) para simular y probar las reglas que serán definidas (también conocido como AMiT ), y un motor basado en Java (runtime) que recibe la información sobre la ocurrencia de eventos, detectando situaciones y reportando las situaciones detectadas a fuentes externas. (Ref. [1])

Figura 2. Procesamiento de eventos con CEP[3]
Procesamiento de eventos con CEP[3]

¿Pero cómo podemos diferenciar un evento de una situación?, para entender los componentes base alrededor de CEP revisemos a detalle los siguientes conceptos: Ref. [2]

  • Events (Eventos): Un evento es una ocurrencia dentro de un sistema o dominio particular; algo que ha sucedido o que está sucediendo en dicho dominio.
  • Event Grouping Keys (Llaves): Utilizadas para asociar varios eventos en conjunto dentro de todos los eventos que son procesados; es decir, nos permite asociar varios eventos relacionados a un área específica (banco, aeropuerto, ATM, etc).
  • Lifespans (Duración): Es el período de tiempo en el que estamos interesados en determinar si una situación existe. En este período se define cuando comienza y termina o bien si nunca tiene un fin.
  • Situations (Situaciones): Es la ocurrencia de un evento que pueda requerir una reacción. Utilizados para definir las reglas especificando (si es el caso) la duración y listando los eventos que deban o no ocurrir, para detectar una situación en concreto.

En resumen, una situación es una condición que está basada en una serie de eventos que han ocurrido dentro de una ventana dinámica de tiempo denominada lifespan. (Ref. [1])

Por lo tanto podemos decir que, el procesamiento de eventos (event processing) es utilizado para monitorear un sistema o proceso fijándonos en el comportamiento excepcional y generando alertas cuando dicho comportamiento ocurre.

Encontramos eventos todo el tiempo en nuestra vida cotidiana, algunos eventos son simples: una llamada telefónica, la recepción de un correo electrónico; y algunos otros son más inesperados: un asalto a una tienda, el retraso en un vuelo ocasionando la pérdida del vuelo de conexión. El concepto de evento se vuelve aún más poderoso cuando se logran modelar las situaciones a las que podemos enfrentarnos en el mundo real. Los siguientes son sólo algunos de los ejemplos de eventos que CEP puede monitorear y detectar:

  1. Programa de personalización de diagnóstico: El médico puede configurar cierto sistema, donde un paciente está conectado a múltiples monitores de manera que la enfermera reciba una alerta si una combinación específica de mediciones son detectadas durante cierto intervalo de tiempo.
  2. Transferencias de dinero sospechosas: Envío de notificaciones si el valor total de los retiros bancarios (ATM, cheques,etc) excede $X monto en los últimos Y días (donde X e Y son parámetros definidos por el cliente).
  3. Detección de Fraude: Envío de notificaciones si 2 o más compras con una misma tarjeta de crédito fueron realizadas en un periodo de una hora a una distancia mayor a 200 km.
  4. Tendencia del mercado financiero: Decidir sobre la compra o venta de acciones si existe una diferencia de más de 5% entre los valores de la misma acción en diferentes mercados, donde la diferencia de tiempo de los valores reportados es menor a 5 minutos.
  5. Satisfacción al cliente: Envío de una alerta si la misma solicitud fue reasignada a 3 agentes y aún no se ha respondido al solicitante en una ventana de tiempo de un día.
  6. Amenaza cibernética: Detección de una dirección IP accesando continuamente a una intranet empresarial la cual está relacionada con la dirección IP de un empleado que salió de la compañía hace 2 semanas.

2.3 Razones para implementar el procesamiento de eventos

Seguramente uno de los principales cuestionamientos es el porqué es que habría de utilizar el enfoque del procesamiento de eventos en sus sistemas. Estas son algunas razones: (Ref. [4] )

  • Si su aplicación requiere identificar y reaccionar a situaciones específicas donde el estado del cambio sea monitoreado; es decir, que la aplicación responda de manera oportuna más que un procesamiento por lotes (batch approach) donde el proceso de detección se ejecuta solamente de forma intermitente.
  • El procesamiento de eventos puede ser una forma de extender sus aplicaciones existentes de una manera flexible y no invasiva. La funcionalidad adicional puede entonces ser implementada procesando los eventos generados por los productores de los mismos.
  • La lógica de procesamiento intermediaria puede ser separada del resto de la aplicación. Esto permite que su aplicación se adapte rápidamente a nuevos requerimientos de negocio.
  • Un enfoque basado en eventos (Event-Driven Architecture) permite que el procesamiento sea ejecutado de forma asíncrona, de manera que encaja muy bien en aplicaciones donde los eventos suceden irregularmente. Logrando así, una respuesta más precisa, mejor rendimiento y flexibilidad al aislar la lógica de procesamiento de los eventos del código aplicativo.

3. Alertamiento transaccional en tiempo real: Un paso adelante contra el crimen

Uno de los ejemplos de crimen organizado más recurrente es el lavado de dinero. El lavado de dinero ocurre en casi la mayor parte del mundo, y un esquema sencillo típicamente consiste en transferir dinero a diversos países con el fin de “maquillar” sus orígenes.

El lavado de dinero se puede describir como el acto de generar dinero proveniente de un “Origen A” haciendo que parezca que proviene de un “Origen B”. (Ref. [6])
Existen muchas técnicas de lavado de dinero conocidas por los departamentos de inteligencia y probablemente innumerables otras más que aún no han sido descubiertas. Las siguientes son algunas de las técnicas más populares: (Ref. [6])

  • Black Market Colombian Peso Exchange: Un traficante intercambia dólares a un distribuidor (broker) en Colombia. El distribuidor utiliza este dinero para adquirir bienes en el país de origen del dinero; una vez que estos bienes son recibidos y vendidos en pesos en Colombia, se paga el correspondiente monto al distribuidor. El distribuidor entrega al traficante el equivalente en pesos colombianos (menos una comisión) del monto original en dólares que originó el proceso.
  • Structuring deposits: También conocido como smurfing (nombre atribuido a la serie de t.v. “Los pitufos”). El dinero es depositado en una o más cuentas ya sea por varias personas (smurfs/pitufos) o por una sola persona (papá pitufo) durante un periodo prolongado de tiempo.
  • Overseas bank: Los lavadores de dinero envían dinero a través de varias cuentas cuyos países tienen leyes bancarias de privacidad, lo que significa que para todos los propósitos, estos países permiten el uso de la banca anónima.
  • Underground/alternative banking: Algunos países en Asia tienen sistemas bancarios alternativos legales y bien establecidos que permiten depósitos, retiros y transferencias no documentados.
  • Shell companies: Compañías falsas cuyo único propósito es lavar dinero recibiendo pagos por supuestos bienes y servicios.
  • Investing in legitimate businesses: Los lavadores de dinero algunas ocasiones sitúan el dinero sucio en negocios legítimos para tratar de limpiarlo. Hacen uso de grandes negocios como organizaciones sin fines de lucro o casinos donde manejan grandes cantidades de dinero siendo fácil mezclarlo, o bien, en negocios pequeños pero de flujo continuo de dinero como bares, centros de auto lavado, clubes nocturnos o agencias de cambio de cheques.

La figura 3 representa de manera gráfica cómo es utilizada la técnica de lavado de dinero denominada smurfing o micro-structuring.

Figura 3. Smurfing / Micro-structuring [6]
Smurfing / Micro-structuring [6]

Consideremos el ejemplo de la figura anterior con relación a la técnica de micro-structuring para demostrar cómo podemos hacer uso de IBM Identity Insight CEP™ de manera que se genere una alerta cuando esta situación sea monitoreada.

3.1 Caso práctico

Supongamos que queremos determinar un posible caso de micro-structuring en donde el límite de depósitos durante el mes sea de $30,000 pesos, y que además, el número de transacciones permitidas por la institución bancaria no exceda de 8 operaciones.
Este es un ejemplo sencillo, sin embargo el objetivo es entender el concepto detrás de CEP y mostrar que el detectar situaciones complejas aporta gran valor cuando se determinan los puntos críticos de alguna organización.
De acuerdo al ejemplo, las reglas que se deben definir son las siguientes:

  • Suma de las transacciones:                      Sum > 30,000
  • Demasiadas transacciones en el mes:     Count > 8

Para que el motor de CEP pueda interpretar y monitorear los eventos que serán definidos, es necesario generar un archivo en formato XML donde se indicarán todas las reglas a ser procesadas. No entraré en mucho detalle sobre la estructura de este archivo, sin embargo para mayor información puede dirigirse a las siguientes referencias (Ref. [7] [1] [2] [5] ).

El Listado 1 muestra las reglas necesarias para poder monitorear este evento:

Listado 1. Archivo XML de definición de eventos CEP
<?xml version="1.0" encoding="UTF-8"?>
<!--     Licensed Materials - Property of IBM		-->
<!--     (C) Copyright IBM Corp. 2007  All Rights Reserved.	-->
<amt xmlns="http://www.ibm.com/amt/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/amt/ amt.xsd">
  <domain>
    <eventTypes>
       <eventType name="EAS_START" updateDefinition="add">
         <identification createdBy="easdemo" createdOn="7/4/11"/>
         <attributeType name="UMF_LOG_ID" xsi:type="double"/>
       </eventType>
     	<eventType name="EAS_STOP" updateDefinition="add">
         <identification createdBy="easdemo" createdOn="7/4/11"/>
         <attributeType name="UMF_LOG_ID" xsi:type="double"/>
       </eventType>
       <eventType name="EVENT" updateDefinition="add">
        <identification createdBy="allen" createdOn="1/3/08" status="approved"/>
          <attributeType name="EVENT_ID" xsi:type="integer"/>
          <attributeType name="EVENT_TYPE" xsi:type="string"/>
          <attributeType name="ENTITY_ID" xsi:type="integer"/>
          <attributeType name="EVENT_REF" xsi:type="string"/>
          <attributeType name="EVENT_LOC" xsi:type="string"/>
          <attributeType name="EVENT_MEMO1" xsi:type="string"/>
          <attributeType name="EVENT_MEMO2" xsi:type="string"/>
          <attributeType name="EVENT_START_DT" xsi:type="date"/>
          <attributeType name="EVENT_END_DT" xsi:type="date"/>
          <attributeType name="EVENT_QTY" xsi:type="double"/>
          <attributeType name="EVENT_UNIT_VALUE" xsi:type="double"/>
          <attributeType name="EVENT_STATUS" xsi:type="string"/>
          <attributeType name="SYS_CREATE_DT" xsi:type="date"/>
          <attributeType name="EVENT_VALUE" xsi:type="double"/>
          <attributeType name="UMF_LOG_ID" xsi:type="double"/>
       </eventType>
       <eventType name="Transaction_Sum_Too_Large" updateDefinition="add">
          <identification createdBy="easdemo" createdOn="7/4/11"/>
          <attributeType name="ALERT_GROUP" xsi:type="string"/>
          <attributeType name="REASON_DESC" xsi:type="string"/>
          <attributeType name="EVENT_SIT_STATUS" xsi:type="string"/>
       </eventType>
       <eventType name="Transactions_Limit_Exceeded" updateDefinition="add">
          <identification createdBy="easdemo" createdOn="7/5/11"/>
          <attributeType name="ALERT_GROUP" xsi:type="string"/>
          <attributeType name="REASON_DESC" xsi:type="string"/>
          <attributeType name="EVENT_SIT_STATUS" xsi:type="string"/>
       </eventType>
     </eventTypes>
  </domain>
  <rules>
    <keys>
       <key name="UMF_LOG_ID" type="double" updateDefinition="add">
          <identification createdBy="easdemo" createdOn="7/4/11"/>
          <eventKey eventType="EAS_START" expression="EAS_START.UMF_LOG_ID"/>
          <eventKey eventType="EAS_STOP" expression="EAS_STOP.UMF_LOG_ID"/>
          <eventKey eventType="EVENT" expression="EVENT.UMF_LOG_ID"/>
       </key>
    </keys>
    <lifespans>
       <lifespan name="EASLifeSpan" updateDefinition="add">
          <identification createdBy="easdemo" createdOn="7/4/11"/>
             <initiator>
                <eventInitiator correlate="ignore" name="EAS_START" where=""/>
             </initiator>
             <terminator>
                <eventTerminator name="EAS_STOP" quantifier="each"  
                      terminationType="terminate" where=""/>
             </terminator>
             <keyBy name="UMF_LOG_ID"/>
       </lifespan>
    </lifespans>
    <situations>
     <situation certaintyThreshold="1" initialActivation="true" internal="false"
lifespan="EASLifeSpan" name="Transaction_Sum_Too_Large" persistent="false"
updateDefinition="add">
        <identification createdBy="easdemo" createdOn="7/4/11"/>
        <report detectionMode="immediate" repeatMode="once" where="EVENT.sum > 30000">
        <operandReport addToSum="true" average="" eventType="EVENT" max=""
      min="" override="false" partAvg="false" partMax="false" 				
      partMin="false" quantifier="each" retain="false" 					
      sampleMeasurementUnit="occurrences" sampleRate="1"
      sum="EVENT.EVENT_VALUE" threshold="MonthDiff(CurrentDate()
      ,EVENT.EVENT_START_DT) == 0"/>
            </report>
          <situationAttribute attributeName="ALERT_GROUP"
        expression=""DEFAULT""/>
          <situationAttribute attributeName="REASON_DESC"
        expression=""Possible microstructuring alert - Cumulative
        Value: $" ++ EVENT.sum"/>
          <situationAttribute attributeName="EVENT_SIT_STATUS"
        expression=""PENDING""/>
      </situation>
      <situation certaintyThreshold="1" initialActivation="true" internal="false"
lifespan="EASLifeSpan" name="Transactions_Limit_Exceeded" persistent="false"
updateDefinition="add">
          <identification createdBy="easdemo" createdOn="7/5/11"/>
          <nth detectionMode="deferred" quantity="9" repeatMode="once" where="">
             <operandNth counted="true" eventType="EVENT" override="false"
    quantifier="each" quantifierType="relative" retain="false"
threshold="MonthDiff(CurrentDate() ,EVENT.EVENT_START_DT) == 0" weight="1"/>
             <keyBy name="UMF_LOG_ID"/>
          </nth>
          <situationAttribute attributeName="ALERT_GROUP"
expression=""DEFAULT""/>
          <situationAttribute attributeName="REASON_DESC" expression=""Transactions
Limit Exceeded : " ++ EVENT.count"/>
          <situationAttribute attributeName="EVENT_SIT_STATUS"
expression=""PENDING""/>
     </situation>
   </situations>
  </rules>
</amt>

La parte más importante del xml anterior se encuentra dentro del bloque <situations> donde se definen dos situaciones para detectar este evento (situation report y situation nth), en ambas situaciones se establece el límite de la condición (threshold) como MonthDiff(CurrentDate() ,EVENT.EVENT_START_DT) == 0 para determinar las transacciones que se han generado sólo durante el mes en curso. Para la primer situación establecemos nuestra condición EVENT.sum > 30000 para indicar el límite del monto permitido; y en la segunda situación basta con indicar quantity="9" para determinar el número máximo permitido de transacciones, que en nuestro ejemplo es 8. En cada bloque de <situation> se deben indicar 3 atributos necesarios mediante el elemento <situationAttribute> cuyos nombres de atributos son (ALERT_GROUP, REASON_DESC, EVENT_SIT_STATUS) y en estos se definen el mensaje que será mostrado en la alerta, que para este ejemplo los mensajes son "Possible microstructuring alert – Cumulative Value: " y "Transactions Limit Exceeded : " respectivamente.

Una vez que nuestras reglas han sido definidas el siguiente paso es generar los datos de simulación con los que nuestro motor CEP estará monitoreando para determinar si se cumple alguna de ellas. El listado 2 muestra el ejemplo de un archivo tipo UMF, con los que típicamente procesa Identity Insight para la ingestión de datos, que no es más que un archivo XML en una estructura bien definida.

Listado 2. Formato de archivo UMF para carga de datos
        <UMF_ENTITY>
  <NAME>
    <NAME_TYPE>M</NAME_TYPE>
    <FIRST_NAME>JUAN</FIRST_NAME>
    <MID_NAME>C</MID_NAME>
    <LAST_NAME>PEREZ</LAST_NAME>
  </NAME>
  <Address>
    <ADDR_TYPE>H</ADDR_TYPE>
    <ADDR1>300  VIA ALMOS  DRAPT.607</ADDR1>
    <CITY>New York</CITY>
    <STATE>NY</STATE>
    <POSTAL_CODE>05614</POSTAL_CODE>
    <COUNTRY>USA</COUNTRY>
  </Address>
  <DSRC_ACTION>A</DSRC_ACTION>
  <DSRC_CODE>100</DSRC_CODE>
  <DSRC_REF>119</DSRC_REF>
  <DSRC_ACCT>119</DSRC_ACCT>
  <EVENT>
    <EVENT_TYPE>EVENT</EVENT_TYPE>
    <EVENT_REF>111-AAA</EVENT_REF>
    <EVENT_LOC>OHIO</EVENT_LOC>
    <EVENT_START_DT>2011-07-13</EVENT_START_DT>
    <EVENT_STATUS>PENDING</EVENT_STATUS>
    <EVENT_VALUE>6000</EVENT_VALUE>
    <EVENT_QTY>1</EVENT_QTY>
  </EVENT>
</UMF_ENTITY>
... 
        (Para ver todo el contenido del archivo UMF da clic aquí)

El listado anterior contiene los registros de 3 entidades(personas) que serán agregadas dentro de Identity Insight y como parte del documento UMF se anexa un bloque denominado <EVENT> donde se especifica la información del evento y los atributos que corresponden al mismo. Como podrá observar cada una de las entidades realiza diversas transacciones en fechas distintas y con distintos montos, el elemento <EVENT_VALUE> define la cantidad de la transaccion que en conjunto excede el límite de $30,000.

La figura 4 ejemplifica el contenido del archivo UMF de manera más detallada.

Figura 4. Diagrama de Entidades y Relaciones de Identity Insight
Diagrama de Entidades y Relaciones de Identity Insight

Después de que la carga de datos se ha realizado utilizando el documento UMF del Listado 2, en Identity Insight podemos visualizar el detalle de las entidades y sus relaciones obteniendo un panorama mucho más amplio de la información que se requiere analizar. Es posible notar en el gráfico anterior que las 3 personas agregadas comparten el atributo de dirección, y una de ellas posee el mismo número de identificación de un terrorista, el cual fue cargado previamente obtenido de una fuente de datos de listas negras.
Durante el proceso de carga de datos, el motor de CEP parsea cada uno de los bloques de elementos <UMF_ENTITY> del archivo UMF localizando los eventos registrados para que puedan ser procesados por las reglas que han sido anteriormente definidas y determinar si alguna situación se presenta para ejecutar la acción correspondiente a cada una de ellas.

En la figura 5 se logra finalmente observar mediante IBM Identity Insight Visualizer se despliegan las alertas relacionadas a los eventos generados notificando sobre cuáles registros en particular se logró determinar tal situación, permitiendo cambiar el estatus o la asignación de responsables de la alerta para su seguimiento desde el momento inicial de la notificación hasta la solución e identificación de las fuentes que la originaron.

También es posible integrar alguna aplicación externa que se encuentre monitoreando los servicios de alertamiento y notificaciones del motor de eventos CEP de manera que se logre aislar la interfaz de Identity Insight Visualizer y se implemente alguna GUI(Graphical User Interface) o bien, algún proceso que se adapte a las necesidades o a la base tecnológica de la organización, como por ejemplo: consumir los servicios de alertamiento para realizar notificaciones de correo electrónico o bien para integrarlas en alguna aplicación web que constantemente actualice en pantalla los resultados obtenidos.
En la figura 6 se muestra un pequeño ejemplo de una aplicación desarrollada en Java, que simplemente despliega una ventana de alerta con la información detectada.

Figura 5. Notificación de alertas de eventos con Identity Insight Visualizer.
Notificación de alertas de eventos con Identity Insight Visualizer.

(Haga clic para ver una versión ampliada de la figura 5.)

Figura 6. Integración de una interfaz externa a CEP para el alertamiento de eventos.
Integración de una interfaz externa a CEP para el alertamiento de eventos.

(Haga clic para ver una versión ampliada de la figura 6.)


4. Conclusiones

En este artículo se logró introducir en los conceptos básicos alrededor de Complex Event Processing y la manera en que IBM Identity Insight™ hace uso de este mecanismo obteniendo una solución más enriquecedora al momento de analizar información en grandes volúmenes siendo muy complicado de hacerlo sin una herramienta de apoyo.
Las aplicaciones que utilicen procesamiento de eventos complejos deben ser capaces de recopilar información, analizarla y reaccionar a los eventos conforme estos ocurran, así como de reconocer patrones – de lo más obvio a lo más complejo – de manera que puedan responder a ellos rápida y adecuadamente.

Complex Event Processing extiende las capacidades que ofrece IBM Identity Insight™ combinando el análisis y monitoreo de eventos en tiempo real con la resolución de entidades y relaciones.
Debido a que los escenarios relacionados con fraudes y amenazas a una organización se encuentran en constante cambio, CEP provee esa flexibilidad para definir los tipos de eventos que se quieren rastrear y de configurar las reglas de negocio para procesar dichos eventos y así generar las alertas, de manera que ya sean eventos sospechosos o eventos de interés particular, se pueda tomar la acción apropiada en el momento preciso para ayudar a su organización en la detención y seguimiento de intentos de amenzas o fraudes.


5. Referencias

  1. IBM Labs in Haifa. CEP User Guide. 2006
  2. Kip Yeackley. IBM Identity Insight CEP Enablement. Julio 2010
  3. IBM Research - Complex Event Processing (CEP) - Innovation Mattershttp://domino.watson.ibm.com/comm/research.nsf/pages/r.datamgmt.innovation.cep.html
  4. Opher Etzion, Peter Niblett. Event Processing in Action. Manning, 2011
  5. Asaf Adi, Opher Etzion. The Situation Manager Rule Language. IBM Research Laboratory in Haifa
  6. Layton Julia.“How Money Laundering Works”. Artículo http://money.howstuffworks.com/money-laundering.htm
  7. IBM Infosphere Identity Insight Information Center. Event Manager. http://publib.boulder.ibm.com/infocenter/easrr/v8r0m0/index.jsp?topic=/com.ibm.iis.ii.overview.doc/topics/eas_con_eventmanager.html

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=742719
ArticleTitle=IBM ISII Complex Event Processing: De la detección de eventos a la acción inmediata
publish-date=07252011