SIU-Arai/Arquitectura

 Arquitectura de la plataforma

La siguiente imagen expone el detalle de la arquitectura general de la plataforma, así como la vinculación entre componentes internos, módulos del SIU y aplicaciones o sistemas externos.

Definición de los componentes

Existen dos componentes que son vitales para el funcionamiento de la plataforma.

• Arai-Registry: Repositorio central de servicios y aplicaciones
• Arai-Usuarios: Proveedor y Administrador de Identidad (término del IdP e IdM) para toda la plataforma. Destaca la provisión del servicio de ingreso único (Single Sign On)

A partir de allí, es posible encontrarse con otros módulos que la complementan.

• SIU-Huarpe: es el portal de la plataforma, punto de acceso único para los usuarios y concentrador de diversos servicios ofrecidos
• SIU-XXX: toda aplicación del SIU capaz de ser integrada a la plataforma, conocido aquí como módulo.

También pueden ir apareciendo en escena futuros módulos o componentes que ofrezcan servicios puntuales. La plataforma es totalmente flexible en este punto. En todos los casos, los servicios ofrecidos han de implementar protocolos de comunicación basados en el estándar REST. Esto es lo que permite lograr el despliegue de una arquitectura basada en servicios (Service Oriented Architecture).

Configuración de dependencias y Servicios

La plataforma cuenta con ARAI-Registry como un componente dedicado al manejo del catálogo de dependencias y servicios, así como su configuración. Tomemos como ejemplo la comunicación entre dos módulos, X e Y. Para que esto suceda, se tiene que resolver una serie de requerimientos como ser la autenticación, la ruta de acceso, entre otros. Se establece que el Módulo Y ya se encuentra registrado previamente a la plataforma.

Para lograr esta tarea, por medio de la librería arai-cli cada sistema desarrollado por el SIU cuenta con una serie de comandos de consola que permiten registrar un módulo a la plataforma SIU-Araí. El primero es registry:add y lo que realiza es el registro del módulo en el catálogo de servicios de ARAI-Registry. Al registrar, el módulo indica si se trata de:

• una aplicación
• si provee o consume un servicio (como de SSO),
• si provee y/o consume una API tipo rest

En los casos que sea necesario, el módulo indica también su punto de acceso (conocido como endpoint), así como las credenciales que posee o con las cuales desea consumir algo.

Nota: el comando registry:add sólo se ejecuta la primera vez. Luego se utiliza un comando distinto para mantener sincronizado los datos.

Una vez registrado el módulo, se procede a su sincronización con el catálogo de servicios en ARAI-Registry. Para ello se ejecuta otro comando, registry:sync, que se encarga de tomar las definiciones del módulo y procesarlas (si ofrece servicios, informarle sobre posibles consumidores; si los consume, informarle de los puntos de acceso y mecanismos de autenticación, etc).

Nota: siempre que los datos de acceso del módulo cambien, se incorporen nuevos proveedores o consumidores, se ha de ejecutar la sincronización para actualizar los datos. ARAI-Registry de ninguna forma enviará esta información de manera pro-activa, como en el caso del ejemplo para informar al Módulo Y.

A partir de este punto el Módulo X es capaz de conectarse de forma directa al Módulo Y para consumir sus recursos (por ej, una API rest). En tal caso, las credenciales del cliente serán conocidas para el servidor, lo que validará el intento de acceso a dicho recurso.

Nota: este ejemplo supone que Módulo Y ya se registró al catálogo de servicios de ARAI-Registry como proveedor de una API rest. También supone que se ejecutó una sincronización en Módulo Y luego de haberse sincronizado el Módulo X.

El catálogo de servicios ARAI-Registry, como se explicó hasta ahora, no se entromete en la comunicación directa entre los módulos de la plataforma. Simplemente brinda un mecanismo de descubrimiento y configuración de servicios. Toda la comunicación posterior entre módulos, pasa de forma desapercibida para el resto la plataforma.

< Volver