Módulo 2. Arquitectura Introducción Objetivos o Analizar la arquitectura física y lógica de la plataforma Agrega. o Identificar los componentes más importantes de la arquitectura física. o Exponer las conexiones establecidas entre componentes físicos. o Explicar la estructura lógica de un nodo de Agrega. o Visualizar los módulos funcionales y el conjunto de servicios que ofrece Agrega. Contenidos o Introducción. o Arquitectura física. o Arquitectura lógica. 1. Introducción En el bloque actual describiremos la arquitectura física y lógica de un nodo de la plataforma. Un nodo operativo esta formado por un conjunto de servicios (que pueden ejecutarse en una o varias máquinas físicas o virtualizadas diferentes) formando así una aplicación web completa, el portal Agrega. Un nodo responde a la arquitectura de 3 capas o niveles empleada típicamente en los portales web: Capa servidor Web Capa de aplicación Capa de datos Apache, PHP (MediaWiki), Squid (caché opcional) JBoss Application Server, JDK 1.6, Galería de Imágenes NFS, Base de datos (MySQL), LDAP La capa del servidor web se encuentra formada por la aplicación de Apache, sobre la cual se instalará el módulo de PHP 5.X y la ayuda que se encuentra elaborada sobre la aplicación MediaWiki 1.12.0. En la capa de aplicación encontramos la JDK 1.6.0, el servidor de aplicaciones JBoss y por último la galería de imágenes. En secciones posteriores entraremos en detalle sobre los mismos. Por último, la capa de datos debe ofrecer un directorio compartido visible desde el Apache y el JBoss (típicamente vía NFS aunque valdrían otras soluciones), una base de datos (en nuestro caso MySQL) sobre la cual se crearán las tablas y usuarios tanto de la plataforma como de la ayuda MediaWiki, y por último debe existir un servicio de LDAP corriendo para la autenticación de los usuarios. Página 1 de 8
En la siguiente sección describiremos una arquitectura física modelo que puede no coincidir con la instalación real. Desde el punto de vista arquitectónico, se podrían instalar todas las capas en una misma máquina física, pero se desaconseja por razones tanto de rendimiento como de seguridad. 2. Arquitectura física La arquitectura física (modelo de referencia) que se plantea es la que se muestra en la siguiente figura: En el diagrama mostrado se ha optado por independizar cada servicio en una máquina diferente, no obstante, no es estrictamente necesario que en producción se dispongan de tantas máquinas físicas como servicios. Como regla general es conveniente dejar el servidor web Apache en la zona desmilitarizada (DMZ) por razones de seguridad, y en caso necesario el servidor que alberga la base de datos podría también albergar el LDAP. Debido a la carga de CPU, número de ficheros abiertos y número de conexiones se recomienda que el servidor JBoss se ejecute sobre una máquina física sin compartir recursos con otros servicios. Página 2 de 8
2.1. Apache Por razones de seguridad se propone que el servidor web Apache se instale en la zona desmilitarizada (DMZ). El servidor web atenderá peticiones en el puerto 80 (HTTP) y 443 (HTTPS). Accederá por medio de cortafuegos a la red interna al puerto 8009 (Conector AJP) del servidor de aplicaciones JBoss. Hay que tener en cuenta que la ayuda (MediaWiki) es un módulo PHP que se ejecutará sobre Apache y que realizará conexiones a la base de datos MySQL. Es posible crear una base de datos aislada para tal propósito, incluso instalarla en la propia máquina de Apache si no queremos abrir conexiones hacia nuestra base de datos interna. La mejor opción consiste en limitar el acceso de los usuarios a la base de datos por dirección IP. A la hora de instalar Apache debemos decidir si deseamos que sirva directamente los contenidos estáticos, para lo que será necesario que éstos se instalen en una partición compartida accesible tanto desde el JBoss como desde Apache, o si, por el contrario, por cada petición queremos que se redirija al JBoss (aunque se traten de contenidos estáticos tales como CSS, JS, GIF ). En función de una u otra opción será necesario o no configurar el espacio de disco compartido por NFS. 2.2. JBoss Application Server La aplicación del portal de Agrega se desplegará sobre el servidor de aplicaciones JBoss que se ejecutará con la versión JDK 1.6. Desde JBoss se necesitará tener acceso tanto al servidor LDAP (para autenticar a los usuarios) como a la base de datos MySQL (para autorizar, cargar contenidos, localizar, noticias, FAQ ). Es obligatorio que el servidor del JBoss disponga de un volumen montado con gran capacidad de almacenamiento (ya sea desde un servidor con un array de discos exportados por NFS o bien directamente discos locales al servidor). Si se decide que Apache sirva directamente los contenidos estáticos, es necesario que JBoss haga uso del directorio compartido exportado por NFS para que dichos contenidos puedan ser servidos directamente desde el servidor web. 2.3. Base de datos: MySQL La plataforma de Agrega necesita hacer uso de una base de datos, en concreto, de MySQL (es posible ejecutar el portal con otras bases de datos). En la base de datos del portal se albergarán las tablas relacionadas con el uso y funcionamiento de Agrega (auditoria, búsquedas realizadas, localizador de ficheros en disco, noticias, categorías, roles de usuarios ) y en la base de datos de la Mediawiki se almacenarán todos los textos de la ayuda. Hay que tener en cuenta que, al encontrarse la ayuda basada en el software libre de MediaWiki, se ejecuta directamente sobre Apache (es una aplicación PHP). Con el fin de asegurar al máximo la plataforma se sugiere que se configuren los usuarios de conexión desde la MediaWiki especificando las IPs permitidas y dando acceso únicamente a la base de datos de la MediaWiki. Página 3 de 8
2.4. LDAP El portal de Agrega se autentica contra el LDAP haciendo el uso de la operación bind. Si la comunidad autónoma ya dispone de un LDAP, durante la instalación bastaría con crear la nueva estructura del portal y los usuarios iniciales, configurando posteriormente el acceso al mismo desde la configuración del portal. Si no se tuviera ningún LDAP, se recomienda la instalación de OpenLDAP v2. 2.5. Servidor de ficheros: NFS En el caso de desear servir los ficheros estáticos directamente desde Apache, es necesario que algún servicio exporte vía NFS un directorio compartido montado desde Apache y JBoss. En ese directorio compartido encontraremos no sólo los ficheros estáticos de la apariencia del portal (CSS, JS, GIF ) sino que también encontraremos todos los recursos de los ODEs cargados en la misma (por ejemplo un recurso puede ser una secuencia animada flash, un fichero OGG, un vídeo AVI ). 2.6. Resumen de conexiones establecidas Las conexiones que se deben tener en cuenta en las conectividades (rutas) y reglas de los firewalls son las siguientes: Host Origen Puerto Origen Host Destino Puerto Destino * (ANY) * (ANY) Apache 80 * (ANY) * (ANY) Apache 443 Apache * (ANY) JBoss 8009 Apache * (ANY) MySQL 3306 * (ANY) * (ANY) JBoss 8080 JBoss * (ANY) LDAP 389 JBoss * (ANY) MySQL 3306 Con el fin de ilustrar las conexiones establecidas, mostramos la siguiente figura: Con el fin de ilustrar las conexiones establecidas, mostramos la siguiente figura: Página 4 de 8
3. Arquitectura lógica La plataforma se desarrolla con la tecnología Java (J2EE v1.4) y tiene una Arquitectura Orientada a Servicios (SOA) donde el papel del proveedor de servicios lo interpretará el Nodo de Objetos Educativos Digitales y el papel consumidor lo interpretarán las Aplicaciones Clientes, según el siguiente esquema: La Arquitectura Orientada a Servicios (SOA), define los servicios de los cuales estará compuesto el sistema y sus interacciones. Desde el punto de vista del consumidor, los servicios son conceptualmente similares a los componentes tradicionales, salvo que los servicios encapsulan sus propios datos y no forman parte, estrictamente hablando, de la aplicación sino que son utilizados por ésta. Otra de las facetas interesantes de la arquitectura SOA es que permite realizar aplicaciones modulares que exponen la lógica de negocio que se decida para ser consumida por terceros. Página 5 de 8
Destacamos el componente de Interfaz de Interoperabilidad que se basa en el estándar de interoperabilidad de Repositorios de IMS (IMS-DRI), que proporciona la funcionalidad básica para explotar los objetos digitales presentes en el repositorio (Buscar, presentar y almacenar). La tecnología que los implementa es la de Web Services que proporciona el sustento de servicios de una arquitectura orientada a servicios. Las búsquedas de contenidos se realizarán con un sistema federal basado en la especificación Simple Query Interface (SQI). Al estar SQI promovido por la Comisión Europea, su adopción facilitará la integración de la Plataforma en las redes europeas de repositorios educativos. En la definición de los servicios no incluidos en IMS DRI que deban incorporarse a la Interfaz de Interoperabilidad se tomará como fuente de inspiración las Open Service Interface Definitions (OSIDs) elaboradas por el MIT en Open Knowledge Initiative (OKI). El Nodo incorpora un repositorio que almacena los contenidos empaquetados conforme al estándar SCORM 2004, aunque proporcionará paquetes en los formatos SCORM 2004, SCORM 1.2 e IMS-CP. La información de catalogación se almacena conforme al estándar LOM v.1.0 en español (LOMES). Como parte de las aplicaciones cliente, se desarrolla un portal, denominado Portal M.E.C., que sirve de escaparate al proyecto y que permite a sus visitantes el acceso a los contenidos públicos albergados en cualquiera de los nodos de la Plataforma. Además, se implementa una estructura de portal en cada Comunidad Autónoma, denominada Portal CC.AA., que permite crear instancias del mismo adaptándolas a las necesidades específicas. Página 6 de 8
3.1. Nodo de objetos digitales educativos En la siguiente figura se representa la estructura del Nodo: 3.1.1. Sistema de almacenamiento La naturaleza de la información manejada por la Plataforma es muy heterogénea y por ello se propone utilizar al menos tres sistemas: Directorio LDAP: en él se almacenará la información utilizada en los módulos de autenticación. Sistema de ficheros en disco: se utilizará para aquella información que, de forma natural, se suele almacenar en archivos, por ejemplo: contenidos, metainformación LOM, trazas del sistema de auditoria, logs, etc. Base de datos: la mayor parte de la información manejada por la Plataforma será almacenada en el sistema de ficheros. Parcialmente existirán datos que por su naturaleza (carácter relacional), serán almacenados en una base de datos relacional. 3.1.2. Capa de acceso a datos Este elemento de la arquitectura tiene como objetivo proporcionar a los módulos funcionales un elevado nivel de abstracción sobre los detalles referentes a cómo los objetos persisten en el sistema de almacenamiento. De esta forma la implementación de los módulos funcionales se centrará en la lógica de negocio. Página 7 de 8
3.1.3. Módulos funcionales e Interfaz de Interoperabilidad Cada módulo funcional encapsula e implementa un conjunto de servicios que serán ofertados al resto de elementos que componen el sistema, utilizando para ello una o varias interfaces bien definidas. Entre los servicios que se ofrecen, destacamos algunos. Conjunto de servicios Además de los servicios enumerados que son consumidos o utilizados por los componentes anteriormente descritos, cabe destacar que todos ellos utilizarán el interfaz propuesto por el componente de Seguridad para comprobar si quien accede está o no autorizado a realizar una u otra determinada operación, así como el interfaz ofrecido por el componente de Auditoria para dejar rastro de la operación realizada. El despliegue de los componentes citados se realiza sobre el servidor de aplicaciones mediante ficheros WAR. Gracias a la arquitectura SOA empleada algunos servicios (ofrecidos por determinados WARs) podrían ser desplegados en diferentes servidores de aplicaciones JBoss y todos los servicios que se necesitaran consumir o proveer se accederían a través de los WebServices publicados. 3.1.3. Módulos funcionales e Interfaz de Interoperabilidad Desde el punto de vista del servidor de aplicaciones JBoss, podemos ver el portal Agrega mediante la clásica arquitectura de 3 niveles o capas: Los usuarios se conectan mediante el navegador a los módulos web (WARs desplegados) que exponen la parte visual del portal. Cada módulo de la capa de presentación puede consumir uno o más servicios de los publicados en la capa de negocio, quienes a su vez, hacen uso de la capa de datos correspondiente. Dentro de la capa de negocio encontramos módulos orquestadores que consumen uno o más subservicios para acometer su objetivo. Página 8 de 8