universidad de sevilla escuela superior de...

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

Í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


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



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



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.



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



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.



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.



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.



• 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.



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



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.



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


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


• 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


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


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


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


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


<% 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


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


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


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


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


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


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



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


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


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


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


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


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


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


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


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


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


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).



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.



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



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.



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



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



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



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



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.



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



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).



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:



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



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.



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


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



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



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)



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



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.



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); [...]



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



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.



[...]

<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.



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.



[...]

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



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.



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.



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



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



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



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.



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



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.



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.



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



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



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)



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.



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



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/



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


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.



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



# 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>



# 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>


</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>



</value></multiField><field>

<name>DEFAULT_NUMBER</name><value>



<name>NUMBER2ALIAS</name><value>


</value><value minOccur='0' maxOccur="inf">

<ax:del minOccur='0'>NUMBER2ALIAS\s*=\s*</ax:del><ax:del minOccur='0'>\n</ax:del>


<name>DEFAULT_TERMINAL</name><value>



<name>LISTEN_PORT</name><value>



<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></value>

</field><field>

<name>GSM_CODEC<ax:del>\s*=\s*</ax:del></name><value>


</ax:alt></value>



</field><field>

<name>LPC_CODEC<ax:del>\s*=\s*</ax:del></name><value>


</ax:alt></value>

</field><field>

<name>USE_MONITOR<ax:del>\s*=\s*</ax:del></name><value>


</ax:alt></value>

</field><field>

<name>MONITOR_FILE</name><value>



<name>TRACE_LEVEL</name><value>



<name>TRACE_FILE</name><value>



<name>TIMEOUT_ANSWER</name><value>



<name>JITTER</name><value>



<name>USE_GATEKEEPER<ax:del>\s*=\s*</ax:del></name><value>


</ax:alt></value>

</field><field>

<name>GATEKEEPER_ADDR</name><value>



<name>PREFIX</name><value>


</value><value minOccur='0' maxOccur="inf">

<ax:del minOccur='0'>PREFIX\s*=\s*</ax:del><ax:del minOccur='0'>\n</ax:del>


<name>CALLBACK</name><value>


</value></field>

</ax:alt></fieldValue>

<ax:def name="comentarios"><ax:del maxOccur="inf" greedy="true">#.*</ax:del>

</ax:def>

<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:

<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"/>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">

<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>

<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>

<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



</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]"/>



<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


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


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


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


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


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


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


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



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"



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:



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.



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”.



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.



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.



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).



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.



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.



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



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.



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 Manual de Usuario del GSAIT


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.



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



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á.



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.



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



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



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


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



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



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)



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).



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)



<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>



<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



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 Contenido del CD


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


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’.

universidad de sevilla escuela superior de...

Documents