Planificación del uso de Common Event Infrastructure

Common Event Infrastructure facilita sucesos.

Por qué y cuándo realizar esta tarea

Common Event Infrastructure proporciona recursos para generar, propagar, conservar y consumir sucesos, pero no define los sucesos reales. Cuando planifique cómo se ha de utilizar Comon Event Infrastructure en el diseño de su sistema, debe comprender los conceptos de empresa relacionados y correlacionarlos con los componentes correspondientes del diseño de su sistema. Debe proporcionar la semántica de la gestión de sucesos definiendo los tipos de sucesos, los grupos de sucesos y su filtrado, dentro del contexto de una arquitectura de orígenes de sucesos y consumidores de sucesos.

Pasos para realizar esta tarea

  1. Identifique cada origen de suceso. El origen de suceso es la aplicación que crea el suceso. El origen de suceso pasa el objeto de suceso a la infraestructura de sucesos. La infraestructura de sucesos también almacena el objeto de sucesos en una base de datos para su recuperación posterior. El rol de la infraestructura de sucesos es pasar el objeto de suceso a las aplicaciones que expresan su interés por recibirlo.
  2. Identifique cada grupo de sucesos. Un consumidor de sucesos es un aplicación que puede utilizar la información que aparece en el objeto de sucesos. Los consumidores de sucesos generalmente procesan los sucesos desde diferentes orígenes de sucesos.
  3. Identifique la jerarquía de las esferas de correlación de sucesos y los identificadores para estas esferas. Los consumidor de sucesos pueden utilizar esferas de correlación de sucesos para correlacionar sucesos. En todos los sucesos, la clase ECSEmitter da soporte a la jerarquía de esferas de correlación mediante el almacenaje del identificador actual y del identificador padre de las esferas de correlación de un suceso.
    Nota: ECSEmitter y las funciones de esferas de correlación se proporcionan mediante el servicio de Sucesos y no a través del propio Common Event Infrastructure.

    Por ejemplo, una actividad BPEL (Business Process Execution Language) abre una esfera de correlación para la actividad actual que identifica la actividad con el ID de instancia de actividad. La esfera de correlación padre es la esfera de correlación de la instancia de proceso en nombre del cual se ejecuta la actividad. La esfera de correlación padre se identifica a partir del ID de instancia de proceso.

  4. Identificar cada grupo de sucesos. Un grupo de sucesos define las características (valores de propiedad) que puede contener todos los sucesos de interés para un tipo determinado de consumidor de sucesos. Se asignan políticas, por ejemplo, controles de acceso y normas de distribución, a los grupos de sucesos para personalizar el comportamiento de la infraestructura de sucesos para cada grupo de usuarios.

WebSphere proporciona un grupo de sucesos por omisión que se define para incluir todos los sucesos. Este grupo de sucesos se denomina Todos los sucesos.

La siguiente figura muestra la relación entre estos objetos:

Figura 1. La arquitectura de un origen de suceso (que crea sucesos), un consumidor de sucesos (que utiliza los datos del suceso) y un grupo de sucesos (que define las características y las políticas asociadas para cada tipo de suceso). Diagrama del flujo de sucesos, del origen al consumidor.

Condiciones de uso |


(c) Copyright IBM Corporation 2005, 2006.
Este centro de información está basado en tecnología Eclipse (http://www.eclipse.org)