Esta sección presenta vistas estáticas y dinámicas de la arquitectura del prototipo G-EEG. Las primeras definen los componentes principales y sus relaciones. Las segundas definen cómo interactúan los componentes intercambiando mensajes. Asimismo, se presenta el diseño detallado de componentes de la arquitectura en términos de clase y sus asociaciones, e interacciones entre instancias de clases para proveer interacción de componentes como se recomienda en la vista dinámica de la arquitectura.
La vista estática de la arquitectura comprende Capa de Negocios, Capa de Persistencia yAdministrador, todas interactuando con Aplicaciones Externas. La vista es descripta en la Figura 65 y explicada a continuación:
Figura 65: Arquitectura del Prototipo G-EEG – Vista Estática
o Capa de Negocios – Incluye tres componentes. (1) Core implementa servicios de mensajería básicos llevados a cabo con diferentes tipos de miembros o canales, exceptuando las respuestas del Administrador. Ofrece tres interfaces: I-Visitor, I-Administrative and I-Extend, todas usadas por las aplicaciones externas (External Application) y el administrador (Administrator). Adicionalmente, utiliza los listeners implementados por aplicaciones externas (ApplicationListener) y la aplicación que implementa el administrador (AdminListener), también utiliza la interfaces provista por el manejador de la base de datos (I- Database) y el repositorio de formato de mensajes (Message Formats). (2) Extend implementa los servicios para habilitar, configurar y deshabilitar extensiones, ofrecidos por dos interfaces (I-MemberExtension y I-
Channel Extension) usadas por Core. Como Core, utiliza la interface de la base de datos I-Database y el repositorio de formato de mensajes. (3) Message Formats define la estructura de varios tipos de mensajes.
o Capa de Persistencia – Maneja la persistencia de datos por medio del componente Database. El
componente incluye una base de datos local y ofrece sus servicios a través de la interface I-Database, usadas por Core y Extend.
o Administrador – El paquete incluye dos componentes: (1) Administator Member implementa el comportamiento del miembro administrador, esencialmente para responder a los requerimientos de los miembros; y (2) Administrator Database maneja el repositorio central que almacena toda la información
relacionada a los miembros existentes, canales y extensiones. Ofrece la misma interface que Database (I- Database), que es usada por Core.
Una vista dinámica de la arquitectura se presenta en la Figura 66. El siguiente intercambio de mensajes ilustra los tres escenarios principales de G-EEG – registración de miembros, creación de canales, y suscripción de miembros a canales, como sigue:
1) Registración de Miembro – El escenario es disparado por una aplicación externa – External Application A, requiriendo registrar un miembro a través de I-Visitor – 1:registerMember. Recibido por el componente
Core – 1.1:registerMember, el requerimiento es reenviado al miembro administrador – Administrator Member – 1.2:send(registerMember) el cual asigna un identificador al nuevo miembro y envía la respuesta –
1.3:send(replyRegisterMember). Al recibir la respuesta satisfactoria del miembro administrador, un nuevo
miembro es instanciado por el componente Core – 1.4:newMember.
2) Creación de Canal – Después de registrar un miembro, External Application A solicita a través de la
interface I-Administrative la creación de un canal – 2:createChannel. Recibido por el componente Core
– 2.1:createChannel, el requerimiento es reenviado al miembro administrador –
2.2:send(createChannel) el cual asigna un nuevo identificador al canal y envía una respuesta – 2.3:send(replyCreateChannel). Al recibir el mensaje, el nuevo canal es creado – 2.4:newChannelOwned. 3) Suscribir Miembro a Canal – Después de registrado el miembro y creado el canal, External Application B
solicita suscripción al canal por medio de I-Administrative – 3:subscribe. Una vez recibido por Core–
3.1:subscribe, el requerimiento es reenviado al miembro administrador – 3.2:send(request Subscription)el cual a su vez, lo reenvía al propietario del canal – 3.3:send(requestSubscription), un
componente de Core. Core, por medio del propietario, suscribe al miembro al canal – 3.4:newSubscriber, y responde al miembro administrador – 3.5:send(replySubscription) el cual lo reenvía al componente que solicitó la suscripción – 3.6:send(replySubscription). Una vez recibida la respuesta satisfactoria, se crea un
nuevo objeto para manejar el canal suscripto – 3.7:newChannelSubscribed.
La Figura 67 a continuación representa el diseño detallado del prototipo G-EEG con la estructura completa propuesta para los principales componentes de la arquitectura – Core, Extend, Database y Message Formats en términos of clases and asociaciones.
Figura 67: Diagrama de Clases de Diseño
Los cuatro componentes ofrecen en conjunto una variedad de servicios de mensajería para aplicaciones externas –
External Application – servicios de visitante para registrar y recuperar miembros (I-Visitor); servicios administrativos para crear y destruir canales, suscribir y des-suscribir miembros a/de canales, des-registrar miembros y reenviar mensajes (I-Administrative); servicios básicos para enviar y recibir mensajes (I-SendReceive); y servicios de extensión para habilitar, configurar y deshabilitar extensiones basadas en canales y miembros (I- ChannelExtension e I-MemberExtension).
Core utiliza la interface ApplicationListener para pasar los mensajes recibidos y los resultados de los servicios a
las aplicación externas. Implementado por External Application, una instancia de ApplicationListener es creada cada vez que la aplicación solicita registrar o recuperar un miembro. Core contiene las siguientes clases: 1) Visitor – Provee la implementación de servicios ofrecidos por la interface I-Visitor, con atributos para
almacenar el nombre, identificador y dirección física de un miembro.
2) Member – Adicionalmente a los atributos previos, incluye tablas con datos acerca de canales suscriptos y
poseídos por un miembro, e implementa los servicios ofrecidos por la interfaces I-Administrative e I- SendReceive.
3) Channel – Una clase abstracta, define las relaciones entre miembros y canales usados por ellos, e incluye las
4) ChannelOwned – Una sub-clase concreta de Channel, contiene atributos para almacenar el identificador y la dirección física del propietario y todos los suscriptores de un canal. Implementa métodos para enviar y recibir mensajes.
5) ChannelSubscribed – Una sub-clase concreta de Channel, contiene atributos para almacenar el identificador
y la dirección física del propietario del canal.
6) Message – La clase provee operaciones para obtener elementos individuales de un mensaje XML. 7) ClientSocket – Implementa un socket cliente para enviar mensajes en nombre de un miembro.
8) ServerSocket – Implementa un socket servidor, verifica continuamente si un miembro recibe algún mensaje. Como el prototipo sólo implementa extensiones orientadas a canal, Extendincluye las siguientes clases:
1) ChannelExtensionManager – Contiene un atributo que almacena todas las extensiones orientadas a canal habilitadas en un canal dado. La clase implementa métodos para habilitar y deshabilitar extensiones sobre canales y para procesar los mensajes de acuerdo a todas las extensiones habilitadas.
2) ChannelExtension – Una clase abstracta que define las operaciones que debe implementar cada extensión concreta orientada a canal como processMessage y configureExtension.
3) Adicionalmente, Extendincluye tres subclases concretas de ChannelExtension - Auditing, Validation y
Transformation que implementan las extensiones de auditoría, validación y transformación, respectivamente. El componente Message Formatsmantiene definiciones XML para todos los tipos de mensajes y archivos de configuración. Incluye cuatro clases: (1) Message define y procesa la estructura de todos los mensajes interpretados por G-EEG; (2) MessageReply define la estructura de todos los mensajes producidos por G-EEG para enviar a las
aplicaciones externas en respuesta a requerimientos de servicio; (3) UserMessage – define el cuerpo de todos los mensajes generados por las aplicaciones externas a ser transferidos por medio de G-EEG, y (4) Parámetros – define el archivo de configuración del prototipo.
El componente Database define clases para el mapear objetos a tablas de una base de datos relacional para almacenar datos en la base de datos. Este paquete contiene una clase por cada tabla definida en la base de datos: (1)
Member, (2) ChannelOwned, (3) ChannelSubscribed, (4) Subscriber, (5) ChannelExtension y (6)
ExtensionParameter.
Diagramas detallados de secuencia que describen el comportamiento del sistema para crear canales, enviar y recibir mensajes y habilitar extensiones de canal, son presentados y explicados en el Apéndice C.