UNIVERSIDAD DE SEVILLAESCUELA SUPERIOR DE INGENIEROS
INGENIERÍA DETELECOMUNICACIÓN
DEPARTAMENTO DE INGENIERÍA DESISTEMAS Y AUTOMÁTICA
ÁREA DE TELEMÁTICA
PROYECTO FIN DE CARRERA
GSAIT: Gestor de Servicios del Área deIngeniería Telemática
Autor: Calixto J. Porras Fortes
Tutor: D. Francisco Javier Muñoz Calle
GSAIT
GSAIT
Índice de Contenidos
Índice de Contenidos ........................................................................................................ 3
Índice de figuras ............................................................................................................... 7
Índice de tablas ................................................................................................................. 9
Índice de listados de código ........................................................................................... 10
1 Introducción y conceptos básicos ........................................................................... 11
1.1 Objetivos iniciales .............................................................................................. 11
1.2 Entorno de desarrollo ......................................................................................... 14
1.2.1 Entorno integrado de desarrollo: Eclipse ................................................... 14
1.2.2 Servidor de aplicaciones. Jakarta Tomcat .................................................. 17
1.2.3 Servidor de base de datos: PostgreSQL...................................................... 17
1.2.4 Aplicación de conversión de ficheros en texto plano: atox ........................ 18
1.2.5 Librería de transformaciones XSLT: libxslt............................................... 19
1.3 Plan de Trabajo seguido ..................................................................................... 19
2 Base Teórica ........................................................................................................... 22
2.1 Jakarta STRUTS................................................................................................. 23
2.1.1 Introducción................................................................................................ 23
2.1.2 El patrón Modelo – Vista – Controlador (MVC) ....................................... 24
2.2 Estos componentes se explicarán detalladamente más adelante. ....................... 24
2.2.1 La implementación del MVC de Struts ...................................................... 25
2.2.1.1El Modelo................................................................................................ 26
2.2.1.2La Vista ................................................................................................... 26
2.2.1.3El Controlador ......................................................................................... 27
2.3 JSP Standard Template Library (JSTL) ............................................................. 27
2.3.1 Introducción................................................................................................ 27
2.3.2 Las librerías JSTL....................................................................................... 29
2.3.3 El lenguaje de Expresión EL ...................................................................... 30
2.3.4 Conclusiones............................................................................................... 30
2.4 Java API for XML Processing............................................................................ 30
2.4.1 Introducción................................................................................................ 30
2.4.2 Paquetes ...................................................................................................... 31
2.4.3 Las APIs SAX (Simple API for XML) ...................................................... 32
GSAIT
2.4.4 Los paquetes de SAX ................................................................................. 34
2.4.5 Las APIs DOM (Document Object Model)................................................ 35
2.4.6 Paquetes de la API DOM de JAXP ............................................................ 36
2.4.7 Las APIs XSLT (XML Stylesheet Translation) ......................................... 36
2.4.8 Los paquetes XSLT .................................................................................... 37
2.5 Log4j................................................................................................................... 37
2.5.1 Motivaciones para su uso ........................................................................... 38
2.5.2 Funcionalidades de log4j ............................................................................ 38
2.6 Seguridad............................................................................................................ 40
2.6.1 Secure Socket Layer (SSL) ........................................................................ 40
2.6.2 Seguridad en la comunicación con servidores remotos. Java Secure
Channel (JSch)........................................................................................................ 42
2.6.2.1Secure Shell (SSH).................................................................................. 42
3 Funcionalidades del Proyecto................................................................................. 44
3.1 Terminología ...................................................................................................... 46
3.2 Gestión del Acceso a la Aplicación.................................................................... 47
3.2.1 Autenticación.............................................................................................. 47
3.2.2 Menú Principal ........................................................................................... 47
3.3 Gestión del GSAIT ............................................................................................. 48
3.3.1 Gestión de Roles......................................................................................... 48
3.3.2 Gestión de Usuarios.................................................................................... 49
3.3.3 Gestión de Servicios ................................................................................... 49
3.3.3.1Procesamiento de los ficheros ................................................................. 51
3.4 Administración Específica del Servicio de Calificaciones................................. 52
3.4.1 Rutas Ficheros SNAIT ............................................................................... 52
3.4.2 Gestión de Asignaturas............................................................................... 52
3.5 Gestión de Servicios ........................................................................................... 53
3.5.1 Configuración del funcionamiento de los servicios ................................... 53
3.6 Gestión de Calificaciones ................................................................................... 55
4 Descripción detallada de la aplicación ................................................................... 59
4.1 Capa de Persistencia ........................................................................................... 59
4.1.1 El patrón DAO / DTO. ............................................................................... 59
4.1.2 Base de datos relacional. ............................................................................ 60
4.1.3 Modelo de datos ......................................................................................... 60
GSAIT
4.2 Lógica de la aplicación....................................................................................... 62
4.2.1 Extensión de Struts ..................................................................................... 62
4.2.2 Formularios en Struts ................................................................................. 66
4.2.3 Paquetes de la Aplicación........................................................................... 71
4.2.3.1edu.extensionStruts ................................................................................. 71
4.2.3.2edu.extensionStruts.seguridad................................................................. 72
4.2.3.3edu.extensionStruts.utilidades................................................................. 73
4.2.3.4edu.gsait.action........................................................................................ 73
4.2.3.5edu.gsait.actionForm ............................................................................... 74
4.2.3.6edu.gsait.datos.beans............................................................................... 75
4.2.3.7edu.gsait.datos.dao .................................................................................. 75
4.2.3.8edu.gsait.formulariosDinamicos ............................................................. 77
4.2.3.9edu.gsait.mensajes................................................................................... 80
4.2.3.10 edu.gsait.ssh ......................................................................................... 81
4.2.3.11 edu.gsait.xml ........................................................................................ 81
4.2.3.12 edu.sistema........................................................................................... 81
4.3 Capa de presentación.......................................................................................... 82
5 Test del mecanismo de modificación de archivos .................................................. 86
5.1 Simulación de acceso SSH ................................................................................. 86
5.2 Simulación de ejecución remota de comandos................................................... 87
5.2.1 Generación de las plantillas de conversión ................................................ 87
5.2.2 Formato original del fichero ....................................................................... 87
5.2.3 Procesador de Descarga.............................................................................. 89
5.2.4 Procesador de Subida ................................................................................. 92
5.2.5 Descriptor del formulario ........................................................................... 95
6 Planificación ........................................................................................................... 98
7 Líneas de continuación ......................................................................................... 100
8 Conclusiones......................................................................................................... 101
9 Bibliografía........................................................................................................... 103
9.1 Libros................................................................................................................ 103
9.2 Sitios Web ........................................................................................................ 103
10 Anexos .................................................................................................................. 105
10.1 Gestión del GSAIT.......................................................................................... 105
10.1.1 Instalación del servidor............................................................................. 105
GSAIT
10.1.1.1 Instalación de atox ............................................................................. 105
10.1.1.2 Inicialización de la base de datos....................................................... 105
10.1.1.3 Despliegue de la aplicación ............................................................... 106
10.1.2 Gestión de la traza del servidor ................................................................ 108
10.1.3 Gestores del GSAIT ................................................................................. 109
10.1.3.1 Administración del GSAIT................................................................ 109
10.1.3.2 Administración del Servicio de Calificaciones.................................. 115
10.2 Manual de Usuario del GSAIT ....................................................................... 120
10.2.1 Gestión de Acceso .................................................................................... 120
10.2.2 Administradores de Servicios (Configuradores) ...................................... 120
10.2.2.1 Gestión de Servidores del Área ......................................................... 120
10.2.3 Profesores ................................................................................................. 123
10.2.3.1 Gestión de Calificaciones .................................................................. 123
10.3 Formularios dinámicos y procesamiento de ficheros...................................... 127
10.3.1 Formulario dinámico. El descriptor de formulario................................... 127
10.3.1.1 Tipos de Campos Simples.................................................................. 128
10.3.1.2 El descriptor del formulario ............................................................... 129
10.3.1.3 El XML Campo – Valor .................................................................... 131
10.3.1.4 Los procesadores de descarga y de subida......................................... 134
10.4 Contenido del CD............................................................................................ 136
10.4.1 Directorio raíz........................................................................................... 136
10.4.2 Directorio Aplicación ............................................................................... 136
10.4.3 Memoria ................................................................................................... 136
10.4.4 ScriptsBD ................................................................................................. 137
10.4.5 Manual atox .............................................................................................. 137
GSAIT
Índice de figurasFigura 1: Esquema de comunicaciones del GSAIT.........................................................11
Figura 2: Esquema básico del mecanismo de conversión de ficheros.............................12
Figura 3: Captura de pantalla del entorno de desarrollo Eclipse.................................... 15
Figura 4: La implementación de Struts de MVC............................................................ 25
Figura 5: Funcionamiento del Procesado SAX .............................................................. 32
Figura 6: Las APIs DOM de JAXP en acción................................................................ 35
Figura 7: Las APIs XSLT de JAXP en acción ............................................................... 36
Figura 8: Pantalla de login del GSAIT ........................................................................... 47
Figura 9: Menú principal de GSAIT .............................................................................. 48
Figura 10: Formulario de Gestión de Roles ................................................................... 48
Figura 11: Formulario de Gestión de Usuarios del GSAIT............................................ 49
Figura 12: Pantalla de Gestión de Servicios................................................................... 50
Figura 13: Gestión de Rutas del SNAIT......................................................................... 52
Figura 14: Gestión de Asignaturas ................................................................................. 53
Figura 15: Captura del árbol de servicios del GSAIT .................................................... 54
Figura 16: Formulario de Configuración de un archivo gestionado por GSAIT............ 55
Figura 17: Panel de Control del Profesor ....................................................................... 56
Figura 18: Panel de control de una asignatura................................................................ 56
Figura 19: Gestión del Listado de Alumnos de una Asignatura..................................... 57
Figura 20: Pantalla de gestión de datos de examen........................................................ 58
Figura 21: Modelo de datos del GSAIT ......................................................................... 60
Figura 22: Menú principal con las opciones habilitadas para los usuarios gestores del
GSAIT .................................................................................................................. 109
Figura 23: Formulario de gestión de roles.................................................................... 110
Figura 24: Formulario de gestión de usuarios del sistema ........................................... 111
Figura 25: Parte superior de la pantalla de gestión de los servicios, con los datos sobre
los servicios en sí.................................................................................................. 113
Figura 26: Parte inferior de la pantalla de gestión de servicios, con los datos sobre los
ficheros de configuración de cada servicio. ......................................................... 113
Figura 27: Gestión de rutas del SNAIT........................................................................ 115
Figura 28: Gestión de asignaturas ................................................................................ 116
Figura 29: Árbol de servicios del GSAIT..................................................................... 121
GSAIT
Figura 30: Formulario de configuración....................................................................... 121
Figura 31: Campo de selección libre ............................................................................ 122
Figura 32: Campo múltiple........................................................................................... 122
Figura 33: Panel de Control del Profesor ..................................................................... 123
Figura 34: Formulario de inserción / modificación del listado de alumnos de la
asignatura.............................................................................................................. 124
Figura 35: Pantalla de gestión de datos de exámenes................................................... 125
Figura 36: Campo de texto ........................................................................................... 128
Figura 37: Campo de selección simple......................................................................... 128
Figura 38: Campo de selección múltiple ...................................................................... 128
Figura 39: Campo de selección libre ............................................................................ 129
Figura 40: Campo de tipo booleano ............................................................................. 129
GSAIT
Índice de tablasTabla 1: Descripción de los componentes del patrón MVC........................................... 24
Tabla 2: Paquetes de la API SAX................................................................................... 35
Tabla 3: Paquetes de la API DOM de JAXP.................................................................. 36
Tabla 4: Estimación de esfuerzo del GSAIT.................................................................. 98
GSAIT
PROYECTO FIN DE CARRERA 10 UNIVERSIDAD DE SEVILLA
Índice de listados de códigoListado 1: Ejemplo de Vista de Struts ............................................................................ 26
Listado 2: JSP de cuenta hasta 10 usando scriptlets....................................................... 28
Listado 3: Ejemplo de cuenta hasta 10 usando JSTL ..................................................... 28
Listado 4: Uso de EL en JSP .......................................................................................... 30
Listado 5: Uso de EL dentro de etiquetas JSTL ............................................................. 30
Listado 6: Creación de un Logger .................................................................................. 39
Listado 7: Inserción de sentencias de log de distintos niveles de prioridad ................... 39
Listado 8: Fichero de configuración de log4j para el Proyecto GSAIT ......................... 40
Listado 9 Esqueleto del método execute de la clase Action de Struts............................ 62
Listado 10: Código de obtención del objeto Method, que permite, por reflexividad,
invocar a un método de la clase actual que se llame de una forma determinada, en
concreto, como indique la variable ‘accion’........................................................... 64
Listado 11: Código de cómo se invoca el método obtenido según se mostró en el
Listado 10 en el método execute de la clase ExtensionAction............................... 65
Listado 12: Ejemplo de una típica clase ExtensionAction ............................................. 65
Listado 13: Ejemplo de llamada a un método concreto de la clase ExtensionAction .... 66
Listado 14: Composición JSP del formulario de login................................................... 67
Listado 15: Clase LoginForm, asociada al formulario de Login del GSAIT ................. 68
Listado 16: Obtención de los valores del formulario en la clase Action........................ 69
Listado 17: Pre-rellenado de los valores de un formulario............................................. 70
Listado 18: Formato original del fichero gwRDSIH323.cfg.......................................... 89
Listado 19: Procesador de descarga para el fichero gwRDSIH323.cfg ......................... 92
Listado 20: Procesador de subida del fichero gwRDSIH323.cfg................................... 95
Listado 21: Descriptor de formulario empleado para el gwRDSIH323.cfg ................... 96
Listado 22: Descriptor de contexto de Tomcat para GSAIT........................................ 107
Listado 23: Líneas a insertar en mod_jk para activar el desvío a Tomcat de las
peticiones dinámicas relativas al GSAIT.............................................................. 107
Listado 24: Ejemplo de fichero XML campo-valor de GSAIT.................................... 133
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 11 UNIVERSIDAD DE SEVILLA
1 Introducción y conceptos básicos
1.1 Objetivos iniciales
El Área de Ingeniería Telemática de la Escuela de Ingenieros de Sevilla dispone de un
conjunto de servidores de funcionalidad diversa. Estos servidores han sido desarrollados
durante los últimos años, con el propósito de cubrir diferentes necesidades del Área.
Cada uno de ellos posee un mecanismo de configuración propio, basado normalmente
en ficheros de texto, de formato heterogéneo. Surge la necesidad de dotar al Área de un
mecanismo único, uniforme, versátil e intuitivo para la gestión de todos estos sistemas
y, evidentemente, de cualquiera que pueda ser desarrollado en el futuro.
El GSAIT (Gestor de Servidores del Área de Ingeniería Telemática), es una aplicación
JSP, destinada a ofrecer un mecanismo de configuración unificado, flexible y seguro,
vía Web, para la configuración remota de los servidores del Área. El GSAIT permitirá
a los usuarios, previa autenticación, modificar la configuración de los servidores a
través de una interfaz gráfica amigable, con el único requisito de disponer de navegador
Web y de conexión a Internet.
INTRANET
CLIENTE(PC + BROWSER)
GSAIT
INTERNET
CLIENTE(PC + BROWSER)
Red de la Universidad
SERVICIOS
Figura 1: Esquema de comunicaciones del GSAIT
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 12 UNIVERSIDAD DE SEVILLA
El sistema ha sido diseñado apoyándose en dos pilares fundamentales:
• las hojas de estilo XSLT: para aplicar transformaciones sobre documentos XML
• la aplicación de fuentes abiertas atox, de Magnus Hetland: para aplicar
transformaciones a documentos de texto plano.
El uso de estas dos herramientas garantiza la capacidad del GSAIT para gestionar
potencialmente cualquier formato de fichero de configuración (ya sea texto plano o
XSLT). De manera sucinta, el sistema se basa en un núcleo común, que trabaja con
formatos XML propios de la aplicación. XSLT y atox, se encargan de hacer que los
formatos propietarios de cada servidor sean transparentes al núcleo de la aplicación
El GSAIT ofrece la posibilidad de incorporar nuevos ficheros de configuración a
gestionar. Para ello, el administrador deberá diseñar las plantillas de conversión
pertinentes, como se detalla en el apartado 10.3, “Formularios dinámicos y
procesamiento de ficheros”. Se trata, por tanto, de una aplicación totalmente
escalable.
Inicialmente se ha configurado el GSAIT con información para poder gestionar los
servidores que funcionan actualmente en el AIT. Especial mención merece aquí el
SNAIT (Servidor de Notas del Área de Ingeniería Telemática). Este servidor no sólo
Fichero ConfiguraciónOriginal
Fichero ConfiguraciónNuevo
atox / XSLT XSLT
XML Valores Originales XML Nuevos Valores
INTERACCIÓNCON EL USUARIO
NÚCLEO GSAIT
Figura 2: Esquema básico del mecanismo de conversión de ficheros
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 13 UNIVERSIDAD DE SEVILLA
dispone de ficheros de texto para su configuración interna. El SNAIT almacena las
notas de exámenes de asignaturas también en ficheros. Se ha considerado oportuno
dotar al GSAIT de un mecanismo adicional de configuración, particular para el SNAIT,
que permitirá:
• Gestionar la información sobre profesores, alumnos y asignaturas
• Ofrecer a los profesores la posibilidad de insertar calificaciones directamente
mediante los ficheros de texto generados por Microsoft Excel.
• Ofrecer a los profesores la posibilidad de publicar y notificar las calificaciones
de los exámenes. Esta funcionalidad se ofrece mediante una conexión al servidor
SCAIT (Servidor de Calificaciones del Área de Ingeniería Telemática).
Como puede deducirse de lo expuesto, el Proyecto tiene un objetivo eminentemente
práctico, que es facilitar la gestión de los servidores del AIT. Sin embargo, las
características del mismo lo convierten en un escenario ideal para estudio y la
integración de una gran variedad de tecnologías implicadas, a saber:
• Java y JSP. Empleo del framework Struts, de Jakarta.
• Bases de datos relacionales (SQL)
• XML, XML Schema y XSLT Stylesheet.
• Perl: Lenguaje de la aplicación atox, vital para el funcionamiento de este
proyecto
• SSH y SFTP: Para la transferencia a través de la red de los ficheros de
configuración, así como para la ejecución de los comandos de reinicio de los
servidores.
Cabe destacar, por último, el empleo exclusivo de software libre, tanto en el entorno de
desarrollo como en las librerías usadas dentro de la aplicación. Además de ser la opción
más económica, se ha constatado que en la práctica totalidad de los casos, las soluciones
de software libre han sido las óptimas. Esto es debido a la gran solidez que proporciona
al software el respaldo de toda una comunidad de programadores y usuarios.
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 14 UNIVERSIDAD DE SEVILLA
1.2 Entorno de desarrollo
La aplicación se ha desarrollado usando el sistema operativo Linux. Concretamente se
ha empleado la distribución Mandrake Official 10.0. Se ha optado por este entorno por
dos motivos principales:
• El rendimiento superior de este sistema operativo frente a otros (Windows, por
ejemplo). Esta superioridad es especialmente crítica al trabajar con procesos
servidores (que es el caso de estudio).
• La similitud con el entorno de producción: La versión final de la aplicación será
desplegada en un entorno Linux. Trabajando en él desde la fase inicial de
desarrollo se minimiza el impacto en la implantación
• El carácter de software libre: con el consiguiente ahorro económico.
Mandrake Linux Official es una distribución libre, que puede ser descargada desde su
página oficial. Posee toda la potencia y robustez de los entornos Linux, a la vez que
ofrece una relativa sencillez en su instalación y mantenimiento.
1.2.1 Entorno integrado de desarrollo: Eclipse
Como entorno de desarrollo se ha empleado Eclipse, en su versión 3.0.1.
Eclipse es una plataforma diseñada para construir entornos integrados de desarrollo
(IDEs). Fue creada y liberada por IBM, y actualmente es impulsada por una comunidad
abierta de empresas desarrolladoras de software (conocida como Eclipse.org). Esta
comunidad aboga por el desarrollo de productos fácilmente interoperables entre sí,
basándose en una tecnología de complementos (plugins, de ahora en adelante).
Colaborando y compartiendo el núcleo de la tecnología de integración, las empresas
pueden concentrarse en producir mejores herramientas de desarrollo para las áreas de
conocimiento que más dominan.
De cara al programador, Eclipse ofrece un entorno de trabajo prácticamente
inmejorable. Asistentes para la creación de proyectos y ficheros, organizador de
proyectos, editor avanzado con funciones de autocompletado y autoformateado,
herramientas de ejecución y depuración… son sólo una ínfima parte del vastísimo
abanico de posibilidades de este entorno. Todo esto se completa con una casi inagotable
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 15 UNIVERSIDAD DE SEVILLA
lista de plugins o complementos que pueden ser encontrados en Internet, y que
convierten a Eclipse en una herramienta de precisión para casi cualquier tecnología
informática.
Figura 3: Captura de pantalla del entorno de desarrollo Eclipse
Para el desarrollo del GSAIT, se ha hecho uso de los siguientes plugins de Eclipse:
Sysdeo Tomcat Plugin (versión 3):
Como se detalla más adelante en esta memoria, se ha empleado como contenedor de
Servlets y JSP el servidor Jakarta Tomcat. Este plugin permite realizar, entre otras,
las siguientes funciones relacionadas con el mismo:
o Arrancar, parar y reiniciar Tomcat.
o Registrar procesos de Tomcat en el depurador de Eclipse.
o Asistente para la creación de un proyecto WAR (El asistente es capaz de
modificar el fichero de configuración de Tomcat server.xml).
o Añadir proyectos Java al classpath de Tomcat.
o Configurar los parámetros, el classpath y el bootclasspath de la máquina
virtual de Tomcat.
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 16 UNIVERSIDAD DE SEVILLA
o Exportar un proyecto de Tomcat a un fichero WAR.
o Elegir el fichero de configuración de Tomcat.
El plugin es gratuito y de fuentes abiertas y puede conseguirse en:
http://www.sysdeo.com/eclipse/tomcatPlugin.html
Objectlearn Lomboz (versión 3.0.1)
Este plugin permite a los desarrolladores de Java construir, probar y desplegar
componentes J2EE y aplicaciones Web en alguno de los servidores de aplicaciones
más populares. Entre sus características más importantes, las que lo hacen
prácticamente imprescindible para el desarrollo del proyecto son las siguientes:
o Asistentes para la construcción de aplicaciones Web con páginas HTML,
servlets, y archivos JavaServer Pages (JSP).
o Editor JSP especializado, con resaltado de la sintaxis y asistente de
autocompleción de código.
o Comprobación de la sintaxis JSP.
o Generación de contenedores Web y EJB mediante asistentes.
o Generación de clientes de prueba para EJBs mediante asistentes.
o Soporte para despliegue de ficheros EAR (archivos de aplicaciones Web
J2EE), WAR (módulos Web) y archivos EJB (Jar).
Este plugin es de software libre, y está disponible en la dirección:
http://www.objectlearn.com/projects/download.jsp
Struts Console, de James Holmes (versión 4.8)
Se trata de una aplicación Swing de Java, que facilita el diseño y mantenimiento de
aplicaciones basadas en el framework Struts de Jakarta1. Struts-console permite editar
visualmente los ficheros de configuración de Taglibs JSP, Struts, Tiles y Validator.
1 Este framework, sobre el que se fundamenta la aplicación GSAIT, será objeto de discusión en apartados
sucesivos.
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 17 UNIVERSIDAD DE SEVILLA
1.2.2 Servidor de aplicaciones. Jakarta Tomcat
Como ya se ha explicado en la introducción, el GSAIT es una aplicación Web
construída con tecnología de servidor JavaServer Pages. Por lo tanto, para desplegarla
es preciso disponer de un contenedor de Servlets y JSP.
Para el desarrollo de la aplicación se ha empleado como contenedor JSP el servidor
Jakarta Tomcat, versión 5.5.4.
Apache Tomcat es el contenedor de Servlets que se usa en la Implementación de
Referencia Oficial de las tecnologías Java Servlet y JavaServer Pages, ambas
desarrolladas por Sun Microsystems.
Apache Tomcat se desarrolla en un entorno abierto y colaborativo, y se distribuye bajo
la licencia de Apache (Apache Software License) que, sin entrar en detalles, permite un
uso gratuíto del software. Apache Tomcat pretende ser el fruto de la colaboración de los
mejores desarrolladores de todo el mundo.
1.2.3 Servidor de base de datos: PostgreSQL
El GSAIT necesita una capa de persistencia, en la que almacenar información
relacionada con los usuarios de la aplicación, los roles, los ficheros a configurar y los
datos acerca de profesores, asignaturas y alumnos para la gestión del SNAIT.
Para implementar dicha capa de persistencia, se ha optado por recurrir a un Sistema
Gestor de Bases de Datos Relacionales (SGBDR). Los principales motivos para esta
elección son:
• La gran variedad de SGBDR que existen, y la práctica omnipresencia de los
mismos en casi cualquier entorno de implantación de sistemas de
información.
• Consecuentemente, la gran documentación y soporte existente para las
soluciones que optan por una capa de persistencia relacional.
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 18 UNIVERSIDAD DE SEVILLA
• La enorme potencia del lenguaje SQL (Structured Query Language), propio de
los SGBDR, que permite una gestión cómoda y eficiente de los datos
almacenados en el sistema.
Como Sistema Gestor de Base de Datos en desarrollo, se ha elegido PostgreSQL 7.4.1.
Esta versión viene incluida en la distribución Mandrake Official 10.0.
PostgreSQL es un Sistema Gestor de Base de Datos Relacional, altamente escalable,
conforme con la norma SQL y de fuentes abiertas. Con más de 15 años ya de desarrollo
a sus espaldas, está convirtiéndose en la base de datos por excelencia para soluciones
empresariales de software libre.
1.2.4 Aplicación de conversión de ficheros en texto plano: atox
Uno de los requisitos clave a los que ha tenido que darse solución en el diseño del
GSAIT ha sido la conversión de texto plano, de formato arbitrario, a XML. La solución
ideal hubiera sido encontrar algún tipo de API nativa de Java especialmente diseñada a
tal efecto. Sin embargo, mucho se ha investigado y no se han encontrado propuestas
interesantes al respecto.
La solución más interesante y óptima que se ha encontrado es el uso de la herramienta
atox, de Magnus Hetland. atox es una aplicación de software libre, escrita en Python,
que permite insertar marcas a un documento de texto plano de entrada. La forma en que
atox realiza esta conversión se le indica pasándole una plantilla, consistente en un
documento XML con una estructura determinada. Se ha empleado la versión 0.5 de la
aplicación.
La integración entre el entorno Java donde corre GSAIT y atox se consigue invocando
este programa como un comando del sistema desde Java. Por tanto, es necesario que
atox esté instalado en el equipo donde corra el servidor, y disponible en el path del
mismo.
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 19 UNIVERSIDAD DE SEVILLA
Los detalles acerca de la estructura que debe tener el fichero de conversión, así como
sobre la instalación atox se discuten en el apartado de despliegue del servidor.
1.2.5 Librería de transformaciones XSLT: libxslt
Como se ha comentado en apartados anteriores, GSAIT hace uso del lenguaje XSLT
para aplicar de forma conveniente transformaciones sobre documentos XML. Esta
funcionalidad dentro de la aplicación se logra usando la API de Java para XML (JAXP).
Esta API y el resto de las que se usan son tratadas en la sección de la Estructura de la
Aplicación.
Sin embargo, aparte del uso de esta API, se ha considerado conveniente instalar las
librerías libxslt. Se trata de la librería XSLT en C desarrollada por el proyecto Gnome (y
se basa en la librería libxml2, del mismo proyecto). De entre las prestaciones que
ofrece, la que la hace interesante es la presencia del comando ‘xsltproc’, que permite
aplicar transformaciones XSLT desde la línea de comandos. Esto tiene dos utilidades
fundamentales:
1. Gran comodidad a la hora de desarrollar y depurar las plantillas XSLT que se
necesitan para convertir los ficheros a configurar por el GSAIT.
2. atox permite incrustar comandos XSLT en sus plantillas de conversión,
multiplicando enormemente su potencia. Para que esto funcione, es necesario
que el comando xsltproc esté disponible en el sistema.
1.3 Plan de Trabajo seguido
La realización del Proyecto se abordó realizando una división en tareas, que se detalla a
continuación:
1.- Documentación
Se realizaría una labor de investigación, documentación e iniciación acerca de las
tecnologías básicas que iban a estar necesariamente implicadas en la realización del
proyecto (Java, JSP, SSL, XML, XML Schema y XSLT), con la que obtener una visión
global que ayudara a realizar el análisis de la aplicación.
2.- Implantación del entorno de desarrollo
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 20 UNIVERSIDAD DE SEVILLA
Una vez adquirida la visión global de las tecnologías implicadas, se procedería a instalar
el entorno de desarrollo. Una vez instalado en su versión inicial (durante las fases
subsiguientes se podrían añadir, eliminar y actualizar varios de sus componentes), se
realizarían diversas pruebas. El objetivo sería tomar contacto directo con las diferentes
tecnologías y APIs a usar, para poder llevar a cabo un análisis lo más preciso y
definitivo posible.
3.- Análisis
A continuación se realizaría un estudio de los requisitos y especificaciones de la
aplicación. En esta fase se deberían delimitar claramente los diferentes módulos de los
que constaría la aplicación, así como una enumeración detallada de las funcionalidades
necesarias en cada uno de ellos.
También se diseñaría el modelo de datos de la aplicación y los scripts necesarios para la
creación del esquema de base de datos de la misma. Como es lógico, este esquema
sufriría modificaciones a lo largo del desarrollo de la aplicación.
4.- Desarrollo de la lógica del servidor
Como cabe suponerse, la fase más extensa del proceso. En esta fase se procedería a la
codificación de los diferentes módulos de la aplicación. La división que se realizó de la
aplicación en módulos (sin entrar en detalles, se describirá en sucesivos apartados), es la
que sigue:
o Módulo de autorización y autenticación (Usuarios y roles)
o Módulo de configuración de ficheros de servidores
Generación dinámica de formularios
Subida / bajada de ficheros mediante SSH / SFTP
Procesado de ficheros mediante XSLT / atox
Ejecución de comandos remotos para reinicio de servidores mediante
SSH.
o Módulo de gestión web de usuarios y roles del GSAIT.
o Módulo de gestión web de servicios configurables por el GSAIT.
o Módulo de gestión web de profesores, asignaturas.
GSAIT Introducción y conceptos básicos
PROYECTO FIN DE CARRERA 21 UNIVERSIDAD DE SEVILLA
o Módulo de gestión web de inserción de listados de alumnos y calificaciones
a partir de ficheros obtenidos de programas de Hoja de Cálculo.
Paralelamente a la fase de desarrollo se llevaría a cabo una fase de pruebas. El
desarrollo se ejecutaría de forma muy modular, y realizando continuas pruebas de cada
pequeño módulo funcional que se fuera creando.
5.- Estética de la aplicación
Esta fase se centraría en el desarrollo de la presentación de la aplicación.
6.- Instalación en producción
En esta fase la aplicación se desplegaría en el entorno de producción. Aunque
teóricamente el grueso de esta fase se debería llevar a cabo en este punto cronológico,
en la práctica se realizaría escalonadamente durante la fase de desarrollo.
7.- Batería definitiva de pruebas
La aplicación se sometería a un conjunto de pruebas destinadas a determinar y afinar su
robustez en el entorno de producción.
8.- Redacción de la memoria
Desde fases tempranas de desarrollo se irían redactando pequeños informes, que en esta
fase final serían agrupados, homogeneizados y extendidos para dar lugar a la presente
memoria.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 22 UNIVERSIDAD DE SEVILLA
2 Base TeóricaComo se ha discutido en el primer bloque de la memoria, el Proyecto consiste en una
aplicación WEB basada en JSP (Java Server Pages), la tecnología de servidor de Java.
Esta aplicación puede ser desplegada, por tanto, en cualquier servidor que cumpla con la
especificación de Sun de contenedor de Servlets y JSP, por ejemplo Jakarta Tomcat.
Tomando como base esta tecnología, se ha hecho uso para el desarrollo de este Proyecto
de un conjunto de herramientas. Se pueden distinguir, en función del objetivo que
persiguen dos grupos de las mismas:
• Marcos de trabajo (Frameworks) de desarrollo: Los marcos de trabajo son
herramientas destinadas a agilizar el desarrollo de tareas habituales. Así, por
ejemplo, son tareas habituales en el diseño de aplicaciones WEB la gestión de
formularios, el control del flujo de la aplicación, el tratamiento visual de la
información lógica, etc. En este Proyecto se ha hecho uso de dos frameworks:
o Jakarta STRUTS: Se trata de un framework de fuentes abiertas,
desarrollado por Jakarta. Básicamente, ofrece una implementación del
patrón de diseño Modelo – Vista – Controlador (que se explica más
adelante), que permite desarrollar aplicaciones donde se separa
claramente la parte de presentación de la lógica de negocio.
o Jakarta Standard Taglibs Library (JSTL): Se trata de una librería de
etiquetas (taglibs) muy completa, que complementada con Struts, facilita
el diseño de páginas JSP donde la presentación se diferencia claramente
de la lógica de la aplicación.
El empleo de estos frameworks permite desarrollar aplicaciones WEB robustas,
donde la capa de presentación y la capa de lógica están separadas. Esto permite
una mayor especialización a la hora del desarrollo (las funciones del
programador y del diseñador gráfico están bastante claramente delimitadas), así
como posibilita que una misma aplicación tenga múltiples interfaces de
presentación (navegador WEB convencional, navegadores WAP, etc.)
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 23 UNIVERSIDAD DE SEVILLA
• APIs de Java: La comunidad JAVA dispone de infinidad de APIs (Application
Programming Interfaces), esto es, bibliotecas de clases que implementan
diversas funcionalidades. Para el desarrollo de este proyecto se ha hecho uso de
las siguientes APIs:
o Java API for XML Processing (JAXP): JAXP es la API de Sun que
permite procesar, generar y transformar documentos XML
independientemente de la implementación concreta de procesado XML
que se desee emplear.
o Java Secure Channel (JSch): Se trata de una API desarrollada por JCraft,
y que ofrece métodos para conectarse a servidores SSH y ejecutar
comandos.
o Log4j (Log for Java): Log4j es una API de fuentes abiertas, desarrollada
bajo el proyecto Jakarta Apache. Proporciona un conjunto de
funcionalidades robustas, fiables, totalmente configurables y fácilmente
extensibles para gestionar el log de aplicaciones Java, con propósitos de
depuración y monitorización.
2.1 Jakarta STRUTS
2.1.1 Introducción
Struts es un framework del lado de servidor de Java, que combina dos de las más
populares tecnologías de Java para servidores: JSPs y servlets, dando lugar a una
implementación del patrón de programación Modelo – Vista – Controlador. Fue ideada
por Craig McClanahan en mayo de 2000, y ha crecido bajo la tutela de la comunidad de
desarrollo de Apacha Jakarta desde entonces.
Es destacable el hecho de que Struts tuviera una aceptación casi inmediata. Claramente,
esto da fe de su calidad y utilidad. La comunidad Java, tanto comercial como privada, se
ha involucrado con bastante fuerza en el proyecto. Actualmente lo soportan los
principales servidores de aplicaciones, incluyendo BEA, Sun, HP y, por supuesto el
Jakarta Tomcat de Apache. El grupo Tomcat ha ido más lejos, e incluso ha empezado a
usar una aplicación Struts para el gestor de aplicaciones del servidor en sus versiones
más recientes.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 24 UNIVERSIDAD DE SEVILLA
El proyecto Struts se diseñó con el objetivo de proporcionar un framework de fuentes
abiertas para crear aplicaciones WEB que separen fácilmente la capa de presentación y
la abstraigan de las capas de transacción y de datos. Como se ha dicho, desde su
creación, Struts ha recibido un gran apoyo de la comunidad de desarrollo, y se está
convirtiendo rápidamente en un estándar “de-facto” en la comunidad de fuentes
abiertas.
2.1.2 El patrón Modelo – Vista – Controlador (MVC)
El patrón Modelo – Vista – Controlador (en adelante, MVC), creado originalmente por
Smalltalk, consta de tres componentes: un modelo, una vista y un controlador. En la
Tabla 1 se definen estos conceptos:
Componente Descripción
Modelo Representa los objetos de datos. El Modelo es lo que se manipula y se
presenta al usuario.
Vista Es la representación en pantalla del Modelo. Es el objeto que presenta el
estado actual de los objetos de datos.
Controlador Define la forma en que la interfaz del usuario reacciona a las acciones
del usuario. El componente Controlador es el objeto que manipula el
Modelo (o objeto de datos).
Tabla 1: Descripción de los componentes del patrón MVC
2.2 Estos componentes se explicarán detalladamente más adelante.
Algunas de las principales ventajas de usar el patrón MVC son:
Fiabilidad: Las capas de presentación y de transacción tienen una separación clara,
lo que permite cambiar la apariencia de la aplicación sin recompilar el código del
Modelo o del Controlador.
Alta reusabilidad y adaptabilidad: El MVC permite el uso de múltiples tipos de
vista, todas ellas accediendo al mismo código de servidor. Esto abarca todo desde
navegadores WEB (http) hasta navegadores inalámbricos (WAP)
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 25 UNIVERSIDAD DE SEVILLA
Costes de desarrollo y ciclo de vida muy bajos: El MVC permite tener un
desarrollo de menor nivel y mantener las interfaces de usuario.
Despliegue rápido: El tiempo de desarrollo se puede reducir significativamente
dado que los programadores del Controlador (programadores Java), se pueden
centrar solamente en las transacciones, y los programadores de la Vista
(desarrolladores de HTML y JSP), pueden centrarse solamente en la presentación.
Mantenibilidad: La separación de la lógica de presentación y la lógica de negocio
también redunda en una facilidad de mantenimiento y modificación de una
aplicación WEB basada en Struts.
2.2.1 La implementación del MVC de Struts
El framework Struts modela su implementación del lado de servidor del MVC usando
una combinación de JSPs, etiquetas propias y servlets Java. En la Figura 4 se describe el
camino que sigue una petición en una aplicación Struts:
Figura 4: La implementación de Struts de MVC
Este proceso puede dividirse en cinco pasos básicos:
1. Se hace una petición (request) de una Vista anteriormente mostrada.
2. La petición la recibe el ActionServlet, que actúa como el Controlador. El
ActionServlet busca la URI solicitada en un fichero XML (el descriptor de
despliegue de Struts, struts-config.xml), y determina el nombre de la clase
Action que realizará la lógica necesaria.
Vista 1
Vista 2
ActionServlet
(Controlador)
5.
1. Acción 1
Acción 1
Acción 1
2.
4.
Modelos
3.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 26 UNIVERSIDAD DE SEVILLA
3. La clase Action lleva a cabo su lógica sobre los componentes del Modelo
asociados con la aplicación.
4. Una vez que la clase Action ha completado su procesamiento, devuelve el
control al ActionServlet. Como parte del retorno, la clase Action proporciona
una clave que indica el resultado del procesamiento. El ActionServlet usa esta
clave para deteminar dónde deberán dirigirse los resultados para la presentación.
5. La petición se completa cuando el ActionServlet responde enviando la petición a
la Vista que está asociada con la clave devuelta. Esta Vista presenta los
resultados de la clase Action.
2.2.1.1 El Modelo
El framework Struts no proporciona componentes especializados para el Modelo.
Deberán desarrollarse para cada caso en concreto.
2.2.1.2 La Vista
Cada componente de la Vista en el Framework Struts se mapea a una única página JSP
que puede contener un número cualquiera de etiquetas Struts. En el Listado 1 se muestra
un ejemplo de vista de Struts:page language="java"><%@taglib uri="/WEB−INF/struts−html.tld" prefix="html" >
<html:form action="loginAction.do"name="loginForm"type="edu.gsait.action.ActionForm" >
Nombre: <html:text property="nombre"><br/>Clave: <html:password property="clave"><br/>
<html:submit /></html:form>
Listado 1: Ejemplo de Vista de Struts
Como puede verse, se usan varias etiquetas JSP en esta página. Estas etiquetas están
definidas por el Framework Struts, y proporcionan una conexión con el Controlador de
una aplicación Struts.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 27 UNIVERSIDAD DE SEVILLA
2.2.1.3 El Controlador
El componente Controlador del Framework Struts es el esqueleto de todas las
aplicaciones WEB hechas con Struts. Está implementado usando un servlet llamado
org.apache.struts.action.ActionServlet. Este servlet recibe todas las peticiones de los
clientes, y delega el control de cada petición a una clase que extienda a
org.apache.struts.action.Action, definida por el usuario. El ActionServlet delega el
control basándose en la URI de la petición. Una vez que la clase Action (la que la
extiende más bien) ha completado su procesamiento, devuelve una clave al
ActionServlet, que la usa para determinar la Vista que presentará los resultados del
procesamiento de la Action. El ActionServlet es similar a una factoria que crea objetos
Action para llevar a cabo la lógica de negocio real de la aplicación.
El Controlador del Framework struts es el componente más importante del MVC de
Struts.
2.3 JSP Standard Template Library (JSTL)
2.3.1 Introducción
La librería JSTL (JSP Standard Template Library) es un componente distribuido por
Sun destinado a la programación en JSP. JSTL permite diseñar páginas JSP usando
etiquetas, en lugar de incrustando código Java (lo que se conoce como scriptlets), que es
la práctica más extendida entre los programadores de JSP. Con JSTL puede realizarse
prácticamente todo lo que se puede realizar con scriptlets.
JSTL se introdujo para permitir a los programadores JSP programar usando etiquetas en
lugar de código Java. A continuación se muestra un ejemplo de por qué esto es
preferible. Sea el sencillo ejemplo de una página JSP que cuenta hasta diez. La versión
de esta página usando scriptlets es la que se muestra en el Listado 2.
<html> <head> <title>Cuenta hasta 10 usando scriptlets</title> </head> <body>
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 28 UNIVERSIDAD DE SEVILLA
<% for(int j=1;j<=10;j++){%><%=j%><br/><%}%> </body></html>
Listado 2: JSP de cuenta hasta 10 usando scriptlets.
Como puede verse, el uso de scriptlets da lugar a código fuente que contiene una mezcla
de etiquetas HTML y de sentencias Java. Hay muchas razones por las cuales esta
mezcla de estilos de programación no es óptima.
La primera razón para no mezclar scriptlet y código basado en etiquetas en la
legibilidad. Esta legibilidad aplica tanto a los humanos como a los ordenadores. JSTL
permite al programador humano leer un programa que consiste únicamente en etiquetas
HTML y etiquetas del estilo de HTML.
La legibilidad del código JSP basado en scriptlets no sólo repercute a los humanos. La
mezcla de scriplet y código HTML es duro de leer también para los ordenadores. Esto
es particularmente cierto para las herramientas de desarrollo HTML como por ejemplo
Dreamweaver o FrontPage. Muchas de ellas tratan los scriptles como bloques no
editables, y ni siquiera lo modifican directamente.
El Listado 3 muestra cómo se escribiría el contador hasta diez usando JSTL. Como
puede verse, este listado es mucho más homogéneo puesto que sólo se usan etiquetas
HTML y JSTL.
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %><html> <head> <title>Cuenta hasta 10 (usando JSTL)</title> </head>
<body> <c:forEach var="j" begin="1" end="10" step="1"> <c:out value="${j}" />
<br /> </c:forEach> </body></html>
Listado 3: Ejemplo de cuenta hasta 10 usando JSTL
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 29 UNIVERSIDAD DE SEVILLA
Examinando el código anterior, se observa que la página JSP consiste únicamente en
etiquetas. Se hace uso de etiquetas HTML como <head> y <br>, y también de etiquetas
JSTL como <c:forEach> y <c:out>.
2.3.2 Las librerías JSTL
A menudo se habla de JSTL como una única librería. En realidad, se tratan de cuatro
librerías, que se resumen a continuación:
Core Tag Library – Contiene etiquetas que son esenciales para cualquier
aplicación Web. Ejemlos de estas etiquetas incluyen bucles, evaluación de
expresión y entrada / salida básica.
Formatting / Internationalization Tag Library – Contiene etiquetas que se
usan para formatear datos. Como ejemplo, algunas de ellas se usan para
formatear fechas basándose en las diferentes configuraciones locales.
Database Tag Library – Contiene etiquetas que pueden usarse para acceder a
bases de datos SQL. Estas etiquetas suelen usarse exclusivamente para la
creación de programas prototipo, ya que no es normal acceder a bases de datos
directamente desde las páginas JSP. El acceso a base de datos debe encontrarse
en la lógica de la aplicación, a la que acceden las páginas JSP.
XML Tag Library – Contiene etiquetas que permiten acceder a elementos
XML. Dado el amplio uso de XML en muchas aplicaciones Web, el procesado
XML es una característica muy importante de JSTL.
De todas estas librerías, en el Proyecto se hace uso casi exclusivo de la Core Tag
Library, en particular, de las etiquetas:
• <c:out> : Permite mostrar en la página JSP el contenido de variables Java
almacenadas en los diferentes ámbitos de la aplicación WEB (petición, sesión,
página, etc.)
• <c:if>: Permite establecer una condición en la generación del JSP, basándose en
una expresión EL (que se detallan más adelante)
• <c:forEach>: Permite realizar bucles tanto numéricos, como basados en
colecciones de objetos Java. Es muy útil para la generación de tablas basadas en
listas de objetos Java.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 30 UNIVERSIDAD DE SEVILLA
2.3.3 El lenguaje de Expresión EL
El lenguaje de expresión EL es una de los principales componentes de JSP a partir de la
versión 2.0. EL se usa intensivamente en JSTL. Sea como fuere, es importante recordar
que EL es una característica de JSP y no de JSTL. JSP 2.0 permite usar expresiones EL
dentro de scriptlets, como puede verse en el Listado 4.
<p> El precio con IVA es: ${precio+IVA}</p>
Listado 4: Uso de EL en JSP
Los valores “precio” e “IVA” se añaden y muestran en el momento en que se genera el
HTML. Estas expresiones pueden usarse también dentro de etiquetas JSTL, como se ve
en el Listado 5.
<p> El precio con IVA es: <c:out var="${precio + iva}"/>
</p>
Listado 5: Uso de EL dentro de etiquetas JSTL
2.3.4 Conclusiones
JSTL facilita un entorno de programación más consistente, al permitir que tanto el
HTML como el código procedimental se exprese mediante etiquetas. JSTL y las taglibs
constituyen una corriente cada vez más extendida en la programación de páginas Web.
La combinación de JSTL, etiquetas propias y Struts permite la creación de aplicaciones
JSP muy consistentes y eficientes.
2.4 Java API for XML Processing
2.4.1 Introducción
La API de Java para el procesado de XML (JAXP), permite a las aplicaciones crear,
validar y transformar documentos XML. Estas prestaciones las ofrece de forma
transparente a las implementaciones de parsers y transformadores XML que se utilicen.
Esto es, JAXP ofrece una jerarquía de interfaces que permite construir aplicaciones que
creen, validen y procesen documentos XML, sin preocuparse de las implementaciones
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 31 UNIVERSIDAD DE SEVILLA
concretas. Usando JAXP, el programador garantiza que el código que desarrolla será
válido para cualquier implementación de Parser y Transformer que cumpla las
especificaciones.
Las APIs principales de JAXP están definidas en el paquete javax.xml.parsers. Este
paquete contiene dos clases factoría (independientes del fabricante):
SAXParserFactory y DocumentBuilderFactory, que construyen un SAXParser y un
DocumentBuilder, respectivamente. El DocumentBuilder, a su vez, genera objetos
Document conformes a la estructura DOM.
Las factorías de la API permiten usar una implementación de XML hecha por otro
fabricante sin necesidad de cambiar el código fuente. La implementación a usar depende
del estado de las variables del sistema: javax.xml.parsers.SAXParserFactory y
javax.xml.parsers.DocumentBuilderFactory. Los valores por defecto apuntan a la
implementación de referencia.
Para el desarrollo del proyecto se han empleado las implementaciones por defecto,
puesto que han colmado perfectamente las necesidades del desarrollo.
2.4.2 Paquetes
Las APIs SAX y DOM están definidas por el grupo XML-DEV y por el W3C,
respectivamente. Las librerías que definen esas APIs son:
javax.xml.parsers Las APIs JAXP, que proporcionan una interfaz común
para los parsers SAX y DOM de diferentes fabricantes.
org.w3c.dom Define la clase Document (un DOM), así como clases para todos
los componentes del DOM
org.xml.sax Define las APIs básicas de SAX
javax.xml.transformDefine las APIs XSLT que permiten transformar XML en
otros formatos.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 32 UNIVERSIDAD DE SEVILLA
SAX (Simple API form XML), es el mecanismo dirigido por eventos y de acceso
secuencial que hace un procesado elemento a elemento. La API para este nivel lee y
escribe XML a un repositorio de datos a la Web. Esta API está indicada para
aplicaciones del lado del servidor o aquéllas en las que se desee alto rendimiento.
La API DOM es normalmente más fácil de usar. Proporciona una estructura
relativamente familiar de árbol de objetos. Se puede usar la API DOM para manipular la
jerarquía de los objetos de aplicación que encapsula. La API DOM es ideal para las
aplicaciones interactivas puesto que el modelo de objetos está totalmente en memoria,
pudiendo ser accedido y manipulado por el usuario.
Sin embargo, construír el DOM requiere la lectura completa de la estructura XML y
mantener el árbol de objetos en memoria, lo que se traduce en un mayor consumo de
memoria y CPU. Es por eso que se prefiere la API SAX para aplicaciones de servidor y
filtros de datos que no requieran una representación en memoria de los datos.
Por último, las APIs XSLT definidas en javax.xml.transform permiten escribir datos
XML a un archivo o convertirla a otros formatos.
2.4.3 Las APIs SAX (Simple API for XML)
El funcionamiento básico del procesado SAX se muestra en la Figura 5.
Figura 5: Funcionamiento del Procesado SAX
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 33 UNIVERSIDAD DE SEVILLA
Para comenzar el proceso, una instancia de SAXParserFactory se usa para generar una
instancia del parser.
El parser encapsula un objeto SAXReader. Cuando el método parse() del parser se
invoca, el reader invoca uno de los muchos métodos de retrollamada (callback methods)
implementados en la aplicación. Estos métodos están definidos por las interfaces
ContentHandler, ErrorHandler, DTDHandler y EntityResolver.
Un resumen de las principales APIs SAX se muestra a continuación:
SAXParserFactory Un objeto SAXParserFactory crea una instancia del parser
basándose en la propiedad del sistema javax.xml.parsers.SAXParserFactory
SAXParser La interfaz SAXParser define muchos tipos de métodos parse().
En general, al parser se le pasa una fuente de datos XML y un objeto
DefaultHandler, que procesa el XML e invoca los métodos apropiados en el
objeto handler.
SAXReader El SAXParser encapsula un SAXReader. El SAXReader es el
encargado de comunicarse con los handlers de eventos SAX definidos.
DefaultHandler No aparece en el diagrama. Un DefaultHandler
implementa las interfaces ContentHandler, ErrorHandler, DTDHandler y
EntityResolver con métodos vacíos. Aquéllos que interesen pueden ser
sobrescritos.
ContentHandler Métodos como startDocument, endDocument,
startElement y endElement son invocados cuando se reconoce una etiqueta
XML. Esta interfaz también define los métodos characters y
processingInstruction, que se invocan cuando el parser encuentra el texto en un
elemento XML o una instrucción de proceso en línea respectivamente.
ErrorHandler Los métodos error, fatalError y warning, se invocan en
respuesta a diversos errores de parseado. El manejador de error por defecto lanza
una excepción cuando se producen errores fatales e ignora otros errores (incluso
los de validación). Por eso es conveniente conocer el parser SAX, ya que a veces
es necesario proporcionar un manejador de errores personalizado.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 34 UNIVERSIDAD DE SEVILLA
DTDHandler Define métodos que no se usarán casi con toda seguridad.
Se usa cuando se procesa un DTD para reconocer y actuar ante declaraciones de
una entidad no parseada.
Entity Resolver El método resolveEntity se invoca cuando el parser debe
identificar datos determinados por una URI. En la mayoría de los casos, una URI
es simplemente una URL, que especifica la localización de un documento, pero
en algunos casos el documento puede estar determinado por una URN – un
identificador público, o nombre, que es único en el espacio web. El identificador
público puede indicarse como complemento a la URL. El EntityResolver puede
entonces usar el identificador público en vez de la URL para encontrar el
documento, por ejemplo para acceder a una copia local del mismo si es que
existe.
Una aplicación típica implementará casi todos los métodos de ContentHandler como
mínimo. Para lograr una aplicación robusta, se recomienda implementar también los
métodos de ErrorHandler.
2.4.4 Los paquetes de SAX
El parser SAX se define en los siguientes paquetes:
Paquete Descripción
org.xml.sax Define las interfaces SAX. El nombre “org.xml” es el prefijo de
paquetes que fue establecido por el grupo que definió la API SAX
org.xml.sax.ext Define las extensiones de SAX que se usan al hacer un procesado
SAX más sofisticado, por ejemplo, para procesar DTDs o para ver
la sintaxis detallada de un fichero.
org.xml.sax.helpers Contiene clases auxiliares que facilitan el uso de SAX – por
ejemplo, definiendo un manejador por defecto con métodos vacíos
para todas las interfaces, de modo que sólo habría que sobrescribir
los que interesaran.
javax.xml.parsers Define la clase SAXParserFactory, que construye el SAXParser.
También define las clases de excepción para informar acerca de
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 35 UNIVERSIDAD DE SEVILLA
Paquete Descripción
errores.
Tabla 2: Paquetes de la API SAX
2.4.5 Las APIs DOM (Document Object Model)
La Figura 6 muestra las APIs JAXP en acción.
Figura 6: Las APIs DOM de JAXP en acción
La clase javax.xml.parsers.DocumentBuilderFactory se emplea para obtener una
instancia de DocumentBuilder, que se usa para producir un Document (DOM),
conforme a la especificación DOM. El builder que se obtiene viene determinado por la
propiedad del sistema javax.xml.parsers.DocumentBuilderFactory, que elija la
implementación de builder que produce la factoría (el valor por defecto de la plataforma
puede sobrescribirse a través de la línea de comandos).
También puede usarse el método newDocument() de DocumentBuilder para crear un
Document vacío que implemente la interfaz org.w3c.dom.Document. Alternativamente,
se puede usar uno de los métodos de parseado del builder para crear un Document a
partir de datos XML existentes. El resultado es un árbol DOM como el que se muestra
en la Figura 6.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 36 UNIVERSIDAD DE SEVILLA
2.4.6 Paquetes de la API DOM de JAXP
Paquete Definición
org.w3c.dom Define las interfaces de programación de DOM para
documentos XML y, opcionalmente, HTML, como especifica
el W3C
javax.xml.parsers Define las clases DocumentBuilderFactory y
DocumentBuilder, que devuelven un objeto que implementa la
interfaz Document del W3C. La factoría que se usa para crear
el builder se especifica en la propiedad del sistema
javax.xml.parsers, que puede indicarse en línea de comandos o
bien a través del método newInstance. Este paquete también
define la excepción ParserConfigurationException para
informar acerca de errores.
Tabla 3: Paquetes de la API DOM de JAXP
2.4.7 Las APIs XSLT (XML Stylesheet Translation)
La Figura 7 muestra las APIs XSLT en acción:
Figura 7: Las APIs XSLT de JAXP en acción
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 37 UNIVERSIDAD DE SEVILLA
Se instancia un objeto TransformerFactory, y se usa para crear un Transformer. El
objeto fuente es la entrada al proceso de transformación. Un objeto fuente puede crearse
a partir de un SAX reader, de un DOM o de una flujo de entrada.
De forma análoga, el objeto resultante es el resultado del proceso de transformación.
Ese objeto puede ser un manejador de eventos SAX, un DOM o un flujo de salida.
Cuando se crea el transformer, éste puede crearse a partir un conjunto de instrucciones
de transformación, en cuyo caso éstas son llevadas a cabo. Si se crea sin instrucciones
específicas, entonces el Transformer simplemente copia el origen al resultado.
2.4.8 Los paquetes XSLT
Paquete Descripción
javax.xml.transform Define las clases TransformerFactory y Transformer, que
se emplean para obtener objetos capaces de hacer
transformaciones. Tras crear un objeto transformer, se
invoca el método transform(), al que se le debe facilitar
una entrada (origen) y unaa salida (resultado).
javax.xml.transform.dom Clases para crear objetos entrada (origen) y salida
(resultado) a partir de un DOM.
javax.xml.transform.sax Clases para crear objetos de entrada (origen) y de salida
(resultado) a partir de un manejador de eventos SAX.
Javax.xml.transform.stream Clases para crear objets entrada (origen) y salida
(resultado) a partir de un flujo de entrada / salida
2.5 Log4j
Log4j es un API de fuentes abiertas para traza (logging), desarrollado bajo el proyecto
Jakarta Apache. Proporciona un framework robusto, fiable, totalmente configurable,
fácilmente extensible y fácil de implementar para el trazado de aplicaciones Java con
propósitos de depuración o monitorización.
Log4j permite insertar sentencias de traza en el código y configurarlas externamente.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 38 UNIVERSIDAD DE SEVILLA
2.5.1 Motivaciones para su uso
El trazado (logging), o escritura del estado de un programa en varias fases de su
ejecución a algún repositorio como por ejemplo un fichero, es un método tradicional
usado para depurar y monitorizar aplicaciones. La tendencia natural es usar las
sentencias de impresión de mensajes del lenguaje en cuestión (System.out.println() en el
caso de Java).
Insertar sentencias de traza manualmente es tedioso y ralentiza el trabajo, por no
mencionar la modificación de las mismas a lo largo de aplicaciones de considerable
entidad. Es en estos escenarios cuando es útil, eficiente y fácil de usar la API log4j.
2.5.2 Funcionalidades de log4j
1. Log4j maneja la inserción de sentencias de traza en el código de la aplicación y
su modificación externamente, sin tocar el código de la aplicación. Para ello se
basa en archivos de configuración externos.
2. Log4j categoriza las sentencias de traza de acuerdo con criterios establecidos por
el usuario y asigna diferentes niveles de prioridad a esas sentencias de traza.
Estos niveles de prioridad deciden qué sentencias de traza son lo bastante
importantes como para ser volcadas en el repositorio de traza.
3. Log4j permite a los usuarios elegir entre varios destinos para las sentencias de
traza, tales como la pantalla, un fichero, bases de datos, servidores SMTP,
componentes gráficos, etc.; con la opción de asignar diferentes destinos a
diferentes categorías de las sentencias de traza. Estos destinos pueden cambiarse
en cualquier momento con una simple modificación de los ficheros de
configuración de log4j.
4. Log4j también facilita la creación de formatos personalizados para la salida de
traza y proporciona formatos por defecto.
Log4j funciona basándose en tres componentes principales, cuyas funcionalidades están
accesibles a través de clases del mismo nombre:
Logger Es el componente que acepta las peticiones de log durante
la ejecución de la aplicación. Lo normal es asignar un Logger a cada
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 39 UNIVERSIDAD DE SEVILLA
clase o jerarquía de clases de la aplicación. El Listado 6 muestra un
ejemplo de creación de Logger para una clase del Proyecto.
[…]
public class GestionSSH { /** * Logger */ static Logger logger = LogManager.getLogger(GestionSSH.class);
[…]
Listado 6: Creación de un Logger
Log4j tiene definidos por defecto cuatro niveles de prioridad para las
sentencias de traza, que son: DEBUG, INFO, ERROR, FATAL. Para
solicitar al Logger que muestre una sentencia de traza, se invoca el
método cuyo nombre coincida con el nivel de prioridad que se desea para
la misma, esto es:
[…] // Mensaje de nivel DEBUG logger.debug(“Este mensaje de traza tiene nivel de DEBUG”);
// Mensaje de nivel FATAL logger.fatal(“Este mensaje tiene de nivel fatal”);
[…]
Listado 7: Inserción de sentencias de log de distintos niveles de prioridad
Aprender: Es la clase que representa cada uno de los posibles
repositorios donde se volcarán las sentencias de traza. Los diferentes
tipos de repositorio (consola, fichero, base de datos, etc) vendrán
representados por diferentes implementaciones de la clase Appender. A
cada Aprender se le pueden asignar uno o varios Logger que vuelquen la
información sobre ellos.
Layout Es la clase que representa el formato con el que se
muestran las diferentes sentencias de traza. Puede asignarse un layout
específico para cada Aprender.
Tanto la asignación de Appenders, como la creación de los diferentes Layouts, el
establecimiento de los niveles de prioridad, y en general, todas las tareas de
configuración de log4j pueden realizarse de dos formas: programáticamente (en el
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 40 UNIVERSIDAD DE SEVILLA
código Java) o bien mediante un fichero de configuración. Ésta es la opción que se ha
elegido en el Proyecto. Se configura un fichero, de nombre log4j.properties, que debe
encontrarse en el classpath de la aplicación, y cuyo contenido se muestra en el Listado
8.
# Logger Raíz ----------------------------------# Nivel del logger principal y appender asignadolog4j.rootLogger=DEBUG, A1
# A1 saldra por consolalog4j.appender.A1=org.apache.log4j.ConsoleAppender
# Definici\u00F3n del patr\u00F3n de A1log4j.appender.A1.layout=org.apache.log4j.PatternLayout#log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x -%m%nlog4j.appender.A1.layout.ConversionPattern=[GSAIT] %-5p %c %x - %m%n# -----------------------------------------------
# Logger de la aplicación ------------------------log4j.logger.edu=DEBUGlog4j.logger.edu.gsait.XML=FATAL
Listado 8: Fichero de configuración de log4j para el Proyecto GSAIT
Básicamente, esta configuración gestiona la salida de una traza a través de la consola,
con nivel DEBUG (es decir, se mostrarán todos los mensajes puesto que el nivel de
DEBUG es el de más baja prioridad), y con un determinado formato.
2.6 Seguridad
2.6.1 Secure Socket Layer (SSL)
SSL o Secure Socket Layer provee una “capa” para asegurar los protocolos de Internet
(como http, SMTP, FTP, etc) y prevenir que la información transmitida por ellos sea
falsificada, modificada o interceptada por terceras personas mientras se encuentra en
tránsito por la red.
SSL opera mediante el intercambio de claves entre el cliente y el servidor para poder
descrifrar la información que ha sido codificada por un algoritmo de cifrado simétrico.
Lo que esto significa es que los datos encriptados sólo pueden ser desencriptados por el
poseedor de la clave correcta.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 41 UNIVERSIDAD DE SEVILLA
La información que viaja por SSL puede ser encriptada con diferentes algoritmos
simétricos, típicamente DES, Triple DES, Rijndael o IDEA. El término simétrico en
este caso implica que los datos que han sido desencriptados pueden ser desencriptados
después (a diferencia de hashes como SHA1 o MD5 que son sólo “hacia un lado”).
La longitud de las claves determina la dificultad para poder desencriptar el contenido
cifrado. Las claves comúnmente usadas por los sitios hoy en día son de 40 y 128 bits.
Los fundamentales problemas que SSL intenta resolver son los siguientes:
Seguridad de la Información SSL garantiza que terceros no tengan
acceso a la información mientras viaja por Internet al encriptarla.
Integridad de los datos La información recibida desde un servidor por SSL
puede ser “validada” para comprobar que no ha sido alterada en la trayectoria.
Autenticidad de los datos Mediante los algoritmos de encriptación, es posible
comprobar que los datos realmente han llegado del servidor que el cliente
espera. Esto evita que alguien se haga pasar por un sitio para cometer fraudes.
(evitando ataques como Phishing, Man in the Middle, etc).
Mediante el uso de certificados digitales avalados por autoridades certificadoras SSL
incorpora un eslabón más en la cadena de confianza.
Los certificados digitales son una forma de agregar un tercer "árbitro" a la cadena de
confianza de la comunicación por SSL. Lo que un certificado digital hace es agregar el
"endoso" de un tercero que garantiza la integridad, y existencia de la organización que
envía los datos. Esto significa que una autoridad certificadora avala que la empresa que
es dueña del sitio web, por ejemplo, realmente existe.
La aplicación Web desarrollada debe en algunos momentos transportar en sus peticiones
información sensible. Tal es el caso de la pantalla de login, donde se solicita la
contraseña al usuario, o bien las pantallas de gestión de servidores donde se transmite
información valiosa como claves, datos personales o notas de los alumnos. Es preciso
en esos casos el empleo de un protocolo seguro que haga bastante difícil que dicha
información pueda ser interceptada y / o alterada por terceros. Surge aquí HTTPS.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 42 UNIVERSIDAD DE SEVILLA
HTTPS es la versión segura del protocolo HTTP. HTTPS utiliza un cifrado basado en
SSL para crear un canal cifrado. El tipo de cifrado empleado en el canal se decide
mediante una negociación entre el servidor y el cliente, usándose el cifrado más
sofisticado que ambos puedan entender. De este modo, el canal que se tiene es más
apropiado para el tráfico de información sensible que el ofrecido por el protocolo
HTTP.
2.6.2 Seguridad en la comunicación con servidores remotos. JavaSecure Channel (JSch)
Como se explicó en la introducción de la presente memoria, uno de los pasos en el
proceso de modificación de los archivos de configuración es su descarga al GSAIT y
posterior subida al servidor original. Evidentemente, estas transacciones deben
realizarse de forma segura, de forma que el empleo del protocol SSH se hace
imprescindible.
Java Secure Channel, de JCraft, es una implementación puramente en Java del protocolo
SSH2. JSch permite establecer conexiones con servidores ssh y usar reenvío de puertos,
envío X11, transferencia de archivos… e integrar esta funcionalidad en aplicaciones
Java.
Dada la amplísima gama de funcionalidades que proporciona esta API, y dado el uso
muy concreto que se hace de la misma, se omite una descripción exhaustiva, y se remite
al lector a futuras secciones donde se comenta el uso que de JSch se hace en el presente
Proyecto.
2.6.2.1 Secure Shell (SSH)
Una de las necesidades de la aplicación consiste en la descarga y subida de ficheros a
servidores remotos, así como en la ejecución de comandos de forma remota en los
mismos. Evidentemente, todas estas operaciones deben hacerse de forma segura, lo cual
descarta de raíz el empleo de protocolos como Telnet.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 43 UNIVERSIDAD DE SEVILLA
La solución adoptada, consistente en el empleo de la API JSch (Java Secure Channel,
comentada en secciones anteriores), introduce el empleo de SSH. SSH (Secure Shell),
es la evolución, en términos de seguridad, del Telnet.
SSH permite ejecutar comandos remotos, así como cargar y descargar archivos de
servidores, pero garantizando la confidencialidad de las comunicaciones, y la
autenticidad de las partes implicadas. Permite diversos algoritmos de autenticación y de
encriptado / desencriptado.
Existen dos versiones de SSH, SSH1 y SSH2. Ambos son protocolos totalmente
diferentes e incompatibles. SSH2 es una nueva versión de SSH escrita desde cero y
optimizada en términos de seguridad y rendimiento. Ésta es la versión que se emplea en
JSch, y es por tanto, la que se emplea en el presente Proyecto.
Para que la aplicación pueda establecer una conexión SSH con los servidores remotos,
éstos deben tener corriendo un demonio de SSH. El programa ‘sshd’, presente en la
mayor parte de las distribuciones de Linux actuales, permite establecer dichas
conexiones y realizar todas las tareas necesarias de forma correcta.
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 44 UNIVERSIDAD DE SEVILLA
3 Funcionalidades del ProyectoEn este apartado se van a describir de forma detallada las diferentes funcionalidades que
ofrece el GSAIT.
Administración del GSAIT Esta sección permitirá a aquellos usuarios
del sistema acreditados como “administradores” del mismo, gestionar los
parámetros y tablas básicas de funcionamiento del servidor. Esto se realizará a
través de las pantallas:
o Gestión de Roles Permite la creación, eliminación y actualización de
los diferentes roles del sistema. Los roles son perfiles, que permiten
identificar a grupos de usuarios de la aplicación con determinados
permisos para realizar determinadas acciones (por ejemplo, gestionar el
GSAIT, gestionar ficheros configurables, etc).
o Administración de Servicios Permite la creación, eliminación y
actualización de servicios configurables por el GSAIT. Dentro de cada
servicio, se permite la creación, eliminación y actualización de los datos
de acceso a los diferentes ficheros de configuración que se desea que el
GSAIT gestione. A cada uno de estos ficheros se les asigna un grupo de
roles que están autorizados a modificarlos (es decir, se dispone de un
control de acceso muy flexible a los mismos).
o Administración de Usuarios Permite la creación, eliminación y
actualización de usuarios del sistema, así como la asignación a cada uno
de ellos de los roles que correspondan.
Administración de Servicios Esta sección permitirá a aquellos usuarios
del sistema acreditados como “configuradores” la modificación, mediante
interfaz gráfica, de los contenidos de los diferentes ficheros de configuración .
Además de disponer de acreditación de “configurador”, el usuario en cuestión
debe pertenecer a alguno de los roles autorizados a modificar el fichero en
cuestión (autorizaciones gestionadas desde la pantalla de Administración de
Servicios).
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 45 UNIVERSIDAD DE SEVILLA
Administración del Servicio de Calificaciones Esta sección permite, a los
usuarios con permisos de “administrador”, gestionar los parámetros de
funcionamiento del servidor SNAIT relativos a la inserción de listados de
alumnos e inserción de calificaciones desde el GSAIT. Esta gestión se realiza
mediante dos pantallas:
o Gestión de Rutas del SNAIT Al actualizar los datos sobre las
asignaturas del SNAIT, así como las listas de notas, el GSAIT debe
actualizar el contenido de los ficheros correspondientes en el SNAIT.
Este apartado permite indicar las rutas de ubicación de dichos ficheros en
el servidor SNAIT.
o Gestión de Asignaturas Este apartado permite añadir, modificar y
eliminar los datos sobre las diferentes asignaturas que se gestionarán
desde el GSAIT. También se permite asignar a cada asignatura los
profesores que la imparten (y que, por lo tanto, tienen permiso para
insertar listados de alumnos y/o exámenes). Los datos modificados aquí
que incumban al servidor SNAIT se sincronizan en los ficheros
correspondientes de dicho servidor en el momento de la modificación.
Profesores Este apartado permite, a los usuarios con permisos de “profesor”,
gestionar los datos relativos a las asignaturas que imparte (y que le son
asignadas por medio de la pantalla “Gestión de Asignaturas”). El profesor puede
insertar y actualizar datos relativos a los listados de alumnos de la asignatura, a
partir de un fichero generado fácilmente a partir de una hoja Excel. Igualmente,
se permite insertar calificaciones de exámenes a partir de ficheros derivados de
hojas Excel. Por último, se ofrece en este apartado acceso al servidor de
publicación de calificaciones (SCAIT), de forma que el profesor pueda decidir
qué exámenes publicar y en qué soporte (web, email, sms).
Todos los cambios realizados en esta sección y que afecten al SNAIT, producen
una sincronización con los ficheros correspondientes de dicho servidor, de forma
que la información albergada por el GSAIT y la albergada en el SNAIT sea
coherente el máximo tiempo posible.
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 46 UNIVERSIDAD DE SEVILLA
Tras esta descripción breve, se procede a continuación a describir detalladamente
cómo el GSAIT ofrece todas estas funcionalidades.
3.1 Terminología
Para entender la funcionalidad de la aplicación conviene hacer una breve discusión
acerca de la forma en que el GSAIT gestiona los permisos de usuario. Esta gestión está
basada en roles, de forma semejante a la gestión de usuarios que presenta, por ejemplo,
Jakarta Tomcat.
Un rol identifica a un grupo de usuarios que tienen permisos para realizar un
determinado conjunto de acciones. Es decir, el proceso para dar sentido a un rol sería el
siguiente:
1.- Crear el rol.
2.- Asignar ese rol como rol autorizado a todas las acciones a las que se desee que tenga
permiso (por ejemplo, asignar el rol a aquellos ficheros de servicios a los que se desee
que pueda configurar).
3.- Asignar ese rol a todos aquellos usuarios del sistema que se desee que esté
autorizado a relizar todas aquellas acciones a las que se autorizó el rol en cuestión en el
apartado 2.
De este modo, un usuario estará autorizado a realizar todas aquellas acciones que les
permita el conjunto de roles que tiene asignado.
Mención aparte merecen los roles del sistema. Por roles del sistema se conoce a un
grupo de roles básicos, con unos permisos perfectamente definidos y que son inherentes
al sistema. Estos roles son:
ROOT_GSAIT Es el rol que permite acceder a la administración del
GSAIT (roles, usuarios, servicios), así como a la administración de los datos
relacionados con el SNAIT (rutas y asignaturas).
CONFIGURADOR Es el rol que da acceso a la modificación de los archivos
de configuración de los diferentes servicios. Nótese que, además de disponer de
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 47 UNIVERSIDAD DE SEVILLA
este rol, para modificar un fichero en concreto es necesario que el usuario
disponga de un rol que se encuentre entre los autorizados para ese fichero (lo
cual se establece en la pantalla de “Gestión de Servicios”).
PROFESOR Es el rol que da acceso a la gestión de las diferentes asignaturas
que tenga asignado el usuario (y que se asignan en la pantalla de “Gestión de
Asignaturas”).
3.2 Gestión del Acceso a la Aplicación
3.2.1 Autenticación
Cuando el usuario accede a la aplicación, aparece la pantalla de login. En ella, el usuario
debe facilitar su nombre corto (o login) y su clave de acceso. Si los datos
proporcionados, por el usuario son correctos, se accede al Menú Principal de la
aplicación. En caso contrario, se vuelve a mostrar la pantalla de login y aparece un
mensaje de error.
Figura 8: Pantalla de login del GSAIT
3.2.2 Menú Principal
Una vez que el usuario ha accedido a la aplicación aparece el menú principal. El menú
principal mostrará sólo aquellos apartados a los que el usuario tenga acceso en función
de aquellos roles del sistema que posea. De cara a poder discutir todos los apartados,
supóngase el caso de un usuario que posee todos los roles de sistema (ROOT_GSAIT,
CONFIGURADOR y PROFESOR), de forma que el menú se presenta completo.
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 48 UNIVERSIDAD DE SEVILLA
Figura 9: Menú principal de GSAIT
Desde este menú se accede a las diferentes secciones de la aplicación.
3.3 Gestión del GSAIT
3.3.1 Gestión de Roles
Esta pantalla permite la inserción, actualización y eliminación de los roles de la
aplicación. Para ello se ofrece un formulario HTML como el que se muestra en la
Figura 10.
Figura 10: Formulario de Gestión de Roles
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 49 UNIVERSIDAD DE SEVILLA
3.3.2 Gestión de Usuarios
En este apartado se permite la inserción, actualización y eliminación de los datos
relativos a los usuarios de la aplicación. Para ello se ofrece un formulario como el que
se aprecia en la Figura 11.
Puede observarse en dicha figura la interfaz intuitiva que se proporciona para la
asignación de roles. En ella el usuario asigna y retira los roles seleccionándolos en unas
listas y pulsando el botón correspondiente.
Figura 11: Formulario de Gestión de Usuarios del GSAIT
3.3.3 Gestión de Servicios
Para comprender esta funcionalidad es conveniente discutir brevemente qué se entiende
por servicio en el GSAIT. El objetivo fundamental del GSAIT, como ya se ha
comentado, es ofrecer una interfaz Web para modificar ficheros de configuración en
texto plano. Dichos ficheros son ficheros de configuración de diferentes programas que
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 50 UNIVERSIDAD DE SEVILLA
se ejecutan como servidores en el Área de Ingeniería Telemática. Pues bien, es a cada
uno de esos programas, a los que se denomina “Servicio”, pudiendo tener por tanto cada
servicio cualquier número de ficheros de configuración asociados. Éste es el caso, por
ejemplo, del servidor de notas SNAIT, que posee entre otros, los ficheros de
configuración snait.ini y lista.cfg. De esta definición se excluyen ciertos ficheros
específicos del SNAIT, que albergan datos sobre calificaciones, y que son gestionados
desde la zona de Gestión de Asignaturas.
La pantalla de gestión de Servicios permite insertar, actualizar y eliminar los datos
relativos a los diferentes servicios sobre cuyos ficheros de configuración el GSAIT
puede actuar. Dicha funcionalidad se ofrece mediante un formulario como el que se
muestra en la Figura 12. En él puede observarse cómo, al seleccionar uno de los
servicios, se actualiza también la lista de ficheros de configuración que éste posee,
permitiendo la inserción, actualización y eliminación de los mismos.
Figura 12: Pantalla de Gestión de Servicios
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 51 UNIVERSIDAD DE SEVILLA
También se permite en esta pantalla la asignación de los roles que están autorizados a
modificar un determinado fichero de configuración, de forma análoga a como se realiza
la asignación de roles a los usuarios del sistema.
3.3.3.1 Procesamiento de los ficheros
GSAIT ofrece un motor que permite habilitar la modificación de ficheros de cualquier
formato, ofreciendo un formulario de configuración amigable y sencillo. Para ello, tal y
como se explicó someramente en la introducción, y tal y como se desarrollará en
profundidad en el capítulo de gestión del servidor, por cada fichero a configurar es
necesario facilitar tres archivos:
Procesador de Descarga: Es el fichero que guía la transformación a aplicar al
fichero de configuración, de forma que como resultado se tenga un documento
XML en formato específico de GSAIT (y que se detallará en su momento). Este
procesador puede ser:
o Un XML de transformación para atox Si el fichero a configurar es
de texto plano, el GSAIT lo transforma usando la herramienta ‘atox’.
Esta herramienta necesita un XML que indique las transformaciones a
efectuar (y cuyo formato será detallado en el apartado de Gestión del
Servidor).
o Una hoja XSLT Si el fichero a configurar es de por sí un
documento XML.
Descriptor de formulario Es necesario describir qué campos y de qué tipo
constará el formulario amigable que se mostrará al usuario. Para ello será
necesario facilitar un documento XML, cuya estructura se discute en el apartado
de Gestión.
Procesador de Subida Tras la intervención del usuario, el formulario
genera un XML en el mismo formato del que se obtuvo tras la aplicación del
procesador de descarga. Es necesario convertir este XML al formato propietario
original del fichero de configuración. Para ello se debe proporcionar una hoja
XSLT que realice esta transformación.
Pues bien, la pantalla de gestión de Servicios, más concretamente en la zona de gestión
de Ficheros, ofrece la posibilidad de asociar a cada fichero sus procesadores. Por cada
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 52 UNIVERSIDAD DE SEVILLA
uno de ellos (procesador de descarga, descriptor de formulario y procesador de subida),
se permite Subir una nueva versión, o bien visualizar la asignada actualmente.
3.4 Administración Específica del Servicio de Calificaciones
3.4.1 Rutas Ficheros SNAIT
En esta pantalla se permite especificar las rutas absolutas en el servidor SNAIT de:
El fichero que contiene la lista con las asignaturas, el nombre del fichero de
audio de cada una, y el nombre del fichero de calificaciones de cada una.
El directorio donde se ubican los ficheros de calificaciones de las asignaturas.
Para ello se ofrece un sencillo formulario, como se muestra en la Figura 13.
Figura 13: Gestión de Rutas del SNAIT
3.4.2 Gestión de Asignaturas
Esta pantalla permite la inserción, actualización y eliminación de los datos relativos a
las diferentes asignaturas que gestiona el SNAIT, y por extensión el GSAIT. Esto se
permite mediante el formulario que se muestra en la Figura 14.
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 53 UNIVERSIDAD DE SEVILLA
Figura 14: Gestión de Asignaturas
Como puede observarse, la asignación de los profesores a cada asignatura se realiza
mediante una interfaz muy parecida a la que se usa para la asignación de roles a los
usuarios.
Las modificaciones realizadas en esta pantalla que deban tener repercusión en alguno de
los ficheros del SNAIT, dan lugar a la inmediata actualización de los mismos, vía SSH,
y al reinicio del servidor. De este modo, se intenta mantener la máxima coherencia
posible entre los datos existentes en el GSAIT y los existentes en el SNAIT.
3.5 Gestión de Servicios
3.5.1 Configuración del funcionamiento de los servicios
Ésta es la sección que ofrece la funcionalidad fundamental para la cual el GSAIT fue
diseñado, esto es, la modificación, mediante una interfaz amigable de ficheros de
configuración de diferentes servicios.
Al acceder a esta sección, la aplicación muestra el árbol de los servicios que gestiona el
GSAIT. En dicho árbol, que se muestra en la Figura 15, el usuario selecciona el fichero
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 54 UNIVERSIDAD DE SEVILLA
que desea modificar. Para ello, el usuario debe disponer de los roles adecuados, pues en
caso contrario dicho fichero aparecería inhabilitado.
Figura 15: Captura del árbol de servicios del GSAIT
Una vez que el usuario selecciona el fichero que se desea configurar, la aplicación
descarga dicho fichero y le aplica los procesamientos oportunos, de forma que
finalmente muestra el formulario de configuración de dicho fichero (Figura 16).
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 55 UNIVERSIDAD DE SEVILLA
Figura 16: Formulario de Configuración de un archivo gestionado por GSAIT
El usuario puede modificar los valores que desee, hasta finalmente Actualizar. La
aplicación procesará los nuevos valores y generará la nueva versión del fichero de
configuración, que se sube al servidor. Finalmente, dicho servidor es reiniciado para que
los cambios tengan efecto.
3.6 Gestión de Calificaciones
Una vez que se accede a esta sección, el profesor dispone de acceso a todas aquellas
asignaturas que imparte. Asimismo, se ofrece acceso al servicio de Publicación de Notas
(mediante un enlace al servidor SCAIT). Todo esto se ofrece en un menú como el que
se muestra en la Figura 17.
Tras seleccionar la asignatura que se desea gestionar, aparece una nueva pantalla, el
llamado Panel de Control de la Asignatura. Desde dicha pantalla, que se muestra en la
Figura 18, el usuario tiene acceso a las siguientes funcionalidades:
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 56 UNIVERSIDAD DE SEVILLA
Figura 17: Panel de Control del Profesor
Figura 18: Panel de control de una asignatura
Inserción / Modificación del listado de alumnos de la asignatura Al
seleccionarlo, se accede a un formulario donde se permite al profesor insertar el
listado de alumnos de la asignatura. Se debe asignar dicho listado a alguno de
los años académicos, y debe facilitarse en formato CSV. Este formato se obtiene
fácilmente a partir de una hoja Excel. La hoja Excel con el listado debe estar
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 57 UNIVERSIDAD DE SEVILLA
compuesta exclusivamente por dos columnas, la primera de ellas con cabecera
DNI, y la segunda con cabecera NOMBRE. Al seleccionar Guardar Como, se
elige Formato CSV. El fichero así obtenido es el que debe facilitarse a través del
campo destinado a tal efecto en el formulario.
Si ya existe un listado de alumnos para esa asignatura y año académico, éste se
muestra en esta misma página. Si ya existe un listado, y se inserta otro nuevo,
éste sobrescribirá totalmente al anterior.
Figura 19: Gestión del Listado de Alumnos de una Asignatura
Al seleccionar un año académico distinto, los datos del listado se actualizan
consecuentemente.
Modificación / eliminación de los datos de exámenes ya introducidos El
panel de control de la asignatura ofrece un listado con los exámenes ya
introducidos. El usuario puede modificar los datos de alguno de ellos o
eliminarlo.
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 58 UNIVERSIDAD DE SEVILLA
Inserción de un nuevo examen
Tanto la modificación de un examen ya introducido como la inserción de uno nuevo dan
paso al formulario de gestión de exámenes, que se muestra en la .
Figura 20: Pantalla de gestión de datos de examen
Este formulario permite modificar todos los datos relativos al examen. Permite
asimismo, subir el fichero CSV derivado de la hoja Excel con las notas del examen. La
hoja Excel de origen debe contener las columnas DNI, Nota numérica y, opcionalmente,
Nota Literal. Todos estos formatos serán descritos detalladamente en el apartado de
Gestión del Servidor.
Toda actualización de los datos de notas de un examen, da lugar a una actualización del
fichero de configuración correspondiente en el SNAIT, de forma que la información de
dicho servidor permanezca lo más coherente posible con la del GSAIT.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 59 UNIVERSIDAD DE SEVILLA
4 Descripción detallada de la aplicaciónEn este apartado se va a llevar a cabo una descripción bastante detallada de cómo se han
implementado las funcionalidades que se han mencionado en capítulo anterior. El
GSAIT se trata de una aplicación de tres capas, y en ellas se desglosará la descripción
del presente apartado:
Capa de persistencia
Lógica de la aplicación
Capa de presentación
4.1 Capa de Persistencia
4.1.1 El patrón DAO / DTO.
La aplicación se ha diseñado intentando independizar lo máximo posible la lógica de la
misma del tipo concreto de capa de persistencia de datos sobre la que se base. Para
conseguir esto, se ha hecho uso del patrón DAO / DTO que, básicamente, consiste en
manejar la persistencia de datos usando dos tipos de objetos:
DTO (Data Transfer Objects): Son simples beans de Java que representarán a las
entidades de la capa de persistencia (por ejemplo, las tablas, en el caso de las
bases de datos relacionales).
DAO (Data Access Objects): Son los objetos Java que se encargan de acceder a
la capa de persistencia, obtener los datos y rellenar con ellos los DTOs.
Los DAOs se diseñan como interfaces que ofrecen los métodos de acceso a los datos.
Por cada tipo de capa de datos que se tenga, se empleará una implementación u otra de
estos DAOs. Al usar las interfaces DAO en el código, se consigue una aplicación en la
que puede cambiarse fácilmente la capa de persistencia sin cambiar la lógica, sino
únicamente la implementación concreta de dichas interfaces.
Para la elaboración de este Proyecto se ha escogido como capa de persistencia una base
de datos relacional. De ahí que, como se verá más adelante, además de las interfaces
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 60 UNIVERSIDAD DE SEVILLA
DAO de acceso a los diferentes objetos, se hayan desarrollado las implementaciones de
las mismas que emplean JDBC para la obtención de los datos.
4.1.2 Base de datos relacional.
El Proyecto se ha desarrollado sobre una base de datos relacional PostgreSQL. Esta
base de datos tiene la peculiaridad de que está compartida con el Servidor de
Calificaciones del Área de Ingeniería Telemática (SCAIT). El motivo es que el GSAIT
lee la información sobre los alumnos, asignaturas y notas de exámenes; y esta
información la necesita el SCAIT para llevar a cabo sus servicios de publicación.
4.1.3 Modelo de datos
Sin entrar en detalles concretos sobre los campos de cada tabla, el modelo de datos de la
aplicación puede verse en la Figura 21.
Figura 21: Modelo de datos del GSAIT
Relacion usuario rol Relacion fichero rolUSUARIO ROL* * FICHERO* *
SERVIDOR
*1
ASIGNATURA
**
Relacion_usuario_asignatura
ALUMNO* *
alumno_asignatura
EXAMEN*
1
*
*
alumno_examen
RUTASSNAIT
CURSOACADEMICO* 1
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 61 UNIVERSIDAD DE SEVILLA
Las diferentes entidades que participan en el modelo son:
USUARIO Representa a los diferentes usuarios del sistema: tanto
administradores, como configuradores, como profesores.
ROL Representa los diferentes roles que pueden tener los usuarios del sistema
FICHERO Representa cada uno de los ficheros de configuración que se
pueden gestionar mediante el GSAIT
SERVIDOR Representa cada uno de los “servicios” que contiene ficheros de
configuración que se pueden gestionar mediante el GSAIT
ASIGNATURA Representa a las asignaturas
ALUMNO Representa a los alumnos
EXAMEN Representa a los exámenes que se realicen de cada asignatura
RUTASSNAIT Tabla auxiliar de datos para almacenar rutas de interés en
el acceso a ficheros del servidor SNAIT
CURSOACADEMICO Representa a cada uno de los cursos académicos de
los cuales hay datos en el sistema.
Y las principales relaciones son:
Relación USUARIO ROL Un usuario puede tener varios roles y un
mismo rol puede estar asignado a varios usuarios (relación N-M)
Relación FICHERO ROL Un fichero puede ser modificado por varios
roles y un mismo rol puede estar autorizado a modificar varios ficheros (relación
N-M)
Relación USUARIO ASIGNATURA Un usuario (profesor) puede tener
asignadas varias asignaturas, y una asignatura puede estar asignada a varios
profesores (relación N-M)
Relación ALUMNO ASIGNATURA Un alumno puede estar
matriculado en varias asignaturas y una asignatura lo normal es que tenga
matriculados varios alumnos (relación N-M)
Relación ALUMNO EXAMEN Un alumno puede realizar varios
exámenes y un examen es realizado, normalmente, por varios alumnos (relación
N-M)
Relación FICHERO SERVIDOR Un fichero pertenece a un servidor,
un servidor puede contener varios ficheros (relación N-1)
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 62 UNIVERSIDAD DE SEVILLA
Relación ASIGNATURA EXAMEN Un examen pertenece a una
asignatura, y una asignatura puede tener varios exámenes (relación 1-N)
Relación EXAMEN CURSO ACADÉMICO Un examen pertenece
a un determinado curso académico, y a un curso académico pueden pertenecer
varios exámenes (relación N-1)
Relación CURSO ACADÉMICO ALUMNO_ASIGNATURA La
relación entre un alumno y una asignatura (matrícula), depende del curso
académico. Un curso académico puede tener muchas matrículas. Por tanto, se
trata de una relación 1-N.
4.2 Lógica de la aplicación
4.2.1 Extensión de Struts
Para facilitar el desarrollo de la aplicación, así como la legibilidad del código, se han
realizado algunas extensiones sobre el comportamiento tradicional de Struts. Estas
extensiones están ubicadas en el paquete edu.extensionStruts de la aplicación.
A grandes rasgos, toda petición que se hace en una aplicación Struts, se realiza a una
determinada URI, normalmente acabada en el prefijo “.do” (esto puede cambiarse en la
configuración del ActionServlet de Struts en el fichero web.xml). En el fichero struts-
config.xml (situado en el directorio WEB-INF de la aplicación), se asocia a cada URI de
ese tipo una clase de tipo Action (que es un servlet), y que será invocada cada vez que
se haga una petición a esa URI. Por defecto, toda petición a una clase Action, invocará
su método execute(); que responde al prototipo siguiente:
public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { // Aqui se hace toda la logica asociada a esta accion
return mapping.findForward(“destino”);
}
Listado 9 Esqueleto del método execute de la clase Action de Struts
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 63 UNIVERSIDAD DE SEVILLA
El método execute recibe cuatro parámetros (rellenados automáticamente por el
ActionServlet), que son:
• ActionMapping Es la clase que permite obtener información sobre las
relaciones entre páginas JSP y las etiquetas con las que se identifican en la
aplicación Struts (todo esto definido en el fichero struts-config.xml).
• ActionForm Es la clase que contiene los datos del formulario asociado a la
petición que se ha hecho. Este formulario es un bean, que debe crearse, que
extienda a la clase ActionForm, y debe asociársele a la URI de petición que se
desee en el fichero struts-config.xml
• HttpServletRequest Es la clase que contiene los datos sobre la petición HTTP.
Permite acceder a datos tales como los parámetros de request o la sesión
• HttpServletRespose Es la clase que contiene los datos sobre la respuesta HTTP
que se va a enviar
En el método execute, haciendo uso de estos parámetros, se lleva a cabo la lógica
deseada, y finalmente debe devolverse un objeto de la clase ActionForward. Este objeto,
como puede verse en el Listado 9, se obtiene a partir del ActionMapping. La cadena
“destino” es un identificador, al que debe habérsele asociado una página JSP en el
fichero struts-config.xml. Puede observarse que el programador tiene la capacidad de
elegir diferentes destinos para la petición en función de los resultados de la lógica, sin
más que devolver un ActionForward a otro destino distinto.
Respecto a esto, se han realizado diversas modificaciones para mayor comodidad:
Se ha creado la clase ContextoWeb (edu.extensionStruts), que simplemente
encapsula los cuatro parámetros con los que se llama al método execute.
Se ha creado una clase ExtensionAction (edu.extensionStruts), que se tomará
como clase base para que hereden de ellas todas las demás. Al invocar cualquier
acción que extienda de ella, será invocado el método execute() de la misma. Tal
método se ha modificado para que lleve a cabo las siguientes funciones:
o Comprobación de la validez de la sesión y de los permisos: Se
comprueba que existen en sesión los datos de login. En caso contrario, se
redirige a la página de login.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 64 UNIVERSIDAD DE SEVILLA
o Se encapsulan los cuatro argumentos del método en un objeto
ContextoWeb.
o Se obtiene el valor de un parámetro del formulario que se llame
‘accion’ y se invoca, por reflexión, al método de la clase que se llame
de esa forma: Esto ha implicado la creación a su vez de una clase
llamada ExtensionActionForm, que extiende a ActionForm, y que
contiene los métodos get y set necesarios para garantizar que todo
formulario tenga un parámetro ‘acción’.
[...]
Class instanciaClaseActual = null; Class claseContextoWeb = null;
// Se obtiene el objeto de esta clase instanciaClaseActual = this.getClass();
// Y se instancia el tipo de los argumentos // que recibe claseContextoWeb = ContextoWeb.class; Class[] parametrosQueRecibeElMetodo = {claseContextoWeb };
// Se aplica reflexividad para obtener el metodo metodoAInvocar = instanciaClaseActual.getMethod(accion, parametrosQueRecibeElMetodo);
[...]
Listado 10: Código de obtención del objeto Method, que permite, por reflexividad, invocar a un
método de la clase actual que se llame de una forma determinada, en concreto, como indique la
variable ‘accion’
[...]
// Se obtiene el método a invocar y se invoca metodoAInvocar =
obtenerMetodoAInvocar(contextoWeb,accion);
Object[] arrayParametrosInvocacion = { contextoWeb };
logger.info("Invocando método '" +metodoAInvocar.getName() + "'");
nombreMappingDestino = (String)
metodoAInvocar.invoke(this,arrayParametrosInvocacion);
destino = mapping.findForward(nombreMappingDestino); [...]
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 65 UNIVERSIDAD DE SEVILLA
Listado 11: Código de cómo se invoca el método obtenido según se mostró en el Listado 10 en el
método execute de la clase ExtensionAction
De la invocación de ese método se espera como retorno una cadena, que
corresponderá con la etiqueta de destino asignada en el struts-config.xml
al JSP al que se desea que se redirija la aplicación.
Como resultado de esto, se tiene que en la aplicación, toda acción extiende a
ExtensionAction. Dentro de estas clases, como puede verse en el Listado 12, se tienen
métodos que reciben como parámetro un objeto de la clase ContextoWeb, y que
devuelven un String, que debe ser ‘forward’ (destino) válido definido en el struts-
config.xml
[...]
public class GestionRutasAction extends ExtensionAction{
/** * Logger */static Logger logger = LogManager.getLogger(GestionRutasAction.class);
/** * Acción de mostrar el formulario de gestión de rutas * * @param contextoWeb * @return * @throws Exception */public String mostrarGestionRutas(ContextoWeb contextoWeb)
throws Exception{
// Logica del metodo mostrarGestionRutas}
/** * Acción de actualizar los datos de las rutas del SNAIT * * @param contextoWeb * @return * @throws Exception */public String actualizarRutas(ContextoWeb contextoWeb)
throws Exception{
// Logica del metodo actualizarRutas}
}
[...]
Listado 12: Ejemplo de una típica clase ExtensionAction
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 66 UNIVERSIDAD DE SEVILLA
Esto permite usar una misma clase ExtensionAction, para procesar diferentes peticiones
que hagan cosas relativamente distintas. Basta con especificar en cada petición el
parámetro ‘accion’, con el nombre del método que se desea que se invoque en cada
caso.
Así, por ejemplo, si se supone que para la clase del Listado 12, la URI que se le ha
asignado en el struts-config.xml es “GestionRutas.do”. Si se desea invocar el método
“mostrarGestionRutas” de la misma, una posibilidad sería la que aparece en el Listado
13.
[...]<script> location.href=”/gsait/GestionRutas.do?accion=mostrarGestionRutas”;</script>[...]
Listado 13: Ejemplo de llamada a un método concreto de la clase ExtensionAction
En este ejemplo, la invocación se hace por Javascript. Lo normal es hacer las
invocaciones desde un formulario. Lo que se hace en estos casos es incorporar al
formulario un campo tipo hidden, de nombre ‘accion’, al que se asigna su valor usando
JavaScript antes de cualquier submit.
4.2.2 Formularios en Struts
Struts incorpora muchas facilidades para el tratamiento de formularios. A toda URI de
llamada a una acción Struts que se realice mediante el submit de un formulario, se le
puede asociar, en el struts-config.xml un objeto que herede de la clase ActionForm (en
el caso del GSAIT, heredará de la clase ExtensionActionForm).
Este objeto no es más que un bean que debe crear el programador, y en el cual debe
incorporar como variables de instancia aquellos campos del formulario que se deseen
procesar en el método invocado de la clase ExtensionAction.
Como ejemplo, supóngase el caso sencillo del formulario de login del GSAIT. Este
formulario se programa en una página JSP como la que se muestra en el Listado 14.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 67 UNIVERSIDAD DE SEVILLA
[...]
<html:form action="/Login.do" method="post">
<%-- Se indica el metodo del Action que efectua la validacion --%><html:hidden property="accion" value="autentificar"/>
<TABLE class="caja" ><TR><TD COLSPAN='2'> <html:errors name="errores" property="Login Incorrecto"/></TD></TR><TR><TD> <bean:message key="login.usuario"/></td><td> <html:text property="usuario" style="width:100px"/></td></TR><TR><td> <bean:message key="login.clave"/></td><td> <html:password property="clave" style="width:100px"/></td></TR><tr> <td colspan="2" style="text-align: center">
<html:submit value="Entrar"/></td></tr></TABLE>
</html:form>
[...]
Listado 14: Composición JSP del formulario de login
Para la creación de formularios, el programador debe apoyarse en las taglibs de la
librería ‘html’ de Struts. Estas etiquetas, tales como html:form, html:hidden,
html:submit, html:text, etc. son análogas a sus equivalentes en HTML. De hecho, el
resultado de su procesamiento es HTML normal. La ventaja es que Struts asocia los
nombres de los campos del formulario, con las variables correspondientes de la clase
ActionForm asociada. Además, ofrece etiquetas que facilitan tareas como la generación
automática de las listas de valores de un campo select a partir de colecciones de objetos
Java presentes en la sesión o el request, entre otras muchas.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 68 UNIVERSIDAD DE SEVILLA
La clase LoginForm, que es la clase de formulario asociada a la acción de Login (y por
tanto al formulario anterior) se muestra en el Listado 15.
[...]
public class LoginForm extends ExtensionActionForm{ private String usuario; private String clave;
/** * @return Devuelve clave. */ public String getClave() { return clave; } /** * @param clave Valor de clave a asignar. */ public void setClave(String clave) { this.clave = clave; } /** * @return Devuelve usuario. */ public String getUsuario() { return usuario; } /** * @param usuario Valor de usuario a asignar. */ public void setUsuario(String usuario) { this.usuario = usuario; }}
[...]
Listado 15: Clase LoginForm, asociada al formulario de Login del GSAIT
Como se ve, la clase tiene dos campos, usuario y clave. Pues bien, al hacer un submit
del formulario de login, Struts buscará, por cada campo del formulario, un método
getNOMBRE_DEL_CAMPO correspondiente, y lo invocará estableciendo los valores
correspondientes.
El resultado es que, una vez en el método de la clase Action, se puede obtener a partir
del ContextoWeb el objeto LoginForm cuyas variables de instancia contienen los
valores que el usuario ha introducido por el formulario. Esto se ve en el Listado 16.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 69 UNIVERSIDAD DE SEVILLA
[...]
public String autentificar(ContextoWeb contextoWeb) throws Exception { [...]
// Se obtienen los datos del formulario loginForm = (LoginForm) contextoWeb.getForm(); usuario = loginForm.getUsuario(); clave = loginForm.getClave();
[...] }
[...]
Listado 16: Obtención de los valores del formulario en la clase Action
Obsérvese cómo en el formulario se establecíó un campo hidden, de nombre acción y
con valor ‘autentificar’. Esto da lugar a que se invoque el método ‘autentifcar’ dentro de
la clase LoginAction.
La obtención de los valores del formulario no es la única facilidad que ofrece Struts.
Más útil es, aún si cabe, la posibilidad de rellenar formularios con valores antes de
mostrarlos. Struts no sólo identifica los campos del formulario con los de la clase
ActionForm asociada al hacer el submit, sino que también lo hace antes de mostrar el
formulario.
Al asociar una clase ActionForm a una Action, en el struts-config.xml, se le da un
nombre a ese ActionForm. Además de eso, se le da un alcance ‘scope’, que puede ser:
request o session. Esto significa que Struts hará disponible el objeto ActionForm a
través de la sesión o del request bajo el nombre que se le haya asignado. Si el alcance es
de request, el objeto se reconstruye cada vez que se hace una petición. Si el alcance es
de sesión, el objeto permanece siempre en la misma con los últimos valores que se le
haya asignado a sus variables.
Para prerellenar un formulario con los valores que se desee, basta con recuperar dicho
objeto de la sesión o del request, según su alcance, e invocar los métodos set
correspondientes con los valores que se deseen asignar. Esto debe hacerse en el método
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 70 UNIVERSIDAD DE SEVILLA
de la clase Action que envíe como destino al JSP del formulario en cuestión. Un
ejemplo de esto se muestra en el Listado 17.
[...]public String mostrarServidor(ContextoWeb contextoWeb)
throws DAOException{
[...]
formulario = (GestionServiciosForm) contextoWeb.getForm();
[...]
// Se rellenan los campos del formulario con los datos del // servidor seleccionadoformulario.setNombreServidor(servidorBean.getNombre());formulario.setUrlServidor(servidorBean.getUrl());formulario.setPuertoSSH(servidorBean.getPuertoSSH());formulario.setUsuarioSSH(servidorBean.getUsuarioSSH());formulario.setClaveSSH(servidorBean.getClaveSSH());
formulario.setComandoReinicio(servidorBean.getComandoReinicio());formulario.setObligatorio(servidorBean.isObligatorio());
contextoWeb.getSesion().setAttribute("GestionServiciosForm",formulario); [...]
}
[...]
Listado 17: Pre-rellenado de los valores de un formulario
El listado muestra que los pasos a dar para pre-rellenar un formulario son:
1.- Obtener el objeto del formulario a través del ContextoWeb
2.- Realizar toda la lógica necesaria para decidir con qué valores se desean rellenar los
campos del formulario.
3.- Invocar los métodos set correspondientes del objeto ActionForm.
4.- Insertar el objeto del formulario en su alcance correspondiente. En el caso del
ejemplo, el objeto tiene un alcance de sesión. El nombre con el que se inserta debe ser el
mismo que se le ha asignado en el struts-config,xml
Este procedimiento es muy útil, por ejemplo, para rellenar formularios con datos
obtenidos de base de datos.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 71 UNIVERSIDAD DE SEVILLA
4.2.3 Paquetes de la Aplicación
En esta sección se irán introduciendo los diferentes paquetes de la aplicación, así como
las clases que contienen y las funcionalidades que éstas albergan. Para mayor detalle, se
remite al lector al JavaDoc de la aplicación. Asimismo, se irán describiendo los
algoritmos más complejos empleados para lograr determinadas funcionalidades.
Todos los paquetes se han agrupado bajo el prefijo ‘edu’. Este prefijo suele ser de uso
estándar para temas relacionados con la educación (otro ejemplo sería el prefijo ‘com’
para aplicaciones comerciales).
4.2.3.1 edu.extensionStruts
En este paquete se han incluido todas aquellas clases implicadas en la extensión del
Framework Struts, así como en la autenticación y autorización de los usuarios.
Clase Descripción
AccionNoEspecificadaException Excepción que se lanza cuando no se especifica el
parámetro ‘accion’ a la hora de llamar a una clase
ExtensionAction
ContextoWeb Clase que encapsula los parámetros con los que el
ActionServlet de Struts invoca al método execute de
la clase Action
DatosLogin Encapsula la información del usuario actualmente
logueado en la aplicación
ExtensionAction Clase que extiende a la clase Action de Struts, y de la
cual extenderán todas las acciones de la aplicación
ExtensionActionForm Clase que extiende a la clase ActionForm de Struts, y
de la cual extenderán todos los objetos asociados a
formularios de la aplicación
GestorUsuariosRolesInterfaz Interfaz para la gestión de los datos relativos a los
usuarios y a los roles
PropiedadesAplicacion Singleton que ofrece las propiedades especificadas en
el fichero properties de la aplicación.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 72 UNIVERSIDAD DE SEVILLA
Clase Descripción
La idea es invocar su método de lectura cada vez que
se ejecuta una Action, de forma que luego las
propiedades estén disponibles de forma estática en
cualquier punto de la aplicación.
UsuarioNoAutorizadoException Excepción que se lanza cuando un usuario intenta
acceder a un recurso (JSP o método de una Action)
para el cual no tiene credenciales.
UsuarioNoExisteException Excepción que se lanza cuando la autentificación del
usuario es incorrecta.
4.2.3.2 edu.extensionStruts.seguridad
Contiene clases especializadas en la autenticación y autorización de los usuarios.
Contiene además el fichero seguridad.properties, en el que se especifican qué roles
tienen acceso a qué páginas JSP y a qué métodos de las diferentes clases Action que
integran la aplicación.
Nombre Descripción
Autenticador Interfaz para la gestión de los datos de autenticación
Autenticador_BD_Impl Implementación de la interfaz Autenticador contra base
de datos mediante ODBC
Autorizador Interfaz que gestiona los permisos para los diferentes
usuarios en función de los diferentes roles.
Autorizador_Properties_Impl Implementación del autorizador basada en un fichero
properties (concretamente en seguridad.properties).
JSPSeguro Extensión de JSPBase que introduce la comprobación de
la sesión y de los permisos antes de mostrar cualquier
página JSP
LoginException Excepción que se lanza cuando se produce algún tipo de
error durante el proceso de Login
Usuario Contiene los datos del usuario que está accediendo a la
aplicación
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 73 UNIVERSIDAD DE SEVILLA
4.2.3.3 edu.extensionStruts.utilidades
Clases que implementan diferentes utilidades
Nombre Descripción
BooleanActualizable Clase que encapsula a un booleano que se puede actualizar (con
el propósito de poder pasarlo como parámetro de entrada – salida)
GestorDataSources Clase que ofrece las conexiones a la base de datos a través del
método estático getConnection(). Las conexiones se realizan a
través de una fuente de datos DataSource, a la que se accede
mediante JNDI. Para que la aplicación funcione, el servidor de
aplicaciones donde esté desplegada debe tener una fuente de
datos que apunte a la base de datos y cuyo nombre sea el que se
especifique en el parámetro nombreJNDIDataSource del fichero
gsait.properties (situado en el directorio WEB-INF de la
aplicación).
Utilidades Contiene métodos estáticos que resuelven diversos problemas
frecuentes en el desarrollo de toda la aplicación (formateado de
datos, recorrido de colecciones, lectura de ficheros, etc.)
4.2.3.4 edu.gsait.action
En este paquete se encuentran todas las clases, herederas de ExtensionAction, que
procesan las peticiones al servidor. Es decir, se encuentra aquí el grueso de la lógica de
la aplicación, el Controlador del patrón MVC
Nombre Descripción
GestionCalificacionesAction Contiene los métodos que gestionan todas las
peticiones relacionadas con la gestión de las
calificaciones.
GestionFicheroAction Contiene los métodos que gestionan todas las
peticiones relacionadas con el proceso de
modificación de un fichero de configuración a
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 74 UNIVERSIDAD DE SEVILLA
Nombre Descripción
través de una interfaz amigable.
GestionGSAITAction Contiene los métodos que gestionan todas las
peticiones relacionadas con los apartados de
Gestión del GSAIT (gestión de roles, gestión de
usuarios y gestión de servicios)
GestionRutasAction Contiene los métodos que gestionan todas las
peticiones relacionadas con el apartado de gestión
de las rutas del SNAIT.
InicioModuloConfiguradoresAction Contiene los métodos que gestionan las peticiones
relacionadas con la entrada en el módulo de
modificación de ficheros de configuración de la
aplicación.
LoginAction Contiene los métodos que gestionan las peticiones
relacionadas con el proceso de autenticación de la
aplicación.
ManejadorExcepcion Clase que hereda de ExceptionHandler, y que
actúa como la acción a ejecutar cuando en algún
punto de la aplicación se lanza una excepción que
no se captura. Se le asigna este cometido en el
fichero struts-config.xml, y su misión es reenviar
el flujo de la aplicación a una página de error.
4.2.3.5 edu.gsait.actionForm
Contiene todas las clases, que heredan de ExtensionActionForm, y que representan los
formularios de la aplicación.
Nombre Descripción
GestionAsignaturasForm Bean asociado al formulario de gestión de asignaturas.
GestionExamenForm Bean asociado al formulario de gestión de exámenes
GestionListadoAlumnosForm Bean asociado al formulario de gestion del listado de
alumnos de las asignaturas
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 75 UNIVERSIDAD DE SEVILLA
Nombre Descripción
GestionRolesForm Bean asociado al formulario de gestion de roles
GestionRutasForm Bean asociado al formulario de gestión de las rutas del
SNAIT
GestionServiciosForm Bean asociado al formulario de gestión de los Servicios
configurables por el GSAIT
GestionUsuariosForm Bean asociado al formulario de gestión de usuarios del
sistema.
LoginForm Bean asociado al formulario de autenticación de la
aplicación
4.2.3.6 edu.gsait.datos.beans
Contiene todos los DTOs de la aplicación, es decir, las clases que se usan para envolver
los datos obtenidos del acceso a la capa de persistencia.
Nombre Descripción
AlumnoBean Bean que contiene los datos de un alumno
AlumnoExamenBean Bean que contiene los datos de la relación entre un alumno y un
examen
AsignaturaBean Bean que contiene los datos de una asignatura
ExamenBean Bean que contiene los datos de un examen
FicheroBean Bean que contiene los datos de un fichero
RolBean Bean que contiene los datos de un rol del sistema
ServidorBean Bean que contiene los datos de un servicio configurable por el
GSAIT
UsuarioBean Bean que contiene los datos de un usuario de la aplicación
4.2.3.7 edu.gsait.datos.dao
Contiene tanto las interfaces de acceso a los datos, como las implementaciones de estas
interfaces basadas en JDBC.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 76 UNIVERSIDAD DE SEVILLA
Nombre Descripción
Alumno_AsignaturaDAO_DB_Impl Clase que gestiona el acceso por JDBC a
datos de la relación entre alumnos y
asignaturas
Alumno_ExamenDAO Interfaz de acceso a los datos de la
relación entre alumnos y exámenes
Alumno_ExamenDAO_DB_Impl Implementación de Alumno_ExamenDAO
basada en JDBC
AlumnoDAO Interfaz de acceso a los datos de los
alumos
AlumnoDAO_DB_Impl Implementación de AlumnoDAO basada
en JDBC
AsignaturaDAO Interfaz de acceso a los datos de las
asignaturas
AsignaturaDAO_DB_Impl Implementación de AsignaturaDAO
basada en JDBC
DAOException Excepción que se lanza cuando se produce
algún error durante el acceso a datos.
ExamenDAO Interfaz de acceso a los datos de los
exámenes.
ExamenDAO_DB_Impl Implementación de ExamenDAO basada
en JDBC
FicheroDAO Interfaz de acceso a los datos de los
exámenes
FicheroDAO_DB_Impl Implementación de FicheroDAO basada
en JDBC
RelacionFicheroRol_DB_Impl Gestiona el acceso a los datos de las
relaciones entre ficheros y roles mediante
JDBC
RelaionUsuarioAsignatura_DAO_DB_Impl Gestiona el acceso a los datos de las
relaciones entre usuarios y asignaturas
mediante JDBC
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 77 UNIVERSIDAD DE SEVILLA
Nombre Descripción
RelacionUsuarioRol_DB_Impl Gestiona el acceso a los datos de las
relaciones entre usuarios y roles mediante
JDBC
RolDAO Interfaz de acceso a los datos de los roles
RolDAO_DB_Impl Implementación de RolDAO basada en
JDBC
ServidorDAO Interfaz de acceso a los datos de los
servicios configurables por GSAIT
ServidorDAO_DB_Impl Implementación de ServidorDAO basada
en JDBC
UsuarioDAO Interfaz de acceso a los datos de un
usuario de la aplicación.
UsuarioDAO_DB_Impl Implementación de UsuarioDAO basada
en JDBC.
4.2.3.8 edu.gsait.formulariosDinamicos
4.2.3.8.1 Objetos implicados
Como ya se ha comentado repetidamente a lo largo de esta Memoria, la principal
utilidad del GSAIT es la posibilidad de generar formularios HTML dinámicamente a
partir de un documento XML descriptor, y permitir modificar ficheros de diferentes
formatos a través de una interfaz unificada.
Pues bien, el grueso de la lógica implicada en la generación del formulario dinámico y
en el procesamiento de la información que se introduce a través de él está contenido en
este paquete.
La implementación se basa en una estructura semejante a un árbol de objetos. Los
objetos fundamentales implicados son:
Formulario Objeto que representa al formulario en sí. Básicamente contiene
una colección de secciones.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 78 UNIVERSIDAD DE SEVILLA
Sección Objeto que representa a una sección del formulario. Básicamente
contiene una colección de campos.
Campo Objeto básico que representa cada uno de los campos del
formulario. Puede ser de dos tipos:
o Simple Se trata de un campo que contiene un único valor o colección de
valores.
o Múltiple Se trata de un conjunto de campos cada uno de los cuales tiene
un array de valores, que vendrá por el valor de otro campo, al que se
denomina campo de dimensión.
4.2.3.8.2 Los campos múltiples
Supóngase el caso de un campo del formulario que sea “Número de canales”.
Supóngase que además se tienen otros dos campos que son:
- Nombre del canal
- Valor del canal
Evidentemente, se necesitarán tantos valores de nombre de canal y de valor de canal
como canales se haya especificado en “Número de canales”. En este ejemplo, el campo
múltiple estaría compuesto de los campos Nombre del canal y Valor del Canal, y el
Número de Canal sería el campo de dimensión. Los campos Nombre del Canal y Valor
del Canal tendrán distintos valores en función del valor del campo Número de Canal.
Los campos múltiples se implementan mediante la inclusión dentro del objeto Campo
de una colección de Campos, así como de un Campo que actúa como campo de
dimensión.
Esto hace la implementación infinitamente recursiva. Esto es, dentro de un campo
múltiple, uno de los campos puede ser a su vez otro campo múltiple, y así
sucesivamente.
En los campos simples que no pertenecen a ningún campo múltiple, el valor o valores
del campo se almacena en una variable de instancia que es una Collection de objetos
tipo Valor.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 79 UNIVERSIDAD DE SEVILLA
En el caso de los campos pertenecientes a campos múltiples el valor o colección de
valores en cada caso depende del valor actual del campo de dimensión: Por ello, estos se
almacenan en una variable de instancia, que es un Map, en el que la clave es el valor del
campo de dimensión y el valor es la Collection con el valor o valores del campo para
ese valor del campo de dimensión.
En el caso de que el campo pertenezca a un campo múltiple que a su vez pertenece a
otro campo múltiple, el proceso es semejante, sólo que las claves del mapa de valores se
forman concatenando los sucesivos valores de los sucesivos campos de dimensión con
la cadena “__X__”, a la que se conoce como secuencia de separación de jerarquía de
campos.
4.2.3.8.3 Descripción del funcionamiento
El funcionamiento del formulario dinámico es el siguiente. En primer lugar, se lee el
contenido del XML descriptor de formulario. De este XML, se obtiene un árbol de
objetos, en el que se tiene el objeto Formulario, con todos los objetos Seccion
correspondientes en su interior. Éstos, a su vez, tienen en su interior los objetos Campo
correspondientes, que a su vez pueden contener campos múltiples hasta un nivel
indefinido de anidamiento.
El objetivo de disponer de este árbol es conservar las relaciones de jerarquía existentes.
Sin embargo, también se requiere tener un acceso secuencial y también aleatorio a cada
uno de ellos. Por ello, a la par que se crea el árbol de objetos, se crea un mapa, en el que
cada clave es el nombre distinguido del campo, y cada valor es el objeto Campo. De
este modo se puede obtener rápidamente cualquier campo a partir de su nombre
distinguido. Para un campo no perteneciente a un campo múltiple, su nombre
distinguido es su propio nombre, mientras que para aquéllos que pertenecen a campos
múltiples, su nombre distinguido se conforma con la secuencia de los nombres de los
campos “padre”, separados por la secuencia de separación de la jerarquía de campos.
Por ejemplo:
Canales__X__NombreDelCanal
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 80 UNIVERSIDAD DE SEVILLA
Tras construir el árbol de objetos del formulario, el siguiente paso es rellenar los
mismos con los valores actuales del fichero de configuración. Estos valores se obtienen
del documento XML derivado de aplicar el procesador de descarga a la versión original
del fichero. A partir de este documento, se leen los valores y se genera un mapa, en el
que cada clave es el nombre distinguido del campo y cada valor una Collection con el
valor o valores del campo (en el caso de campos pertenecientes a campos múltiples, en
lugar de una Collection se tiene un mapa de valores indexado por los valores de los
correspondientes campos de dimensión).
A partir del árbol de objetos y del mapar de valores, el objeto Formulario genera el
código HTML que se muestra al usuario. Todas las modificaciones al formulario se
procesan por diversos métodos del mismo que reciben como parámetro el request de las
peticiones.
Finalmente, al pulsar el botón de Actualizar, el formulario recorre todos sus campos y
genera un documento XML con los nuevos valores de los mismos. A este documento es
al que posteriormente se le aplica el procesador de subida, para obtener la nueva
versión del fichero de configuración en su formato original.
Nombre Descripción
Campo Objeto que representa un campo del formulario.
Formulario Objeto que representa al formulario. Contiene la inmensa mayoría de la
lógica relacionada con la gestión de los formularios dinámicos
Seccion Objeto que representa una sección del formulario.
Valor Objeto que encapsula un valor de un campo del formulario
4.2.3.9 edu.gsait.mensajes
Contiene el fichero de mensajes de la aplicación (mensajesGSAIT.properties). Struts
permite agrupar todos los mensajes de texto en un fichero properties, y acceder a ellos
mediante diversos métodos y etiquetas. Una de las principales ventajas de esto es la
internacionalización, es decir, bastaría con crear un fichero de mensajes alternativo para
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 81 UNIVERSIDAD DE SEVILLA
cambiar el idioma de la aplicación. Esta prestación apenas ha sido empleada en el
presente Proyecto.
4.2.3.10 edu.gsait.ssh
Contiene las clases que ofrecen los métodos que requieren de SSH. Para ello hace uso
de la API JSch.
Nombre Descripción
GestionSSH Clase que ofrece métodos estáticos para la subida de ficheros, descarga
de ficheros y ejecución de comandos mediante SSH.
SSHException Excepción que se lanza cuando se produce algún tipo de error durante
operaciones basadas en SSH
4.2.3.11 edu.gsait.xml
Incluye las clases que gestionan las operaciones relacionadas con el procesado de
ficheros XML. Para ello, se hace uso de la API JAXP de Java.
Nombre Descripción
GestionXML Clase que ofrece métodos estáticos para realizar diversas tareas
relacionadas con el procesamiento y la generación de documentos XML
4.2.3.12 edu.sistema
Este paquete contiene la clase que ofrece los métodos necesarios para la ejecución de
comandos del sistema. La principal utilidad de esto es la ejecución del procesador
‘atox’.
Descripción Nombre
UtilidadesSistema Ofrece métodos estáticos para la ejecución de diversos métodos
relacionados con el sistema operativo donde se ejecuta la aplicación
(por ejemplo, la ejecución de comandos)
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 82 UNIVERSIDAD DE SEVILLA
4.3 Capa de presentación
GSAIT responde a la estructura de toda aplicación Web. Básicamente esta consiste en:
Directorio WEB-INF: Es el directorio donde se ubican los ficheros que
determinan el funcionamiento de la aplicación. De entre ellos cabe destacar:
o struts-config.xml Es el fichero de configuración de Struts. En él se
especifican todas las URIs de acceso a las acciones, se relacionan los JSP
con etiquetas y se asocian objetos ActionForm a los formularios, entre
otras muchas cosas.
o web.xml Descriptor de despliegue de la aplicación. Cabe destacar
que se han añadido líneas para habilitar que todas las peticiones que
acaben en ‘.do’, se redirijan al ActionServlet, esto es, sean gestionadas
por Struts.
o gsait.properties Fichero donde se indica a la aplicación el nombre
JNDI que tiene asociada la fuente de datos que da acceso a la capa de
persistencia. Esta fuente de datos debe estar dada de alta en el contenedor
de aplicaciones.
o Todos los ficheros .tld de las múltiples librerías de etiquetas que se
emplean
o DIRECTORIO lib Contiene todos los JARs (Java Archives) de las
APIs y taglibs que se emplean en la aplicación.
o DIRECTORIO src Contiene los fuentes de la aplicación
o DIRECTORIO classes Contiene los ficheros .class de la aplicación
Directorio include Contiene los siguientes directorios:
o DIRECTORIO imagenes Contiene todos los ficheros gráficos que se
muestran en las páginas JSP
o DIRECTORIO css Contiene todas las hojas de estilo que se muestran
en las páginas JSP
o DIRECTORIO js Contiene todos los ficheros JavaScript que se
emplean en la aplicación.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 83 UNIVERSIDAD DE SEVILLA
Paralelamente a estos directorios está la raíz de la aplicación, esto es, el directorio a
partir del cual se sirven las páginas JSP. A continuación se hace una breve enumeración
de los JSP que componen la aplicación y su función:
Página JSP Descripción
index.jsp Página que se muestra por defecto. Simplemente
redirige hacia la acción Struts inicial, que lleva hasta
el formulario de login
login.jsp Formulario de Login
Directorio /paginas/
errorAplicacion.jsp Página que se muestra cuando se produce una
excepción no capturada en la aplicación.
principal.jsp Página que contiene el menú principal una vez que el
usuario se ha autenticado.
Directorio /paginas/gestionCalificaciones
gestionAsignaturas.jsp Página que muestra el formulario de gestión de
asignaturas.
gestionExamen.jsp Página que muestra el formulario de gestión de datos
de exámenes
gestionListadoAlumnos.jsp Página que muestra el formulario de gestión de listado
de alumnos de una asignatura
gestionRutas.jsp Página que muestra el formulario de gestión de las
rutas del SNAIT
panelAsignatura.jsp Página que muestra el panel de control de una
asignatura.
panelProfesor.jsp Página que muestra el panel de control del profesor.
Directorio /paginas/gestionGSAIT
gestionRoles.jsp Página que muestra el formulario de gestión de roles
del sistema
gestionServicios.jsp Página que muestra el formulario de gestión de los
servicios configurables por el GSAIT
gestionUsuarios.jsp Página que muestra el formulario de gestión de
usuarios de la aplicación
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 84 UNIVERSIDAD DE SEVILLA
visualizarFichero.jsp Página destinada a abrirse como ventana emergente y
que muestra el contenido de alguno de los ficheros
asociados a la configuración (procesador de descarga,
descriptor de formulario o procesador de subida)
Directorio /paginas/moduloConfiguradores
actualizacionRealizada.jsp Página que se muestra una vez que la nueva versión
del fichero de configuración se ha vuelto a subir a
dicho servidor
arbolServidores.jsp Página que muestra el árbol de servicios configurables
por el GSAIT, para que el usuario seleccione qué
fichero de ellos desea modificar.
descargaFinalizada.jsp Página que se muestra tras descargar el fichero de
configuración del servidor remoto
entradaModulo.jsp Página de entrada al módulo de configuración de
Servicios
ficheroProcesadoEnDescarga.jsp Página que se muestra una vez que se le ha aplicado el
procesador de descarga a la versión descargada del
fichero de configuración.
ficheroProcesadoEnSubida.jsp Página que se muestra una vez que se ha aplicado el
procesador de subida al fichero de valores generado
por el formulario dinámico.
ficheroSubido.jsp Página que se muestra una vez se ha subido la nueva
versión del fichero de configuración al servidor
remoto.
formulario.jsp Página donde se muestra el formulario de
configuración del archivo.
formularioProcesado.jsp Página que se muestra cuando se ha obtenido el XML
de valores a partir de los datos introducidos por el
usuario en el formulario.
Directorio /paginas/enProceso/
Éste es un directorio temporal donde se almacenarán los ficheros auxiliares resultantes
de las diferentes transformaciones intermedias que debe aplicar GSAIT
Directorio /paginas/formConfig/
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 85 UNIVERSIDAD DE SEVILLA
En este directorio es donde GSAIT ubica todos los ficheros descriptores de formularios,
al subirlos mediante la página de “Gestión de Servicios”
Directorio /paginas/moduloConfiguradores/procesadoresDescarga
En este directorio es donde GSAIT ubica todos los ficheros procesadores de descarga
(hojas XSLT o bien hojas de transformación de atox), al subirlos mediante la página de
“Gestión de Servicios”.
Directorio /paginas/moduloConfiguradores/procesadoresSubida
En este directorio es donde GSAIT ubica todos los ficheros procesadores de subida
(hojas XSLT), al subirlos mediante la página de “Gestión de Servicios”.
Directorio /paginas/modulos
En este directorio se encuentran los fragmentos de JSP que se usan en sentencias de
“incluye”
cabecera.jsp Cabecera de las páginas
navegador.jsp Navegador de las páginas
pie.jsp Pie de las páginas
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 86 UNIVERSIDAD DE SEVILLA
5 Test del mecanismo de modificación de archivosEl grueso de las pruebas sobre la aplicación se ha centrado en el apartado de
modificación de ficheros, puesto que se trata del más complejo, y el que engloba más
tecnologías distintas funcionando coordinadamente.
Para el resto de apartados de la aplicación, se ha realizado un mecanismo continuo de
pruebas paralelo al proceso de desarrollo, en el que se han ido resolviendo los
problemas de forma escalonada, dando lugar a un conjunto bastante robusto de la
aplicación
Las principales pruebas versaron sobre la modificación de un archivo de configuración
remoto, el gwRDSIH323.cfg perteneciente al Gateway RDSI – H323 del Área de
Ingeniería Telemática.
5.1 Simulación de acceso SSH
En teoría, la aplicación debe ser capaz de descargar el fichero de un servidor remoto,
volver a subirlo y ejecutar comandos remotos, todo ello mediante SSH. Para la
realización de pruebas, se ha procedido a:
Habilitar el demonio de SSH en la máquina local (sshd)
Crear una cuenta de usuario ficticia en local, que simule la cuenta que se
habilitará en el servidor real de la aplicación.
Copiar el fichero gwRDSIH323.cfg al directorio local donde se desee (siempre y
cuando el usuario SSH ficticio creado al efecto tenga permisos de lectura y
escritura en él).
A continuación se ha dado de alta el servicio, introduciendo los datos del servidor local
(URL: localhost, etc), y los datos de la cuenta del usuario creado para las pruebas.
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 87 UNIVERSIDAD DE SEVILLA
5.2 Simulación de ejecución remota de comandos
Para comprobar la correcta ejecución de comandos vía SSH, se ha establecido como
comando de reinicio un simple ‘cat’ del fichero recién modificado a otro fichero de
copia. De este modo, toda modificación del fichero gwRDSIH323.cfg debe producir la
regeneración de dicho fichero de copia.
5.2.1 Generación de las plantillas de conversión
Como ya se ha introducido en apartados anteriores, para la modificación de un fichero
remoto, al GSAIT deben proporcionársele tres plantillas: el procesador de descarga, el
procesador de subida y el descriptor de formulario. El formato de cada una de estas
plantillas se discute en profundidad en el apartado 10.3, “Formularios dinámicos y
procesamiento de ficheros”.
Se muestra en este apartado cómo serían estas plantillas para el fichero de ejemplo
gwRDSIH323.cfg.
5.2.2 Formato original del fichero
El formato original del fichero gwRDSIH323.cfg es de texto plano, y se muestra en el
Listado 18.
# Nombre del GatewayGW_NAME = gwRDSIH323
# Número de canales activos (2 por cada BRI)NUM_CHANNELS = 2
# MSN (Multiple Subscriber Numbers) asociado a cada canal activo# IMPORTANTE: La extension "603" tiene asociado el "MSN = 3"# ("60" es añadido por centralita: "6"-Pasivo largo, "0"-Numero del bus)MSN_0 = 3MSN_1 = 4
# Números adicionales asociados a cada canal activo# ADN_MSN_0 = 3125;3126# ADN_MSN_1 = 3125;3127;3128
# Número de teléfono donde redireccionar las llamadas H.323 entrantesDEFAULT_NUMBER = 38
# Asociación para redireccionar a una determinada IP H323 en funcióndel
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 88 UNIVERSIDAD DE SEVILLA
# número teléfonico desde el que se ha realizado la llamada teléfonicaentrante.## NUMBER2ALIAS = <Numero_teléfono_llamante>-<IP_H323>## Si no se indica ninguno, se envia un tono de 400 Hz al teléfonollamante## Este parámetro es NECESARIO para encaminar la llamada de RDSI->H.323# IMPORTANTE: La extension "603" tiene asociado el "Número = 3"# ("60" es añadido por centralita: "6"-Pasivo largo, "0"-Numero del bus)#NUMBER2ALIAS = 3-193.147.162.162#NUMBER2ALIAS = 4-193.147.162.162NUMBER2ALIAS = 3-127.0.0.1NUMBER2ALIAS = 4-127.0.0.1
# Dirección IP H323 donde redireccionar las llamadas telefónicasentrantes# cuando no se ha hecho uso de la opción "NUMBER2ALIAS".# DEFAULT_TERMINAL = 193.147.162.166
# Puerto para llamadas H.323 entrantes (las salientes siempre usan el1720)LISTEN_PORT = 1721
# Codecs admitidos# Orden de preferencia por defecto: G711_A, G711_U, GSM (MS-GSM), LPCG711_ALAW_CODEC = yG711_ULAW_CODEC = yGSM_CODEC = nLPC_CODEC = n
# Monitorización de los canales RDSIUSE_MONITOR = y
# Fichero donde almacenar la monitorizacion de los canales RDSIMONITOR_FILE = ./registro/monitor.openisdngw
# Nivel de traza de la ejecución del servidor (0-4)TRACE_LEVEL = 0
# Fichero donde almacenar la traza de ejecuciónTRACE_FILE = ./registro/trace.openisdngw
# Tiempo de espera (en segundos) para las llamadas RDSI entrantesTIMEOUT_ANSWER = 30
# Buffer para la corrección del jitter (en milisegundos de retraso)JITTER = 30
# Usar GatekeeperUSE_GATEKEEPER = n
# Dirección IP del Gatekeeeper (usar "*" para broadcast)# GATEKEEPER_ADDR = 193.147.162.166# GATEKEEPER_ADDR = *
# Prefijos enviados al Gatekeeper# PREFIX_x = <prefix>
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 89 UNIVERSIDAD DE SEVILLA
# PREFIX = 9# PREFIX = 6# PREFIX = 0
# Dirección de callback# CALLBACK =
Listado 18: Formato original del fichero gwRDSIH323.cfg
5.2.3 Procesador de Descarga
El procesador de descarga se trata de un documento XML con formato adecuado para
que la aplicación atox sea capaz de convertir el fichero gwRDSIH323.cfg en un
documento XML que entienda el motor del GSAIT. Su contenido se muestra en el
Listado 19.
<?xml version="1.0"?><ax:format xmlns:ax="http://hetland.org/atox"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><fieldValue>
<ax:alt maxOccur="inf"><ax:match name="comentarios"/><field>
<name>GW_NAME</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><field>
<name>NUM_CHANNELS</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><multiField ax:greedy="false">
<name ax:greedy="false">MSN</name>
<dimensionValue><ax:del>_</ax:del><ax:del>\s*=</ax:del></dimensionValue><value>
<ax:del>\s*</ax:del><ax:del>\n</ax:del>
</value></multiField><multiField>
<name>ADN_MSN</name>
<dimensionValue><ax:del>_</ax:del><ax:del>\s*=</ax:del></dimensionValue><value>
<ax:del>\s*</ax:del><ax:del>\n</ax:del>
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 90 UNIVERSIDAD DE SEVILLA
</value></multiField><field>
<name>DEFAULT_NUMBER</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><field>
<name>NUMBER2ALIAS</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value><value minOccur='0' maxOccur="inf">
<ax:del minOccur='0'>NUMBER2ALIAS\s*=\s*</ax:del><ax:del minOccur='0'>\n</ax:del>
</value></field><field>
<name>DEFAULT_TERMINAL</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><field>
<name>LISTEN_PORT</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><field>
<name>G711_ALAW_CODEC<ax:del>\s*=\s*</ax:del></name><value>
<ax:alt><ax:del>n\s*\n</ax:del>y
</ax:alt></value>
</field><field>
<name>G711_ULAW_CODEC<ax:del>\s*=\s*</ax:del></name><value>
<ax:alt><ax:del>n\s*\n</ax:del>y
</ax:alt></value>
</field><field>
<name>GSM_CODEC<ax:del>\s*=\s*</ax:del></name><value>
<ax:alt><ax:del>n\s*\n</ax:del>y
</ax:alt></value>
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 91 UNIVERSIDAD DE SEVILLA
</field><field>
<name>LPC_CODEC<ax:del>\s*=\s*</ax:del></name><value>
<ax:alt><ax:del>n\s*\n</ax:del>y
</ax:alt></value>
</field><field>
<name>USE_MONITOR<ax:del>\s*=\s*</ax:del></name><value>
<ax:alt><ax:del>n\s*\n</ax:del>y
</ax:alt></value>
</field><field>
<name>MONITOR_FILE</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><field>
<name>TRACE_LEVEL</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><field>
<name>TRACE_FILE</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><field>
<name>TIMEOUT_ANSWER</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><field>
<name>JITTER</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><field>
<name>USE_GATEKEEPER<ax:del>\s*=\s*</ax:del></name><value>
<ax:alt><ax:del>n\s*\n</ax:del>y
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 92 UNIVERSIDAD DE SEVILLA
</ax:alt></value>
</field><field>
<name>GATEKEEPER_ADDR</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field><field>
<name>PREFIX</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value><value minOccur='0' maxOccur="inf">
<ax:del minOccur='0'>PREFIX\s*=\s*</ax:del><ax:del minOccur='0'>\n</ax:del>
</value></field><field>
<name>CALLBACK</name><value>
<ax:del>\s*=\s*</ax:del><ax:del>\n</ax:del>
</value></field>
</ax:alt></fieldValue>
<ax:def name="comentarios"><ax:del maxOccur="inf" greedy="true">#.*</ax:del>
</ax:def>
<!-- Transformaciones XSLT --><xsl:template match="fieldValue/multiField/name[.='MSN']">
<name>canalesActivos__X__MSN</name></xsl:template><xsl:template match="fieldValue/multiField/name[.='ADN_MSN']">
<name>canalesActivos__X__ADN-MSN</name></xsl:template>
</ax:format>
Listado 19: Procesador de descarga para el fichero gwRDSIH323.cfg
5.2.4 Procesador de Subida
El procesador de subida debe convertir el XML generado por el formulario de nuevo al
formato original del fichero. Se trata de una hoja XSLT, y para el caso del fichero
gwRDSIH323.cfg, la hoja que se empleó en las pruebas es la siguiente:
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 93 UNIVERSIDAD DE SEVILLA
<xsl:stylesheet version="2.0"xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:output indent="no" method="text" encoding="UTF-8" omit-xml-declaration="yes" />
<xsl:template match="/">
<xsl:text># Generado por GSAIT</xsl:text>
<xsl:apply-templates select="fieldValue/field"/><!-- El numero de canales se puede obtener contando el numero devalores de MSN que se han dado -->NUM_CHANNELS = <xsl:value-of select="count(fieldValue/multiField[name= 'canalesActivos__X__MSN' and value != ''])"/>
<xsl:apply-templates select="fieldValue/multiField"/>
</xsl:template>
<xsl:template match="fieldValue/field">
<!-- Campos simples tipo NOMBRE = VALOR --><xsl:if test="value != ''"><xsl:if test="name='GW_NAME'">GW_NAME = <xsl:value-of select="value"/></xsl:if><xsl:if test="name='DEFAULT_NUMBER'">DEFAULT_NUMBER = <xsl:value-of select="value"/></xsl:if><xsl:if test="name='DEFAULT_TERMINAL'">DEFAULT_TERMINAL = <xsl:value-of select="value"/></xsl:if><xsl:if test="name='LISTEN_PORT'">LISTEN_PORT = <xsl:value-of select="value"/></xsl:if><xsl:if test="name='USE_MONITOR'">USE_MONITOR = <xsl:value-of select="value"/></xsl:if><xsl:if test="name='MONITOR_FILE'">MONITOR_FILE = <xsl:value-of select="value"/></xsl:if><xsl:if test="name='TRACE_LEVEL'">TRACE_LEVEL = <xsl:value-of select="value"/></xsl:if><xsl:if test="name='TRACE_FILE'">TRACE_FILE = <xsl:value-of select="value"/></xsl:if><xsl:if test="name='TIMEOUT_ANSWER'">TIMEOUT_ANSWER = <xsl:value-of select="value"/></xsl:if><xsl:if test="name='JITTER'">JITTER = <xsl:value-of select="value"/></xsl:if><xsl:if test="name='CALLBACK'">CALLBACK = <xsl:value-of select="value"/></xsl:if></xsl:if>
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 94 UNIVERSIDAD DE SEVILLA
<!-- Campos que pueden aparecer multiples veces CAMPO = VALOR1 CAMPO = VALOR2 ... CAMPO = VALORN --><xsl:if test="name='NUMBER2ALIAS'"><xsl:for-each select="value"><xsl:if test=". != ''">NUMBER2ALIAS = <xsl:value-of select="."/></xsl:if></xsl:for-each></xsl:if>
<xsl:if test="name='GATEKEEPER_ADDR'"><xsl:for-each select="value"><xsl:if test=". != ''">GATEKEEPER_ADDR = <xsl:value-of select="."/></xsl:if></xsl:for-each></xsl:if>
<xsl:if test="name='PREFIX'"><xsl:for-each select="value"><xsl:if test=". != ''">PREFIX = <xsl:value-of select="."/></xsl:if></xsl:for-each></xsl:if>
<!-- Campos booleanos --><xsl:if test="name='G711_ALAW_CODEC' and value='on'">G711_ALAW_CODEC = y</xsl:if><xsl:if test="name='G711_ALAW_CODEC' and not(value = 'on')">G711_ALAW_CODEC = n</xsl:if>
<xsl:if test="name='G711_ULAW_CODEC' and value='on'">G711_ULAW_CODEC = y</xsl:if><xsl:if test="name='G711_ULAW_CODEC' and not(value = 'on')">G711_ULAW_CODEC = n</xsl:if>
<xsl:if test="name='GSM_CODEC' and value='on'">GSM_CODEC = y</xsl:if><xsl:if test="name='GSM_CODEC' and not(value = 'on')">GSM_CODEC = n</xsl:if>
<xsl:if test="name='LPC_CODEC' and value='on'">LPC_CODEC = y</xsl:if><xsl:if test="name='LPC_CODEC' and not(value = 'on')">LPC_CODEC = n</xsl:if>
<xsl:if test="name='USE_GATEKEEPER' and value='on'">USE_GATEKEEPER = y
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 95 UNIVERSIDAD DE SEVILLA
</xsl:if><xsl:if test="name='USE_GATEKEEPER' and not(value = 'on')">USE_GATEKEEPER = n</xsl:if>
</xsl:template>
<xsl:template match="fieldValue/multiField"><xsl:if test="name='canalesActivos__X__MSN' and value != ''">MSN_<xsl:value-of select="dimensionValue"/> = <xsl:value-ofselect="value"/></xsl:if>
<xsl:if test="name='canalesActivos__X__ADN-MSN' and value != ''">ADN_MSN_<xsl:value-of select="dimensionValue"/> = <xsl:value-ofselect="value"/></xsl:if>
</xsl:template></xsl:stylesheet>
Listado 20: Procesador de subida del fichero gwRDSIH323.cfg
5.2.5 Descriptor del formulario
El descriptor de formulario describe los campos de los que debe estar compuesto el
formulario que se muestre al usuario para modificar el fichero en cuestión. El empleado
para las pruebas se muestra en el
<?xml version="1.0" encoding="ISO-8859-1"?><formConfig> <section name="config" label="Configuracion general del Gateway del AIT">
<field name="GW_NAME" title="GW_NAME" type="TEXT" label="Nombre del Gateway"/>
<multiField name="canalesActivos"> <dimensionField name="numeroDeCanales"
title="NUM_CHANNELS" label="Numero de canales activos (2 por cada BRI)"/>
<field name="MSN" title="MSN" type="TEXT" label="MSN asociado a cada canal"/>
<field name="ADN-MSN" title="ADN_MSN" type="TEXT" label="Numeros adicionales asociados a cada canal activo"/>
</multiField> <field name="DEFAULT_NUMBER" title="DEFAULT_NUMBER"
type="TEXT" label="Número de telefono donde redireccionar las llamadas H.323 entrantes"/>
<field name="NUMBER2ALIAS" title="NUMBER2ALIAS" type="FSELECT" label="Asociacion para redireccionar a una determinada IP H.3232 en funcion del numero telefonico desde el que se ha realizado la llamada telefonica entrante.Formato: [Numero_Llamante]-[IP-H323]"/>
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 96 UNIVERSIDAD DE SEVILLA
<field name="DEFAULT_TERMINAL" title="DEFAULT_TERMINAL" type="TEXT" label="Direccion IP H323 donde redireccionar las llamadas telefonicas entrantes cuando no se ha hecho uso de la opcion NUMBER2ALIAS"/>
<field name="LISTEN_PORT" title="LISTEN_PORT" type="TEXT" label="Puerto para llamadas H.323 entrantes (las salientes siempre usan el 1720)"/>
<field name="G711_ALAW_CODEC" title="G711_ALAW_CODEC" type="BOOLEAN"/>
<field name="G711_ULAW_CODEC" title="G711_ULAW_CODEC" type="BOOLEAN"/>
<field name="GSM_CODEC" title="GSM_CODEC" type="BOOLEAN"/> <field name="LPC_CODEC" title="LPC_CODEC" type="BOOLEAN"/>
<field name="USE_MONITOR" title="USE_MONITOR" type="BOOLEAN" label="Monitorizacion de los canales RDSI"/>
<field name="MONITOR_FILE" title="MONITOR_FILE" type="TEXT" label="Fichero donde almacenar la monitorizacion de los canales RDSI"/>
<field name="TRACE_LEVEL" title="TRACE_LEVEL" type="TEXT" label="Nivel de traza de la ejecucion del servidor (0- 4)"/>
<field name="TRACE_FILE" title="TRACE_FILE" type="TEXT" label="Fichero donde almacenar la traza de ejecucion"/>
<field name="TIMEOUT_ANSWER" title="TIMEOUT_ANSWER" type="TEXT" label="Tiempo de espera (en segundos) para las llamadas RDSI entrantes."/>
<field name="JITTER" title="JITTER" type="TEXT" label="Buffer para la correccion del jitter (en milisegundos de retraso)"/>
<field name="USE_GATEKEEPER" title="USE_GATEKEEPER" type="BOOLEAN" label="Usar Gatekeeper"/>
<field name="GATEKEEPER_ADDR" title="GATEKEEPER_ADDR" type="TEXT" label="Direccion IP del Gatekeeper"/>
<field name="PREFIX" title="PREFIX" type="FSELECT" label="Prefijos enviados al Gatekeeper"/>
<field name="CALLBACK" title="CALLBACK" type="TEXT" label="Direccion de callback"/> </section></formConfig>
Listado 21: Descriptor de formulario empleado para el gwRDSIH323.cfg
Con estos ficheros se realizó la batería de pruebas con la que se depuró el
funcionamiento del procesamiento de ficheros y la generación dinámica de formularios.
También se depuró el módulo de descarga de ficheros, subida de ficheros y ejecución de
comandos remotos mediante SSH.
GSAIT Planificación
PROYECTO FIN DE CARRERA 98 UNIVERSIDAD DE SEVILLA
6 PlanificaciónEn la última parte del primer bloque de esta Memoria se describió el Plan de Trabajo
seguido, descompuesto en subtareas. En este capítulo pretende hacerse una estimación
del esfuerzo en horas empleado en cada una de esas tareas.
TareaEsfuerzo
(Horas)
Documentación 80
Implantación del entorno de desarrollo 20
Análisis (requisitos y modelo de datos) 40
Módulo de Autorización y Autenticación 20
Módulo de configuración de Ficheros de Servicios
• Generación dinámica de formularios:
• Subida / bajada de ficheros SSH:
• Procesado de ficheros mediante XSLT / atox
• Ejecución de comandos remotos SSH
200
8
36
2
106
Módulo de gestión web de usuarios y roles GSAIT 4
Módulo de gestión web de servicios 8
Módulo de gestión web de profesores y asignaturas 6
Módulo de gestión de listados de alumnos y notas a partir de ficheros
derivados de hojas de cálculo
8
Estética de la aplicación 8
Instalación en producción 4
Batería de pruebas 8
Redacción de la memoria 200
TOTAL 552
Tabla 4: Estimación de esfuerzo del GSAIT
GSAIT Planificación
PROYECTO FIN DE CARRERA 99 UNIVERSIDAD DE SEVILLA
Teniendo en cuenta que la jornada laboral ordinaria es de 8 horas, se tiene que el coste
en tiempo del proyecto ha sido de 69 jornadas laborales, o lo que es equivalente, de 3
meses laborales y medio.
GSAIT Líneas de continuación
PROYECTO FIN DE CARRERA 100 UNIVERSIDAD DE SEVILLA
7 Líneas de continuaciónEn repetidas ocasiones se ha comentado en esta Memoria, la importancia de las
llamadas plantillas de conversión a la hora del procesamiento de los ficheros de
configuración y la generación de formularios dinámicos. La versión actual de GSAIT
requiere que estas plantillas se creen fuera de la aplicación y, una vez creadas, sean
incorporadas a través del formulario de Gestión de Servicios.
Una primera línea de continuación sería la creación de una interfaz gráfica que
permita la generación interactiva y amigable del documento XML descriptor del
formulario. Esto ahorraría al gestor del GSAIT tener que conocer detalladamente la
estructura XML de dicho documento, tal y como se requiere en la actualidad. Esta línea
de continuación es bastante factible y no demasiado compleja, puesto que el XML que
se debe generar tiene una estructura concreta bastante definida.
Asimismo, sería conveniente la creación de una interfaz gráfica de ayuda para la
generación de los procesadores de subida y de descarga. En este caso, la premisa de
generalidad que se desea para todos los ficheros susceptibles de ser configurados, hacen
bastante más compleja esta línea. Se propone, como solución más cercana, la
facilitación al gestor del GSAIT de plantillas para las conversiones de los formatos de
fichero en texto plano y XML más frecuentes.
También se hace pertinente la elaboración de XML Schemas para los documentos
XML de formato definido por el GSAIT (el XML campo-valor y el descriptor de
formulario). Esto permitirá realizar una validación exhaustiva de la sintaxis de estos
documentos, y una detección fina de posibles errores.
Por último, también sería bastante útil la adición de mecanismos de monitorización
del estado de los servicios que el GSAIT gestiona. Mediante sondeo u otra técnica
semejante, el GSAIT debería poder saber el estado de todos los servidores e incluso
notificar la posible caída de alguno de ellos.
GSAIT Conclusiones
PROYECTO FIN DE CARRERA 101 UNIVERSIDAD DE SEVILLA
8 ConclusionesSe ha conseguido diseñar una aplicación Web que ofrece una interfaz única, amigable y
sencilla para la gestión de servicios remotos totalmente genérica. Se ha conseguido
además, ofrecer un servicio para la fácil gestión de los listados de alumnos y de notas de
las asignaturas de cara a los profesores.
Más allá de todo ello, la aplicación ha supuesto un esfuerzo integrador de muchas
tecnologías
La necesidad de presentarlo bajo la forma de aplicación Web ha requerido el
estudio en profundidad de las tecnologías de servidor de Java: JSP, Servlets.
Además de ha hecho uso del Framework Struts, ampliamente empleado, y con el
cual se ha adquirido bastante soltura.
La necesidad de gestionar la autenticación, permisos e información sensible ha
fomentado la profundización en los conceptos de seguridad y encriptación.
(SSL, SSH, algoritmos de encriptación, etc.)
La necesidad de poder trabajar con ficheros de cualquier formato, que ha
redundado en un intenso estudio de XML y XSLT. También se ha requerido la
búsqueda de herramientas para el procesamiento de texto plano, encontrándose
en atox, basada en tecnología python, la solución óptima.
La generación dinámica de formularios, a partir de un fichero descriptor en
XML, y sobre todo, la obligación de abarcar cualquier casuística en el formato
de entrada de los ficheros, ha tenido como consecuencia el desarrollo de
algoritmos recursivos de procesamiento y generación de datos. Un claro ejemplo
de ello es el soporte para campos múltiples, que se explica detalladamente en el
capítulo de Lógica de la Aplicación.
Se han asentado y desarrollado conocimientos sobre la administración de los
servidores de implantación, tanto servidores Web (Apache y Tomcat), como de
base de datos (PostgreSQL).
Se ha tomado conciencia del amplísimo abanico de herramientas en software
libre que hay disponibles. Se ha comprobado que permiten realizar
GSAIT Conclusiones
PROYECTO FIN DE CARRERA 102 UNIVERSIDAD DE SEVILLA
prácticamente cualquier tarea con la misma fiabilidad que muchas soluciones
comerciales, y con la ventaja del coste económica y el respaldo de una
comunidad desarrolladora.
Como conclusión, puede decirse que el GSAIT constituye una muestra de la integración
de prácticamente todas las tecnologías de la información del mundo del software libre
actualmente en auge.
GSAIT Bibliografía
PROYECTO FIN DE CARRERA 103 UNIVERSIDAD DE SEVILLA
9 Bibliografía
9.1 Libros
[1] DESARROLLO WEB CON JSP. Ben Galbraith; Jayson Falkner; Romin Irani
Ed. Anaya Multimedia
[2] MASTERING JAKARTA STRUTS. James Goodwill. Ed Wiley
[3] JAVA Y XSLT. Eric M. Burke; Tábula Digital. Ed. Anaya Multimedia
[4] Java, XML, and the JAXP. Arthur Griffith, Arthur Griffith. Ed. Ed. Wiley
[5] Tomcat. The Definitive Guide. Jason Brittain, Ian F.Darwin. Ed O’Reilly
9.2 Sitios Web
[1] http://www.eclipse.org
[2] http://java.sun.com
[3] http://jakarta.apache.org/tomcat/
[4] http://logging.apache.org/log4j
[5] http://jdbc.postgresql.org/
[6] http://atox.sourceforge.net
[7] http://www.jamesholmes.com/struts/console/
[8] http://www.sysdeo.com/eclipse/tomcatplugin
[9] http://struts.apache.org/
[10] http://www.jcraft.com/jsch/
[11] http://logging.apache.org/log4j/docs/
[12] http://www.freesoft.org/CIE/Topics/139.htm
[13] http://www.first-american.net/SSL.html
[14] http://www.w3schools.com/
[15] http://www.programacion.com
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 105 UNIVERSIDAD DE SEVILLA
10 Anexos
10.1 Gestión del GSAIT
10.1.1 Instalación del servidor
10.1.1.1 Instalación de atox
Para su correcto funcionamiento, GSAIT necesita que esté instalada en la misma
máquina donde corre el servidor la aplicación atox. Se trata de una aplicación que
transforma documentos en texto plano a XML siguiendo las instrucciones de un fichero
XML con una determinada estructura.
La instalación de atox es muy sencilla. Simplemente requiere que el sistema Linux
tenga instaladas las bibliotecas de Python (presentes en la mayor parte de las
distribuciones Linux de la actualidad).
La versión de atox con la que se ha trabajado en el desarrollo del Proyecto es la 0.5. Su
paquete de instalación es el fichero atox-0.5.tar.gz. Para instalarlo, debe copiarse en
algún directorio del sistema y ejecutar:
$ tar –zxf atox-0.5.tar.gz
Esto descomprimirá el archivo a un directorio llamado atox-0.5. Ejecutar entonces:
$ cd atox-0.5
$ python setup.py install
Y si todo va bien, atox debe haber quedado instalado en el sistema. Para comprobarlo,
basta con ejecutar el comando ‘atox’, y ver si efectivamente se ejecuta.
10.1.1.2 Inicialización de la base de datos
La aplicación GSAIT requiere un servidor de base de datos Postgres funcionando. En el
CD del Proyecto se facilitan dos scripts para la base de datos, uno de creación del
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 106 UNIVERSIDAD DE SEVILLA
esquema (create.sql) , y otro para la inserción de los valores iniciales (insert.sql). Desde
alguna herramienta de conexión a postgres, ya sea ‘psql’ o bien alguna herramienta
gráfica, como pgadmin, se deben ejecutar dichos scripts.
10.1.1.3 Despliegue de la aplicación
Para poder desplegar la aplicación GSAIT, es necesario disponer de un contenedor de
servlets y páginas JSP instalado y ejecutándose. En el entorno de producción, éste
servidor es Jakarta Tomcat 5.5.9, con la particularidad de que se accede a él a través de
un servidor Apache 2. El servidor Apache 2 sirve el contenido estático y desvía las
peticiones de contenido dinámico al Tomcat a través del conector mod_jk.
Los pasos a seguir para desplegar la aplicación en un entorno de este tipo son:
1.- Copiar el directorio de la aplicación en algún directorio del servidor. Supóngase que
dicho directorio es el siguiente:/var/www/servidores/gsait/www
2.- El siguiente paso es dar de alta este contexto en Tomcat. Para ello, la opción más
modular es la creación de un fichero de contexto. El fichero de contexto es un
documento xml, que debe cumplir:
o Su nombre debe corresponderse con el nombre que se desea que el contexto
tenga en Tomcat. En este caso, gsait.xml
o Debe ubicarse en el directorio:
%TOMCAT_HOME%/conf/Catalina/localhost/
donde TOMCAT_HOME se refiere al directorio base de Tomcat.
o Su contenido debe ser como sigue:
<Context path="/gsait" reloadable="true"docBase="/var/www/servidores/gsait/www/"workDir="/var/www/servidores/gsait/www/work">
<Resource name="jdbc/gsait" auth="Container"
type="javax.sql.DataSource" driverClassName="org.postgresql.Driver"
url="jdbc:postgresql://localhost:5432/bd_scait-gsait" username="scait-gsait"
password="piscis3" maxActive="20" maxIdle="10"
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 107 UNIVERSIDAD DE SEVILLA
maxWait="-1"/>
</Context>
Listado 22: Descriptor de contexto de Tomcat para GSAIT
En este descriptor se especifican las siguientes características:
La aplicación se sirve bajo el contexto /gsait (como indica el parámetro ‘path’).
El contenido de la aplicación se encuentra en el directorio/var/www/servidores/gsait/www/
(como indica el parámetro ‘docBase’).
Los resultados de compilar las páginas JSP se ubicarán en el subdirectorio work
de la carpeta anterior (como indica el parámetro ‘workDir’).
El resto del contenido se usa para configurar la fuente de datos. Esto se comenta en el
apartado siguiente.
3.- Por último debe indicársele al módulo mod_jk, que desvíe hacia Tomcat todas las
peticiones de la aplicación /gsait/ que acaben en *.jsp o en *.do (es importante no
olvidarse de desviar también las peticiones de acciones Struts). Esto se hace
introduciendo las siguientes líneas en el fichero mod_jk.conf:
[...]
JkMount /gsait/ ajp13JkMount /gsait ajp13JkMount /gsait/*.do ajp13JkMount /gsait/*.jsp ajp13
[...]
Listado 23: Líneas a insertar en mod_jk para activar el desvío a Tomcat de las peticiones dinámicas
relativas al GSAIT
4.- El último paso es reiniciar Tomcat y Apache.
10.1.1.3.1 Configuración de la fuente de datos (DataSource)
Tal y como se expuso en la descripción de la lógica, la aplicación realiza el acceso a
base de datos mediante una fuente de datos (DataSource), que se obtiene mediante
JNDI. En Tomcat, para que esta fuente de datos esté accesible, es necesario definirla
dentro del descriptor de contexto, tal y como se hace en el Listado 22. Los parámetros
de más interés en su configuración son:
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 108 UNIVERSIDAD DE SEVILLA
name Es el nombre con el que se recuperará el objeto mediante la API JNDI.
En este caso, “jdbc/gsait”.
driverClassName Es el nombre cualificado del driver JDBC que se
empleará. En este caso, al usar PostgreSQL, el driver que se emplea es
‘org.postgresql.Driver’
url Es la cadena de conexión a la base de datos. Responde al formato:jdbc:driver://servidor:puerto/nombreBD
En este caso, la base de datos está situada en la misma máquina que Tomcat, de
ahí que este parámetro tome el valor:
‘jdbc:postgresql://localhost:5432/bd_scait-gsait’.
username y password Son el usuario y la clave de la base de datos.
El resto de parámetros controlan cosas como el número mínimo y máximo de
conexiones, etc. Normalmente, no es necesario modificar dichos valores.
10.1.2 Gestión de la traza del servidor
La aplicación hace uso de log4j, una potente herramienta de traza. Usando esta
herramienta, el servidor emite mensajes de depuración que informan en todo momento
de las operaciones realizadas. Asimismo, en caso de producirse errores, el servidor
emite una completa traza de la excepción producida de forma que sea fácil localizar el
problema.
Los mensajes de traza de GSAIT se vuelcan en consola, y pueden ser controlados a
través del fichero ‘catalina.out’, situado en el directorio %TOMCAT_HOME$/logs.
Todo mensaje de traza de la aplicación va convenientemente etiquetado con el nombre
del contexto para facilitar su identificación.
Tanto el formato de estos mensajes como el repositorio donde se vuelcan pueden ser
fácilmente modificados, configurando convenientemente el fichero de funcionamiento
‘log4j.properties’, situado en el directorio /WEB-INF/classes de la aplicación.
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 109 UNIVERSIDAD DE SEVILLA
Los gestores del GSAIT son los usuarios que están autorizados a gestionar las tablas
que gobiernan el funcionamiento del servidor. Para ser gestor del GSAIT, es necesario
que el usuario tenga el rol “ROOT_GSAIT”.
10.1.3 Gestores del GSAIT
Una vez que un usuario con rol de gestor del GSAIT se loguea contra la aplicación,
aparece el menú principal con las opciones correspondientes.
Figura 22: Menú principal con las opciones habilitadas para los usuarios gestores del GSAIT
10.1.3.1 Administración del GSAIT
Esta sección engloba las pantallas que permiten configurar el funcionamiento del
GSAIT como servidor de configuración remota de archivos.
10.1.3.1.1 Gestión de Roles
Desde esta pantalla se permite añadir, modificar y eliminar los diferentes roles que
puede tener un usuario del sistema (para una explicación del concepto de roles y
permisos que lleva a cabo el GSAIT, se remite el lector al apartado 3.1 “Terminología”.
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 110 UNIVERSIDAD DE SEVILLA
Figura 23: Formulario de gestión de roles
El formulario muestra en una lista de selección todos los roles actualmente existentes.
Ver los datos de un rol Para ver los datos de un rol, debe hacerse clic sobre
el nombre de dicho rol. Automáticamente el formulario se cargará con los datos
del mismo.
Modificar los datos de un rol Para modificar los datos de un rol, debe
hacerse clic sobre él. A continuación deben modificarse los datos que se deseen.
Finalmente, pulsar el botón “Actualizar”.
Crear un nuevo rol Para crear un nuevo rol, debe pulsarse el botón “Nuevo”.
Aparecerá un nuevo rol, de nombre “Nuevo Rol” y con todos los datos en
blanco. Debe rellenarse el formulario con los datos correspondientes y pulsar el
botón “Actualizar”.
Eliminar un rol Debe seleccionarse el rol que se desea eliminar y pulsar el
botón “Eliminar”. Se solicitará confirmación previa al borrado.
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 111 UNIVERSIDAD DE SEVILLA
10.1.3.1.2 Gestión de Usuarios
Desde esta pantalla se permite la creación, modificación y eliminación de los usuarios
de la aplicación. Además, se permite asignar a cada usuario el rol o roles que se desea
que tenga.
Figura 24: Formulario de gestión de usuarios del sistema
Los datos que gestiona este formulario son:
Nombre Nombre del usuario del sistema (el login)
Clave Clave del usuario
Confirmar clave Para evitar la inserción de claves erróneas al asignar o
modificar las claves de un usuario
Roles Son los roles que tiene asignado el usuario
Las acciones que pueden realizarse en esta pantalla son:
Ver los datos de un usuario Para ver los datos de un usuario, debe hacerse clic
sobre su nombre en la lista de selección que aparece en la parte superior de la
pantalla. Al hacer esto, se carga automáticamente el formulario con los datos del
usuario en cuestión.
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 112 UNIVERSIDAD DE SEVILLA
Modificar los datos de un usuario Debe seleccionarse el usuario cuyos datos
se deseen modificar. A continuación deben modificarse los datos en el
formulario, y finalmente pulsar “Actualizar”. NOTA: Este proceso aplica a todos
los datos salvo a los roles asignados al usuario, cuya gestión se describe a
continuación.
Modificar los roles asignados a un usuario En primer lugar debe seleccionarse
el usuario cuyos roles se desean gestionar. Como puede verse, en el formulario
hay dos listas de selección:
o Roles asignados al usuario: Los roles que tiene asignados el usuario
actualmente
o Roles disponibles: Son todos los roles que hay en la aplicación.
Para asignar roles a un usuario, deben seleccionarse en la lista de roles
disponibles, y pulsar el botón “<==”. Para retirar roles a un usuario, deben
seleccionarse de la lista de los asignados, y pulsar el botón “==>”. Nótese que
las modificaciones sobre los roles se actualizan inmediatamente (sin necesidad
de pulsar el botón de “Actualizar”).
Creación de un nuevo usuario Para crear un nuevo usuario, debe pulsarse
el botón “Añadir”. Un nuevo usuario con los datos en blanco, y de nombre
“Nuevo Usuario” aparecerá. Deben entonces rellenarse los datos del nuevo
usuario y pulsar entonces “Actualizar”.
10.1.3.1.3 Gestión de Servicios
Para entender la funcionalidad de esta pantalla, es conveniente conocer el concepto de
“Servicio”. A tal fin, se remite al lector al apartado 3.3.3, “Gestión de Servicios” de la
presente Memoria. Del mismo modo, para añadir servicios y ficheros a configurar, es
necesario comprender los procesos y el formato de los archivos implicados. Todo esto
se detalla en el Anexo 10.3, “Formularios dinámicos y procesamiento de ficheros”.
El GSAIT es un gestor totalmente escalable y genérico, que permite gestionar un
número arbitrario de ficheros de configuración de prácticamente cualquier formato (ya
sea texto plano o XML).
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 113 UNIVERSIDAD DE SEVILLA
Figura 25: Parte superior de la pantalla de gestión de los servicios, con los datos sobre los servicios
en sí
Figura 26: Parte inferior de la pantalla de gestión de servicios, con los datos sobre los ficheros de
configuración de cada servicio.
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 114 UNIVERSIDAD DE SEVILLA
En esta pantalla se gestionan tanto los datos de los Servicios gestionados por el GSAIT,
como los datos de acceso a los ficheros de configuración que contienen esos servicios.
Los diferentes servicios aparecen enumerados en una lista de selección en la parte
superior de la pantalla. Al hacer clic sobre uno de ellos, el formulario se rellena con sus
datos. Igualmente, en la lista de selección que aparece bajo el rótulo “Ficheros de
configuración del Servicio”, aparecerán enumerados los diferentes ficheros de
configuración que tenga asociado dicho servicio. Si se hace clic sobre alguno de esos
ficheros, los datos relativos al mismo aparecerán en la zona del formulario dedicada a
ello (parte inferior).
Los datos relativos a los servicios que se configuran en esta pantalla son:
Nombre Es un nombre puramente descriptivo, una etiqueta para identificar
al servicio
URL En realidad es la dirección de la máquina donde se encuentra ubicado el
servicio en cuestión (por ejemplo ‘localhost’).
Puerto SSH Puerto donde está escuchando el demonio SSH que debe estar
corriendo en la máquina que hospeda al servicio.
Usuario SSH Nombre del usuario con el que se accederá por SSH a la máquina
donde se encuentra el servicio
Clave SSH Clave del usuario anterior
Comando de reinicio del servidor Comando que debe ejecutarse para reiniciar
el servicio en cuestión (por ejemplo ‘servicio restart’).
Los datos relativos a los ficheros de configuración que se gestionan mediante esta
pantalla son:
Nombre Nombre puramente identificativo del fichero (etiqueta)
Descripción Descripción sobre el archivo
Ruta Ruta completa del archivo en el servidor donde se hospeda
¿Es XML? Indica si el fichero es de formato XML o bien texto plano
Procesador de descarga Permite subir un nuevo procesador de descarga
asociado al fichero actual o visualizar el asociado actualmente.
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 115 UNIVERSIDAD DE SEVILLA
Descriptor de formulario Permite subir un nuevo descriptor de
formulario asociado al fichero actual o visualizar el asociado actualmente.
Procesador de Subida Permite subir un nuevo procesador de subida
asociado al fichero actual o visualizar el asociado actualmente.
Roles autorizados a gestionar este fichero Los usuarios que pretendan
modificar (mediante la interfaz gráfica de GSAIT) el contenido del fichero
deberán poseer alguno de estos roles.
La función y estructura del procesador de descarga, procesador de subida y del
descriptor de formulario se comenta detalladamente en el anexo 10.3, “Formularios
dinámicos y procesamiento de ficheros”.
La visualización, modificación, creación y eliminación de servicios, así como de
ficheros de configuración dentro de los servicios se realiza de forma análoga a lo
comentado para la pantalla de Gestión de Roles o para la de Gestión de Usuarios.
Asimismo, la asignación de roles autorizados a modificar un archivo se rige por los
mismos criterios de funcionamiento que en el caso de la asignación de roles a usuarios
en la pantalla de Gestión de Usuarios.
10.1.3.2 Administración del Servicio de Calificaciones
10.1.3.2.1 Rutas de los ficheros del SNAIT
Esta pantalla permite configurar rutas de interés para el acceso a determinados ficheros
del SNAIT donde se almacenan los datos relativos a las asignaturas y a las
calificaciones.
Figura 27: Gestión de rutas del SNAIT
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 116 UNIVERSIDAD DE SEVILLA
Los datos que se pueden configurar en este formulario son:
Ruta del Fichero con la lista de las asignaturas SNAIT dispone de un fichero
de configuración, de nombre por defecto ‘lista.cfg’, donde se listan todas las
asignaturas, así como el nombre del fichero de calificaciones y el fichero de
audio de cada una. Pues la ruta absoluta de ese fichero en el servidor SNAIT
debe indicarse en este campo del formulario.
Ruta de los ficheros de calificaciones En este campo del formulario debe
indicarse la ruta del directorio donde el SNAIT contiene los ficheros con las
calificaciones de las diferentes asignaturas.
Para modificar alguno de estos valores, basta con ingresar su nuevo valor en el
campo correspondiente y hacer clic en “Actualizar”.
10.1.3.2.2 Gestión de Asignaturas
Esta pantalla permite añadir, eliminar y actualizar los datos relativos a las asignaturas
que van a ser gestionadas por el GSAIT, y por extensión, por el SNAIT. También
permite asignar los profesores que imparten cada asignatura. Los cambios realizados en
esta pantalla tienen repercusión inmediata en los ficheros de configuración
correspondientes del SNAIT.
Figura 28: Gestión de asignaturas
En la parte superior de la pantalla se muestra una lista con todas las asignaturas
actualmente existentes. Haciendo clic sobre una de ellas, el formulario se rellena con
sus datos.
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 117 UNIVERSIDAD DE SEVILLA
Los datos de las asignaturas que se gestionan por medio de este formulario son:
Código Código identificativo (cifra) de la asignatura. Debe ser único.
Nombre Nombre descriptivo (etiqueta) de la asignatura
Fichero de audio Nombre del fichero de audio situado en el SNAIT con el
nombre de la asignatura
Fichero de calificaciones Nombre del fichero situado en el SNAIT con las
calificaciones de la asignatura.
Curso Curso al que pertenece la asignatura
Tipo Tipo de asignatura (tronca, obligatoria, optativa, etc.)
Profesores Asignados Lista de profesores que tienen asignada esta
asignatura (y que estarán autorizados a insertar listados de alumnos y de
calificaciones)
El mecanismo para añadir, modificar, crear y eliminar asignaturas es el mismo que para
el resto de formularios de gestión. Asímimo, la asignación de profesores se realiza de la
misma forma que la asignación de roles a un usuario, según se vio en la pantalla de
Gestión de Usuarios.
GSAIT Gestión del GSAIT
PROYECTO FIN DE CARRERA 118 UNIVERSIDAD DE SEVILLA
GSAIT Manual de Usuario del GSAIT
PROYECTO FIN DE CARRERA 120 UNIVERSIDAD DE SEVILLA
10.2 Manual de Usuario del GSAIT
10.2.1 Gestión de Acceso
Para acceder a la aplicación es necesario autenticarse. Para ello, se debe introducir el
nombre de usuario y la clave en el formulario dedicado a tal efecto. Si los datos de
autenticación facilitados no son correctos, entonces se devuelve al usuario a la pantalla
de login. Lo mismo sucede si se intenta acceder a alguna página intermedia de la
aplicación sin haber iniciado sesión correctamente.
10.2.2 Administradores de Servicios (Configuradores)
Los administradores de Servicios son aquellos usuarios que tienen autorización para
hacer uso del GSAIT con el objeto de modificar los ficheros de configuración de los
diferentes servicios que éste controla. Para que un usuario pueda actuar como
administrador de Servicios, debe poseer el rol “CONFIGURADOR”.
Una vez que el Administrador de Servicios se loguea contra la aplicación, accede al
menú principal de la misma. En él tendrá, como mínimo, acceso a la sección “Gestión
de Servidores del Área”.
10.2.2.1 Gestión de Servidores del Área
10.2.2.1.1 Configuración de Ficheros
Una vez que se accede a este apartado, la aplicación muestra un árbol con todos los
servicios que el GSAIT gestiona. Dentro de cada servicio se muestran los ficheros de
configuración que le pertenecen.
GSAIT Manual de Usuario del GSAIT
PROYECTO FIN DE CARRERA 121 UNIVERSIDAD DE SEVILLA
Figura 29: Árbol de servicios del GSAIT
El usuario deberá hacer clic sobre aquel fichero que desee modificar. Sólo podrá hacerlo
si posee alguno de los roles autorizados a tal efecto (autorización que asignan los
gestores del GSAIT en la pantalla “Gestión de Servicios”).
Da comienzo entonces el proceso de descarga y procesamiento del fichero, que
concluye mostrando el formulario de configuración.
Figura 30: Formulario de configuración
GSAIT Manual de Usuario del GSAIT
PROYECTO FIN DE CARRERA 122 UNIVERSIDAD DE SEVILLA
Conviene hacer ciertas aclaraciones respecto al manejo de algunos tipos especiales de
campos:
Los campos de tipo Selección Libre, permiten insertar varios valores a través del
cuadro de texto situado a la derecha de la lista de selección. Para añadir un valor,
debe escribirse éste en dicho cuadro y pulsar el botón +. Para eliminar uno o
varios valores, deben seleccionarse en la lista de selección y pulsar el botón –
Figura 31: Campo de selección libre
Los campos múltiples: Si el lector no domina el concepto de campos múltiples
se le remite a la lectura del apartado 4.2.3.8.1 “Objetos implicados”. Haciendo
clic sobre cualquier valor del campo de dimensión, el formulario actualiza
automáticamente los valores de los campos pertenecientes al campo múltiple. Si
se desea añadir un valor al campo de dimensión, debe teclearse éste en el cuadro
de texto ubicado a la derecha de la lista de selección y pulsar el botón “+”. Si se
desea eliminar algún valor del campo de dimensión, debe seleccionarse y a
continuación pulsar el botón “-“. Si el usuario cambia algún valor de los campos
pertenecientes al campo múltiple y posteriormente hace clic sobre otro valor del
campo de dimensión, los cambios quedarán automáticamente guardados.
Figura 32: Campo múltiple
Cuando el usuario haya hecho todos los cambios que considere oportunos, debe pulsar
el botón “Actualizar” de la parte inferior del formulario. GSAIT procesará los cambios,
actualizará el fichero en el servidor correspondiente y lo reiniciará.
GSAIT Manual de Usuario del GSAIT
PROYECTO FIN DE CARRERA 123 UNIVERSIDAD DE SEVILLA
10.2.3 Profesores
Esta sección permite a los profesores gestionar las asignaturas que imparten en lo
relativo a listados de alumnos matriculados e inserción de listado de notas de exámenes.
Para que un usuario sea considera como profesor debe poseer el rol “PROFESOR”.
10.2.3.1 Gestión de Calificaciones
Al acceder a esta sección, la aplicación muestra lo que se conoce como “Panel de
Control del Profesor”. En él, se listan todas las asignaturas que imparte el profesor.
Asimismo se ofrece acceso al servicio de publicación de calificaciones, ofrecido por el
servidor SCAIT.
Figura 33: Panel de Control del Profesor
Si se hace clic sobre alguna de la asignaturas, se accede a lo que se conoce como “Panel
de Control de la Asignatura”. En el panel de Control de la Asignatura, el profesor
puede:
Acceder a la Inserción / Modificación del listado de alumnos matriculados en la
asignatura
Modificar o eliminar alguno de los exámenes cuyos datos ya se hayan
introducidos (aparecen listados).
Crear un nuevo registro de datos de examen.
GSAIT Manual de Usuario del GSAIT
PROYECTO FIN DE CARRERA 124 UNIVERSIDAD DE SEVILLA
10.2.3.1.1 Inserción / Modificación del listado de alumnos
Esta funcionalidad se lleva a cabo a través de un formulario.
Figura 34: Formulario de inserción / modificación del listado de alumnos de la asignatura
Los datos que maneja el formulario son:
Asignatura Nombre de la asignatura (es de solo léctura, aparece por
indicación).
Curso Académico Indica en qué curso académico se asigna el listado de
alumnos en cuestión a la asignatura.
Fichero CSV Campo de tipo FILE, en el que se inserta (usando el botón
“Examinar”), el fichero en formato CSV con el listado de alumnos que se desea
asignar (el formato de dicho fichero se discute más adelante).
En caso de haberse insertado ya un listado para la asignatura en el curso académico
seleccionado, éste se muestra en la parte inferior del formulario. Si se cambia el año
académico, el listado se actualiza automáticamente al del nuevo año académico
seleccionado.
El fichero CSV del listado de alumnos se obtiene a partir de una hoja Excel que debe
cumplir con la siguiente plantilla: debe tratarse de una hoja Excel que conste de dos
columnas, tituladas “DNI” y “NOMBRE”. En la primera de esas columnas se inserta el
DNI (sin puntos) del alumno, y en la segunda de ellas el nombre completo del mismo.
Una vez que se tiene la hoja Excel, se selecciona “Guardar Como”, y se elige como
GSAIT Manual de Usuario del GSAIT
PROYECTO FIN DE CARRERA 125 UNIVERSIDAD DE SEVILLA
formato “CSV, separado por comas”. El fichero resultante es el que debe pasarse a
través del formulario.
10.2.3.1.2 Inserción / Modificación de datos de exámenes
Tanto la creación de nuevos datos como la modificación de datos ya existentes sobre
exámenes se realizan a través del mismo formulario.
Figura 35: Pantalla de gestión de datos de exámenes
Los datos que se manejan en este formulario son:
Asignatura Nombre de la asignatura (sólo lectura)
Curso (Numérico) Curso al que pertenece la asignatura
Curso Académico Curso académico al que pertenece el examen
Fichero CSV de Notas Permite incorporar el fichero CSV con el listado de
calificaciones de los alumnos. El formato se describe más adelante y es
semejante al del CSV del listado de alumnos. NOTA: Sólo se podrán insertar
notas de exámenes si previamente se ha insertado el listado de alumnos para esa
asignatura y ese año académico en concreto.
Tipo de Examen Primer parcial , segundo parcial, final, etc.
Fecha de realización Fecha en la que se hizo el examen
GSAIT Manual de Usuario del GSAIT
PROYECTO FIN DE CARRERA 126 UNIVERSIDAD DE SEVILLA
Revisado Campo booleano que indica si el examen ya se ha revisado o no
Lugar de la revisión
Hora de la revisión
Fecha de la revisión
En caso de que ya se hayan insertado calificaciones para este examen, el listado de
las mismas aparece en la parte inferior de esta página.
El fichero CSV con la lista de notas se obtiene fácilmente a partir de una hoja Excel
que debe cumplir un formato. La hoja debe estar compuesta por las columnas
“DNI”, “Nota numérica” y opcionalmente “Nota Literal”. Las nota numérica debe
usar como separador decimal el punto. Una vez rellena la hoja Excel de esta forma,
se selecciona “Guardar Como” y como formato se elige “CSV, separado por
comas”. El fichero resultante es el que debe pasarse a través del formulario.
Tanto en la gestión de listados de alumnos como en la gestión de exámenes, se
permite Añadir un nuevo curso académico (botón situado a la derecha del
desplegable de cursos académicos). El resultado de invocarla es la adición del curso
consecutivo inmediatamente posterior.
GSAIT Formularios dinámicos y procesamiento de ficheros
PROYECTO FIN DE CARRERA 127 UNIVERSIDAD DE SEVILLA
10.3 Formularios dinámicos y procesamiento de ficheros
GSAIT está preparado para poder ser configurado de manera que permita modificar el
contenido de ficheros de cualquier formato mediante un formulario HTML amigable. El
núcleo de la aplicación, sin embargo, trabaja con un único formato de fichero, un
documento XML con formato campo-valor, cuya estructura se describe más adelante.
Esto hace necesario:
Una conversión del formato original del fichero al formato interno XML campo
– valor. Esta conversión se realizará o bien mediante una hoja XSLT, si el
fichero original está en formato XML, o bien mediante un documento XML en
formato del programa atox, si el fichero original está en texto plano. En
cualquier caso, se requiere una plantilla a la que se denominará procesador de
descarga (puesto que es el procesado que se aplica al fichero recién descargado
de su servidor).
Una conversión del documento en formato interno XML campo – valor de
GSAIT al formato original del fichero. En este caso, la conversión se realizará
siempre mediante una hoja XSLT, puesto que el documento origen es siempre
un documento XML. A esta hoja se le denominará procesador de subida
(puesto que es el procesado que se lleva a cabo previamente a la subida del
fichero al servidor).
Un documento que describa cómo será el formulario que se deberá mostrar al
usuario para que modifique los valores del fichero. A este documento XML,
cuyo formato se describe más adelante, se le denomina descriptor de
formulario.
10.3.1 Formulario dinámico. El descriptor de formulario.
GSAIT ofrece la posiblidad de mostrar formularios divididos en secciones, y
compuestos de campos que pueden ser de varios tipos.
La primera clasificación entre los campos que puede mostrar un formulario del GSAIT
es:
o Campos Simples: Sólo tienen un valor o colección de valores
GSAIT Formularios dinámicos y procesamiento de ficheros
PROYECTO FIN DE CARRERA 128 UNIVERSIDAD DE SEVILLA
o Campos Múltiples: Formados por agrupaciones de campos simples (o también
múltiples) cuyos valores son múltiples y están indexados en función del valor de
un campo llamado campo de dimensión. El concepto de campo múltiple se
explica a fondo en la sección 4.2.3.8.1 “Objetos implicados”.
10.3.1.1 Tipos de Campos Simples
GSAIT permite el uso de los siguientes tipos de campos simples:
Campos de TEXTO (TEXT) Son campos de texto.
Figura 36: Campo de texto
Campos tipo SELECCIÓN SIMPLE (SELECT)Son campos de selección,
con múltiples opciones y de las cuales sólo puede seleccionarse una.
Figura 37: Campo de selección simple
Campos tipo SELECCIÓN MÚLTIPLE (MSELECT) Son campos de
selección con múltiples opciones de las cuales pueden seleccionarse varias
Figura 38: Campo de selección múltiple
Campos tipo SELECCIÓN LIBRE (FSELECT) Son campos de selección en
los que los valores se añaden y se eliminan libremente por el usuario. Todos los
valores incluidos en el campo se procesan
GSAIT Formularios dinámicos y procesamiento de ficheros
PROYECTO FIN DE CARRERA 129 UNIVERSIDAD DE SEVILLA
Figura 39: Campo de selección libre
Campos de tipo BOOLEANO (BOLEAN) Son campos con sólo dos
posibles valores (sí/no).
Figura 40: Campo de tipo booleano
10.3.1.2 El descriptor del formulario
El descriptor del formulario es un documento XML en el que se describen las diferentes
secciones de las que constará el formulario, y los diferentes campos de que constará
cada sección.
Todo descriptor de formulario comienza y termina con el elemento raíz <formConfig>.
<formConfig> Elemento raíz del descriptor de formulario
Dentro de cada elemento formConfig irán las diferentes secciones del formulario, cada
una representada por un elemento <section>.
<section> Elemento que representa a las diferentes secciones del formulario.
Los atributos de este elemento son:
o name Es el nombre de la sección
o description Descripción que se mostrará junto al nombre de la sección
A su vez, dentro de las secciones se tienen los diferentes campos que componen cada
una. Los campos pueden ser de dos tipos, simples (definidos por un elemento <field>,
o múltiples, definidos por un elemento <multifield>).
<field> Elemento que representa a un campo simple. Los atributos de este
elemento son:
o name El nombre del campo (debe ser único en todo el formulario)
GSAIT Formularios dinámicos y procesamiento de ficheros
PROYECTO FIN DE CARRERA 130 UNIVERSIDAD DE SEVILLA
o title El título del campo que se mostrará en el formulario
o type El tipo del campo. Los posibles valores son: TEXT
SELECT
MSELECT
FSELECT
BOOLEAN
o label La descripción del campo
Para los campos de tipo SELECT Y MSELECT, el elemento field admite
elementos internos de tipo <option>.
<option> Elemento que representa cada una de las posibles opciones de un
campo SELECT O MSELECT. Sus atributos (obligatorios) son:
o label Etiqueta que se mostrará en la lista de selección del formulario.
o value Valor que se enviará en la petición de submit del formulario si se
selecciona esa opción
<multiField> Elemento que representa un campo múltiple. Estos campos
requieren un campo de dimensión (que se representa por el elemento
<dimensionField>) y en su interior contendrán elementos <field> o incluso
<multiField> (se permite anidamiento de profundidad arbitraria). Su atributo
es:
o name Nombre del campo múltiple (debe ser único en todo el
formulario)
<dimensionField> Elemento interno a <multiField>, y que define el campo
de dimensión del campo múltiple. Sus atributos son:
o name Nombre del campo de dimensión (debe ser único en todo el
formulario)
o title Título del campo que se mostrará en el formulario.
o label Descripción del campo, que se mostrará en el formulario.
Un ejemplo de descriptor de formulario puede verse en el Listado 21 (página 96).
GSAIT Formularios dinámicos y procesamiento de ficheros
PROYECTO FIN DE CARRERA 131 UNIVERSIDAD DE SEVILLA
10.3.1.3 El XML Campo – Valor
Éste es el formato de documento XML con el que en realidad trabaja GSAIT. A grandes
rasgos, se trata de un documento XML en el que se enumeran todos los campos del
formulario, y para cada uno se listan sus valores actuales.
El formulario de configuración, una vez que el usuario ha hecho las modificaciones
pertinentes, traduce todos sus valores a este formato. También precarga sus valores
iniciales leyendo un documento XML en este formato.
Es evidente, por tanto que:
- El procesador de descarga debe convertir el fichero de configuración original en un
XML Campo-Valor coherente con el descriptor de formulario asociado.
- El procesador de subida debe convertir el XML Campo-Valor generado por el
formulario al formato original del fichero de configuración.
El documento XML campo – valor, tiene como elemento raíz <fieldValue>.
<fieldValue> Elemento raíz del XML campo – valor.
Dentro de este elemento se enumeran todos los campos del formulario y los valores que
tiene cada uno. Los campos que no pertenecen a campos múltiples aparecen como
elementos <field>, y los campos que pertenecen a campos múltiples aparecen como
elementos <multiField>. Como se ha comentado, dentro de <fieldValue> se enumeran
todos los campos del formulario (sin jerarquía entre ellos).
<field> Elemento que representa un campo y su valor. Contiene dos tipos de
elementos internos:
o <name> Contiene el nombre del campo
o <value> Este elemento puede aparecer una o varias veces, en función del
tipo de campo de que se trate (si es de tipo texto aparecerá sólo una vez,
si es de tipo selección múltiple aparecerá tantas veces como valores se
hayan seleccionado)
GSAIT Formularios dinámicos y procesamiento de ficheros
PROYECTO FIN DE CARRERA 132 UNIVERSIDAD DE SEVILLA
<multiField> Elemento que representa un campo perteneciente a un campo
múltiple y su valor. Contiene tres tipos de elementos internos:
o <name> Nombre distinguido del campo (el concepto de nombre
distinguido aplicado a campos pertenecientes a campos múltiples se
explica en detalle en la sección 4.2.3.8.3 “Descripción del
funcionamiento”)
o <dimensionValue> Secuencia de valores de los campos de dimensión
padres para la cual este campo tiene asignado el valor o valores que se
indican en el / los elemento/s <value>
o <value> Elemento que puede aparecer una o varias veces, en función del
tipo de campo. Aparecerá una vez por cada valor del campo.
Se deduce que los campos pertenecientes a campos múltiples se verán representados por
uno o varios elementos <multiField>, pero con un valor distino de <dimensionValue>
en cada caso (uno por cada posible secuencia de valores de los campos de dimensión de
los campos múltiples que lo albergan).
Un ejemplo de fichero XML campo – valor se muestra en el
<fieldValue> <field> <name>DEFAULT_NUMBER</name> <value>38</value> </field>
<field> <name>G711_ALAW_CODEC</name> <value>y</value> </field>
<field> <name>G711_ULAW_CODEC</name> <value>y</value> </field>
<field> <name>GW_NAME</name> <value>gwRDSIH323</value> </field>
<field> <name>JITTER</name> <value>30</value> </field>
GSAIT Formularios dinámicos y procesamiento de ficheros
PROYECTO FIN DE CARRERA 133 UNIVERSIDAD DE SEVILLA
<field> <name>LISTEN_PORT</name> <value>1721</value> </field>
<field> <name>MONITOR_FILE</name> <value>./registro/monitor.openisdngw</value> </field>
<field> <name>NUMBER2ALIAS</name> <value>3-127.0.0.1</value> <value/> </field>
<field> <name>PREFIX</name> <value>prefijo1</value> <value>prefijo2</value> </field>
<field> <name>TIMEOUT_ANSWER</name> <value>30</value> </field>
<field> <name>TRACE_FILE</name> <value>./registro/trace.openisdngw</value> </field>
<field> <name>TRACE_LEVEL</name> <value>0</value> </field>
<field> <name>NUM_CHANNELS</name> <value>2</value> </field>
<multiField> <name>canalesActivos__X__MSN</name> <dimensionValue>0</dimensionValue> <value>3</value> </multiField>
<multiField> <name>canalesActivos__X__MSN</name> <dimensionValue>1</dimensionValue> <value>4</value> </multiField>
</fieldValue>
Listado 24: Ejemplo de fichero XML campo-valor de GSAIT
GSAIT Formularios dinámicos y procesamiento de ficheros
PROYECTO FIN DE CARRERA 134 UNIVERSIDAD DE SEVILLA
10.3.1.4 Los procesadores de descarga y de subida
Teniendo en cuenta que el formulario recibe y genera documentos con el formato XML
campo – valor descrito en el apartado anterior, queda clara la misión que deben cumplir
los procesadores de descarga y de subida.
El procesador de descarga es la hoja XSLT o bien el XML de entrada a la aplicación
atox que dirija la transformación del fichero de configuración en su formato original a
un documento XML campo – valor cuyo formato sea coherente con el descriptor de
formulario que se haya diseñado (es decir, que los nombres, tipos y jerarquía de los
campos coincidan).
Por otra parte, el procesador de subida es una hoja XSLT que dirija la transformación
desde el XML campo – valor obtenido del formulario al formato original del fichero de
configuración.
En el CD del Proyecto se adjunta el manual de la aplicación atox, donde se describe
detalladamente la estructura de sus documentos XML de transformación
GSAIT Formularios dinámicos y procesamiento de ficheros
PROYECTO FIN DE CARRERA 135 UNIVERSIDAD DE SEVILLA
GSAIT Contenido del CD
PROYECTO FIN DE CARRERA 136 UNIVERSIDAD DE SEVILLA
10.4 Contenido del CD
El CD del Proyecto presenta la siguiente estructura:
/
|_ Aplicación
|_ gsait
|_ gsait.war
|_ Memoria
|_ Memoria.pdf
|_ ScriptsBD
|_ create.sql
|_ insert.sql
|_ Manual atox
|_ atox.pdf
A continuación se describe detalladamente el contenido.
10.4.1 Directorio raíz
Contiene el fichero indice.txt, donde se especifica el contenido de los diferentes
directorios del CD en formato de texto.
10.4.2 Directorio Aplicación
Contiene:
Directorio gsait Es la aplicación Web completa, incluyendo las fuentes y
las clases de la misma.
gsait.war Se trata de la aplicación empaquetada en un fichero de despliegue
web.
10.4.3 Memoria
Contiene:
Memoria.pdf Es el documento PDF con la presente Memoria.
GSAIT Contenido del CD
PROYECTO FIN DE CARRERA 137 UNIVERSIDAD DE SEVILLA
10.4.4 ScriptsBD
Contiene
create.sql Script de creación (o sobreescritura) del esquema de base de
datos.
insert.sql Script de inserción de los datos iniciales en la base de datos
10.4.5 Manual atox
Contiene:
atox.pdf Documento PDF que contiene el manual de usuario de la
aplicación ‘atox’.