UNIVERSIDAD DE SEVILLA ESCUELA SUPERIOR DE INGENIEROS INGENIERÍA DE TELECOMUNICACIÓN DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y AUTOMÁTICA ÁREA DE TELEMÁTICA PROYECTO FIN DE CARRERA GSAIT: Gestor de Servicios del Área de Ingeniería Telemática Autor: Calixto J. Porras Fortes Tutor: D. Francisco Javier Muñoz Calle
137
Embed
UNIVERSIDAD DE SEVILLA ESCUELA SUPERIOR DE …bibing.us.es/proyectos/abreproy/11079/fichero/Memoria%2FMemoria.pdf · universidad de sevilla escuela superior de ingenieros ingenierÍa
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSIDAD DE SEVILLAESCUELA SUPERIOR DE INGENIEROS
INGENIERÍA DETELECOMUNICACIÓN
DEPARTAMENTO DE INGENIERÍA DESISTEMAS Y AUTOMÁTICA
ÁREA DE TELEMÁTICA
PROYECTO FIN DE CARRERA
GSAIT: Gestor de Servicios del Área deIngeniería Telemática
Autor: Calixto J. Porras Fortes
Tutor: D. Francisco Javier Muñoz Calle
GSAIT
GSAIT
Índice de Contenidos
Índice de Contenidos ........................................................................................................ 3
Índice de figuras ............................................................................................................... 7
Índice de tablas ................................................................................................................. 9
Índice de listados de código ........................................................................................... 10
1 Introducción y conceptos básicos ........................................................................... 11
Examinando el código anterior, se observa que la página JSP consiste únicamente en
etiquetas. Se hace uso de etiquetas HTML como <head> y <br>, y también de etiquetas
JSTL como <c:forEach> y <c:out>.
2.3.2 Las librerías JSTL
A menudo se habla de JSTL como una única librería. En realidad, se tratan de cuatro
librerías, que se resumen a continuación:
Core Tag Library – Contiene etiquetas que son esenciales para cualquier
aplicación Web. Ejemlos de estas etiquetas incluyen bucles, evaluación de
expresión y entrada / salida básica.
Formatting / Internationalization Tag Library – Contiene etiquetas que se
usan para formatear datos. Como ejemplo, algunas de ellas se usan para
formatear fechas basándose en las diferentes configuraciones locales.
Database Tag Library – Contiene etiquetas que pueden usarse para acceder a
bases de datos SQL. Estas etiquetas suelen usarse exclusivamente para la
creación de programas prototipo, ya que no es normal acceder a bases de datos
directamente desde las páginas JSP. El acceso a base de datos debe encontrarse
en la lógica de la aplicación, a la que acceden las páginas JSP.
XML Tag Library – Contiene etiquetas que permiten acceder a elementos
XML. Dado el amplio uso de XML en muchas aplicaciones Web, el procesado
XML es una característica muy importante de JSTL.
De todas estas librerías, en el Proyecto se hace uso casi exclusivo de la Core Tag
Library, en particular, de las etiquetas:
• <c:out> : Permite mostrar en la página JSP el contenido de variables Java
almacenadas en los diferentes ámbitos de la aplicación WEB (petición, sesión,
página, etc.)
• <c:if>: Permite establecer una condición en la generación del JSP, basándose en
una expresión EL (que se detallan más adelante)
• <c:forEach>: Permite realizar bucles tanto numéricos, como basados en
colecciones de objetos Java. Es muy útil para la generación de tablas basadas en
listas de objetos Java.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 30 UNIVERSIDAD DE SEVILLA
2.3.3 El lenguaje de Expresión EL
El lenguaje de expresión EL es una de los principales componentes de JSP a partir de la
versión 2.0. EL se usa intensivamente en JSTL. Sea como fuere, es importante recordar
que EL es una característica de JSP y no de JSTL. JSP 2.0 permite usar expresiones EL
dentro de scriptlets, como puede verse en el Listado 4.
<p> El precio con IVA es: ${precio+IVA}</p>
Listado 4: Uso de EL en JSP
Los valores “precio” e “IVA” se añaden y muestran en el momento en que se genera el
HTML. Estas expresiones pueden usarse también dentro de etiquetas JSTL, como se ve
en el Listado 5.
<p> El precio con IVA es: <c:out var="${precio + iva}"/>
</p>
Listado 5: Uso de EL dentro de etiquetas JSTL
2.3.4 Conclusiones
JSTL facilita un entorno de programación más consistente, al permitir que tanto el
HTML como el código procedimental se exprese mediante etiquetas. JSTL y las taglibs
constituyen una corriente cada vez más extendida en la programación de páginas Web.
La combinación de JSTL, etiquetas propias y Struts permite la creación de aplicaciones
JSP muy consistentes y eficientes.
2.4 Java API for XML Processing
2.4.1 Introducción
La API de Java para el procesado de XML (JAXP), permite a las aplicaciones crear,
validar y transformar documentos XML. Estas prestaciones las ofrece de forma
transparente a las implementaciones de parsers y transformadores XML que se utilicen.
Esto es, JAXP ofrece una jerarquía de interfaces que permite construir aplicaciones que
creen, validen y procesen documentos XML, sin preocuparse de las implementaciones
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 31 UNIVERSIDAD DE SEVILLA
concretas. Usando JAXP, el programador garantiza que el código que desarrolla será
válido para cualquier implementación de Parser y Transformer que cumpla las
especificaciones.
Las APIs principales de JAXP están definidas en el paquete javax.xml.parsers. Este
paquete contiene dos clases factoría (independientes del fabricante):
SAXParserFactory y DocumentBuilderFactory, que construyen un SAXParser y un
DocumentBuilder, respectivamente. El DocumentBuilder, a su vez, genera objetos
Document conformes a la estructura DOM.
Las factorías de la API permiten usar una implementación de XML hecha por otro
fabricante sin necesidad de cambiar el código fuente. La implementación a usar depende
del estado de las variables del sistema: javax.xml.parsers.SAXParserFactory y
javax.xml.parsers.DocumentBuilderFactory. Los valores por defecto apuntan a la
implementación de referencia.
Para el desarrollo del proyecto se han empleado las implementaciones por defecto,
puesto que han colmado perfectamente las necesidades del desarrollo.
2.4.2 Paquetes
Las APIs SAX y DOM están definidas por el grupo XML-DEV y por el W3C,
respectivamente. Las librerías que definen esas APIs son:
javax.xml.parsers Las APIs JAXP, que proporcionan una interfaz común
para los parsers SAX y DOM de diferentes fabricantes.
org.w3c.dom Define la clase Document (un DOM), así como clases para todos
los componentes del DOM
org.xml.sax Define las APIs básicas de SAX
javax.xml.transformDefine las APIs XSLT que permiten transformar XML en
otros formatos.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 32 UNIVERSIDAD DE SEVILLA
SAX (Simple API form XML), es el mecanismo dirigido por eventos y de acceso
secuencial que hace un procesado elemento a elemento. La API para este nivel lee y
escribe XML a un repositorio de datos a la Web. Esta API está indicada para
aplicaciones del lado del servidor o aquéllas en las que se desee alto rendimiento.
La API DOM es normalmente más fácil de usar. Proporciona una estructura
relativamente familiar de árbol de objetos. Se puede usar la API DOM para manipular la
jerarquía de los objetos de aplicación que encapsula. La API DOM es ideal para las
aplicaciones interactivas puesto que el modelo de objetos está totalmente en memoria,
pudiendo ser accedido y manipulado por el usuario.
Sin embargo, construír el DOM requiere la lectura completa de la estructura XML y
mantener el árbol de objetos en memoria, lo que se traduce en un mayor consumo de
memoria y CPU. Es por eso que se prefiere la API SAX para aplicaciones de servidor y
filtros de datos que no requieran una representación en memoria de los datos.
Por último, las APIs XSLT definidas en javax.xml.transform permiten escribir datos
XML a un archivo o convertirla a otros formatos.
2.4.3 Las APIs SAX (Simple API for XML)
El funcionamiento básico del procesado SAX se muestra en la Figura 5.
Figura 5: Funcionamiento del Procesado SAX
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 33 UNIVERSIDAD DE SEVILLA
Para comenzar el proceso, una instancia de SAXParserFactory se usa para generar una
instancia del parser.
El parser encapsula un objeto SAXReader. Cuando el método parse() del parser se
invoca, el reader invoca uno de los muchos métodos de retrollamada (callback methods)
implementados en la aplicación. Estos métodos están definidos por las interfaces
ContentHandler, ErrorHandler, DTDHandler y EntityResolver.
Un resumen de las principales APIs SAX se muestra a continuación:
SAXParserFactory Un objeto SAXParserFactory crea una instancia del parser
basándose en la propiedad del sistema javax.xml.parsers.SAXParserFactory
SAXParser La interfaz SAXParser define muchos tipos de métodos parse().
En general, al parser se le pasa una fuente de datos XML y un objeto
DefaultHandler, que procesa el XML e invoca los métodos apropiados en el
objeto handler.
SAXReader El SAXParser encapsula un SAXReader. El SAXReader es el
encargado de comunicarse con los handlers de eventos SAX definidos.
DefaultHandler No aparece en el diagrama. Un DefaultHandler
implementa las interfaces ContentHandler, ErrorHandler, DTDHandler y
EntityResolver con métodos vacíos. Aquéllos que interesen pueden ser
sobrescritos.
ContentHandler Métodos como startDocument, endDocument,
startElement y endElement son invocados cuando se reconoce una etiqueta
XML. Esta interfaz también define los métodos characters y
processingInstruction, que se invocan cuando el parser encuentra el texto en un
elemento XML o una instrucción de proceso en línea respectivamente.
ErrorHandler Los métodos error, fatalError y warning, se invocan en
respuesta a diversos errores de parseado. El manejador de error por defecto lanza
una excepción cuando se producen errores fatales e ignora otros errores (incluso
los de validación). Por eso es conveniente conocer el parser SAX, ya que a veces
es necesario proporcionar un manejador de errores personalizado.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 34 UNIVERSIDAD DE SEVILLA
DTDHandler Define métodos que no se usarán casi con toda seguridad.
Se usa cuando se procesa un DTD para reconocer y actuar ante declaraciones de
una entidad no parseada.
Entity Resolver El método resolveEntity se invoca cuando el parser debe
identificar datos determinados por una URI. En la mayoría de los casos, una URI
es simplemente una URL, que especifica la localización de un documento, pero
en algunos casos el documento puede estar determinado por una URN – un
identificador público, o nombre, que es único en el espacio web. El identificador
público puede indicarse como complemento a la URL. El EntityResolver puede
entonces usar el identificador público en vez de la URL para encontrar el
documento, por ejemplo para acceder a una copia local del mismo si es que
existe.
Una aplicación típica implementará casi todos los métodos de ContentHandler como
mínimo. Para lograr una aplicación robusta, se recomienda implementar también los
métodos de ErrorHandler.
2.4.4 Los paquetes de SAX
El parser SAX se define en los siguientes paquetes:
Paquete Descripción
org.xml.sax Define las interfaces SAX. El nombre “org.xml” es el prefijo de
paquetes que fue establecido por el grupo que definió la API SAX
org.xml.sax.ext Define las extensiones de SAX que se usan al hacer un procesado
SAX más sofisticado, por ejemplo, para procesar DTDs o para ver
la sintaxis detallada de un fichero.
org.xml.sax.helpers Contiene clases auxiliares que facilitan el uso de SAX – por
ejemplo, definiendo un manejador por defecto con métodos vacíos
para todas las interfaces, de modo que sólo habría que sobrescribir
los que interesaran.
javax.xml.parsers Define la clase SAXParserFactory, que construye el SAXParser.
También define las clases de excepción para informar acerca de
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 35 UNIVERSIDAD DE SEVILLA
Paquete Descripción
errores.
Tabla 2: Paquetes de la API SAX
2.4.5 Las APIs DOM (Document Object Model)
La Figura 6 muestra las APIs JAXP en acción.
Figura 6: Las APIs DOM de JAXP en acción
La clase javax.xml.parsers.DocumentBuilderFactory se emplea para obtener una
instancia de DocumentBuilder, que se usa para producir un Document (DOM),
conforme a la especificación DOM. El builder que se obtiene viene determinado por la
propiedad del sistema javax.xml.parsers.DocumentBuilderFactory, que elija la
implementación de builder que produce la factoría (el valor por defecto de la plataforma
puede sobrescribirse a través de la línea de comandos).
También puede usarse el método newDocument() de DocumentBuilder para crear un
Document vacío que implemente la interfaz org.w3c.dom.Document. Alternativamente,
se puede usar uno de los métodos de parseado del builder para crear un Document a
partir de datos XML existentes. El resultado es un árbol DOM como el que se muestra
en la Figura 6.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 36 UNIVERSIDAD DE SEVILLA
2.4.6 Paquetes de la API DOM de JAXP
Paquete Definición
org.w3c.dom Define las interfaces de programación de DOM para
documentos XML y, opcionalmente, HTML, como especifica
el W3C
javax.xml.parsers Define las clases DocumentBuilderFactory y
DocumentBuilder, que devuelven un objeto que implementa la
interfaz Document del W3C. La factoría que se usa para crear
el builder se especifica en la propiedad del sistema
javax.xml.parsers, que puede indicarse en línea de comandos o
bien a través del método newInstance. Este paquete también
define la excepción ParserConfigurationException para
informar acerca de errores.
Tabla 3: Paquetes de la API DOM de JAXP
2.4.7 Las APIs XSLT (XML Stylesheet Translation)
La Figura 7 muestra las APIs XSLT en acción:
Figura 7: Las APIs XSLT de JAXP en acción
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 37 UNIVERSIDAD DE SEVILLA
Se instancia un objeto TransformerFactory, y se usa para crear un Transformer. El
objeto fuente es la entrada al proceso de transformación. Un objeto fuente puede crearse
a partir de un SAX reader, de un DOM o de una flujo de entrada.
De forma análoga, el objeto resultante es el resultado del proceso de transformación.
Ese objeto puede ser un manejador de eventos SAX, un DOM o un flujo de salida.
Cuando se crea el transformer, éste puede crearse a partir un conjunto de instrucciones
de transformación, en cuyo caso éstas son llevadas a cabo. Si se crea sin instrucciones
específicas, entonces el Transformer simplemente copia el origen al resultado.
2.4.8 Los paquetes XSLT
Paquete Descripción
javax.xml.transform Define las clases TransformerFactory y Transformer, que
se emplean para obtener objetos capaces de hacer
transformaciones. Tras crear un objeto transformer, se
invoca el método transform(), al que se le debe facilitar
una entrada (origen) y unaa salida (resultado).
javax.xml.transform.dom Clases para crear objetos entrada (origen) y salida
(resultado) a partir de un DOM.
javax.xml.transform.sax Clases para crear objetos de entrada (origen) y de salida
(resultado) a partir de un manejador de eventos SAX.
Javax.xml.transform.stream Clases para crear objets entrada (origen) y salida
(resultado) a partir de un flujo de entrada / salida
2.5 Log4j
Log4j es un API de fuentes abiertas para traza (logging), desarrollado bajo el proyecto
Jakarta Apache. Proporciona un framework robusto, fiable, totalmente configurable,
fácilmente extensible y fácil de implementar para el trazado de aplicaciones Java con
propósitos de depuración o monitorización.
Log4j permite insertar sentencias de traza en el código y configurarlas externamente.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 38 UNIVERSIDAD DE SEVILLA
2.5.1 Motivaciones para su uso
El trazado (logging), o escritura del estado de un programa en varias fases de su
ejecución a algún repositorio como por ejemplo un fichero, es un método tradicional
usado para depurar y monitorizar aplicaciones. La tendencia natural es usar las
sentencias de impresión de mensajes del lenguaje en cuestión (System.out.println() en el
caso de Java).
Insertar sentencias de traza manualmente es tedioso y ralentiza el trabajo, por no
mencionar la modificación de las mismas a lo largo de aplicaciones de considerable
entidad. Es en estos escenarios cuando es útil, eficiente y fácil de usar la API log4j.
2.5.2 Funcionalidades de log4j
1. Log4j maneja la inserción de sentencias de traza en el código de la aplicación y
su modificación externamente, sin tocar el código de la aplicación. Para ello se
basa en archivos de configuración externos.
2. Log4j categoriza las sentencias de traza de acuerdo con criterios establecidos por
el usuario y asigna diferentes niveles de prioridad a esas sentencias de traza.
Estos niveles de prioridad deciden qué sentencias de traza son lo bastante
importantes como para ser volcadas en el repositorio de traza.
3. Log4j permite a los usuarios elegir entre varios destinos para las sentencias de
traza, tales como la pantalla, un fichero, bases de datos, servidores SMTP,
componentes gráficos, etc.; con la opción de asignar diferentes destinos a
diferentes categorías de las sentencias de traza. Estos destinos pueden cambiarse
en cualquier momento con una simple modificación de los ficheros de
configuración de log4j.
4. Log4j también facilita la creación de formatos personalizados para la salida de
traza y proporciona formatos por defecto.
Log4j funciona basándose en tres componentes principales, cuyas funcionalidades están
accesibles a través de clases del mismo nombre:
Logger Es el componente que acepta las peticiones de log durante
la ejecución de la aplicación. Lo normal es asignar un Logger a cada
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 39 UNIVERSIDAD DE SEVILLA
clase o jerarquía de clases de la aplicación. El Listado 6 muestra un
ejemplo de creación de Logger para una clase del Proyecto.
[…]
public class GestionSSH { /** * Logger */ static Logger logger = LogManager.getLogger(GestionSSH.class);
[…]
Listado 6: Creación de un Logger
Log4j tiene definidos por defecto cuatro niveles de prioridad para las
sentencias de traza, que son: DEBUG, INFO, ERROR, FATAL. Para
solicitar al Logger que muestre una sentencia de traza, se invoca el
método cuyo nombre coincida con el nivel de prioridad que se desea para
la misma, esto es:
[…] // Mensaje de nivel DEBUG logger.debug(“Este mensaje de traza tiene nivel de DEBUG”);
// Mensaje de nivel FATAL logger.fatal(“Este mensaje tiene de nivel fatal”);
[…]
Listado 7: Inserción de sentencias de log de distintos niveles de prioridad
Aprender: Es la clase que representa cada uno de los posibles
repositorios donde se volcarán las sentencias de traza. Los diferentes
tipos de repositorio (consola, fichero, base de datos, etc) vendrán
representados por diferentes implementaciones de la clase Appender. A
cada Aprender se le pueden asignar uno o varios Logger que vuelquen la
información sobre ellos.
Layout Es la clase que representa el formato con el que se
muestran las diferentes sentencias de traza. Puede asignarse un layout
específico para cada Aprender.
Tanto la asignación de Appenders, como la creación de los diferentes Layouts, el
establecimiento de los niveles de prioridad, y en general, todas las tareas de
configuración de log4j pueden realizarse de dos formas: programáticamente (en el
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 40 UNIVERSIDAD DE SEVILLA
código Java) o bien mediante un fichero de configuración. Ésta es la opción que se ha
elegido en el Proyecto. Se configura un fichero, de nombre log4j.properties, que debe
encontrarse en el classpath de la aplicación, y cuyo contenido se muestra en el Listado
8.
# Logger Raíz ----------------------------------# Nivel del logger principal y appender asignadolog4j.rootLogger=DEBUG, A1
# A1 saldra por consolalog4j.appender.A1=org.apache.log4j.ConsoleAppender
# Definici\u00F3n del patr\u00F3n de A1log4j.appender.A1.layout=org.apache.log4j.PatternLayout#log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x -%m%nlog4j.appender.A1.layout.ConversionPattern=[GSAIT] %-5p %c %x - %m%n# -----------------------------------------------
# Logger de la aplicación ------------------------log4j.logger.edu=DEBUGlog4j.logger.edu.gsait.XML=FATAL
Listado 8: Fichero de configuración de log4j para el Proyecto GSAIT
Básicamente, esta configuración gestiona la salida de una traza a través de la consola,
con nivel DEBUG (es decir, se mostrarán todos los mensajes puesto que el nivel de
DEBUG es el de más baja prioridad), y con un determinado formato.
2.6 Seguridad
2.6.1 Secure Socket Layer (SSL)
SSL o Secure Socket Layer provee una “capa” para asegurar los protocolos de Internet
(como http, SMTP, FTP, etc) y prevenir que la información transmitida por ellos sea
falsificada, modificada o interceptada por terceras personas mientras se encuentra en
tránsito por la red.
SSL opera mediante el intercambio de claves entre el cliente y el servidor para poder
descrifrar la información que ha sido codificada por un algoritmo de cifrado simétrico.
Lo que esto significa es que los datos encriptados sólo pueden ser desencriptados por el
poseedor de la clave correcta.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 41 UNIVERSIDAD DE SEVILLA
La información que viaja por SSL puede ser encriptada con diferentes algoritmos
simétricos, típicamente DES, Triple DES, Rijndael o IDEA. El término simétrico en
este caso implica que los datos que han sido desencriptados pueden ser desencriptados
después (a diferencia de hashes como SHA1 o MD5 que son sólo “hacia un lado”).
La longitud de las claves determina la dificultad para poder desencriptar el contenido
cifrado. Las claves comúnmente usadas por los sitios hoy en día son de 40 y 128 bits.
Los fundamentales problemas que SSL intenta resolver son los siguientes:
Seguridad de la Información SSL garantiza que terceros no tengan
acceso a la información mientras viaja por Internet al encriptarla.
Integridad de los datos La información recibida desde un servidor por SSL
puede ser “validada” para comprobar que no ha sido alterada en la trayectoria.
Autenticidad de los datos Mediante los algoritmos de encriptación, es posible
comprobar que los datos realmente han llegado del servidor que el cliente
espera. Esto evita que alguien se haga pasar por un sitio para cometer fraudes.
(evitando ataques como Phishing, Man in the Middle, etc).
Mediante el uso de certificados digitales avalados por autoridades certificadoras SSL
incorpora un eslabón más en la cadena de confianza.
Los certificados digitales son una forma de agregar un tercer "árbitro" a la cadena de
confianza de la comunicación por SSL. Lo que un certificado digital hace es agregar el
"endoso" de un tercero que garantiza la integridad, y existencia de la organización que
envía los datos. Esto significa que una autoridad certificadora avala que la empresa que
es dueña del sitio web, por ejemplo, realmente existe.
La aplicación Web desarrollada debe en algunos momentos transportar en sus peticiones
información sensible. Tal es el caso de la pantalla de login, donde se solicita la
contraseña al usuario, o bien las pantallas de gestión de servidores donde se transmite
información valiosa como claves, datos personales o notas de los alumnos. Es preciso
en esos casos el empleo de un protocolo seguro que haga bastante difícil que dicha
información pueda ser interceptada y / o alterada por terceros. Surge aquí HTTPS.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 42 UNIVERSIDAD DE SEVILLA
HTTPS es la versión segura del protocolo HTTP. HTTPS utiliza un cifrado basado en
SSL para crear un canal cifrado. El tipo de cifrado empleado en el canal se decide
mediante una negociación entre el servidor y el cliente, usándose el cifrado más
sofisticado que ambos puedan entender. De este modo, el canal que se tiene es más
apropiado para el tráfico de información sensible que el ofrecido por el protocolo
HTTP.
2.6.2 Seguridad en la comunicación con servidores remotos. JavaSecure Channel (JSch)
Como se explicó en la introducción de la presente memoria, uno de los pasos en el
proceso de modificación de los archivos de configuración es su descarga al GSAIT y
posterior subida al servidor original. Evidentemente, estas transacciones deben
realizarse de forma segura, de forma que el empleo del protocol SSH se hace
imprescindible.
Java Secure Channel, de JCraft, es una implementación puramente en Java del protocolo
SSH2. JSch permite establecer conexiones con servidores ssh y usar reenvío de puertos,
envío X11, transferencia de archivos… e integrar esta funcionalidad en aplicaciones
Java.
Dada la amplísima gama de funcionalidades que proporciona esta API, y dado el uso
muy concreto que se hace de la misma, se omite una descripción exhaustiva, y se remite
al lector a futuras secciones donde se comenta el uso que de JSch se hace en el presente
Proyecto.
2.6.2.1 Secure Shell (SSH)
Una de las necesidades de la aplicación consiste en la descarga y subida de ficheros a
servidores remotos, así como en la ejecución de comandos de forma remota en los
mismos. Evidentemente, todas estas operaciones deben hacerse de forma segura, lo cual
descarta de raíz el empleo de protocolos como Telnet.
GSAIT Base Teórica
PROYECTO FIN DE CARRERA 43 UNIVERSIDAD DE SEVILLA
La solución adoptada, consistente en el empleo de la API JSch (Java Secure Channel,
comentada en secciones anteriores), introduce el empleo de SSH. SSH (Secure Shell),
es la evolución, en términos de seguridad, del Telnet.
SSH permite ejecutar comandos remotos, así como cargar y descargar archivos de
servidores, pero garantizando la confidencialidad de las comunicaciones, y la
autenticidad de las partes implicadas. Permite diversos algoritmos de autenticación y de
encriptado / desencriptado.
Existen dos versiones de SSH, SSH1 y SSH2. Ambos son protocolos totalmente
diferentes e incompatibles. SSH2 es una nueva versión de SSH escrita desde cero y
optimizada en términos de seguridad y rendimiento. Ésta es la versión que se emplea en
JSch, y es por tanto, la que se emplea en el presente Proyecto.
Para que la aplicación pueda establecer una conexión SSH con los servidores remotos,
éstos deben tener corriendo un demonio de SSH. El programa ‘sshd’, presente en la
mayor parte de las distribuciones de Linux actuales, permite establecer dichas
conexiones y realizar todas las tareas necesarias de forma correcta.
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 44 UNIVERSIDAD DE SEVILLA
3 Funcionalidades del ProyectoEn este apartado se van a describir de forma detallada las diferentes funcionalidades que
ofrece el GSAIT.
Administración del GSAIT Esta sección permitirá a aquellos usuarios
del sistema acreditados como “administradores” del mismo, gestionar los
parámetros y tablas básicas de funcionamiento del servidor. Esto se realizará a
través de las pantallas:
o Gestión de Roles Permite la creación, eliminación y actualización de
los diferentes roles del sistema. Los roles son perfiles, que permiten
identificar a grupos de usuarios de la aplicación con determinados
permisos para realizar determinadas acciones (por ejemplo, gestionar el
GSAIT, gestionar ficheros configurables, etc).
o Administración de Servicios Permite la creación, eliminación y
actualización de servicios configurables por el GSAIT. Dentro de cada
servicio, se permite la creación, eliminación y actualización de los datos
de acceso a los diferentes ficheros de configuración que se desea que el
GSAIT gestione. A cada uno de estos ficheros se les asigna un grupo de
roles que están autorizados a modificarlos (es decir, se dispone de un
control de acceso muy flexible a los mismos).
o Administración de Usuarios Permite la creación, eliminación y
actualización de usuarios del sistema, así como la asignación a cada uno
de ellos de los roles que correspondan.
Administración de Servicios Esta sección permitirá a aquellos usuarios
del sistema acreditados como “configuradores” la modificación, mediante
interfaz gráfica, de los contenidos de los diferentes ficheros de configuración .
Además de disponer de acreditación de “configurador”, el usuario en cuestión
debe pertenecer a alguno de los roles autorizados a modificar el fichero en
cuestión (autorizaciones gestionadas desde la pantalla de Administración de
Servicios).
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 45 UNIVERSIDAD DE SEVILLA
Administración del Servicio de Calificaciones Esta sección permite, a los
usuarios con permisos de “administrador”, gestionar los parámetros de
funcionamiento del servidor SNAIT relativos a la inserción de listados de
alumnos e inserción de calificaciones desde el GSAIT. Esta gestión se realiza
mediante dos pantallas:
o Gestión de Rutas del SNAIT Al actualizar los datos sobre las
asignaturas del SNAIT, así como las listas de notas, el GSAIT debe
actualizar el contenido de los ficheros correspondientes en el SNAIT.
Este apartado permite indicar las rutas de ubicación de dichos ficheros en
el servidor SNAIT.
o Gestión de Asignaturas Este apartado permite añadir, modificar y
eliminar los datos sobre las diferentes asignaturas que se gestionarán
desde el GSAIT. También se permite asignar a cada asignatura los
profesores que la imparten (y que, por lo tanto, tienen permiso para
insertar listados de alumnos y/o exámenes). Los datos modificados aquí
que incumban al servidor SNAIT se sincronizan en los ficheros
correspondientes de dicho servidor en el momento de la modificación.
Profesores Este apartado permite, a los usuarios con permisos de “profesor”,
gestionar los datos relativos a las asignaturas que imparte (y que le son
asignadas por medio de la pantalla “Gestión de Asignaturas”). El profesor puede
insertar y actualizar datos relativos a los listados de alumnos de la asignatura, a
partir de un fichero generado fácilmente a partir de una hoja Excel. Igualmente,
se permite insertar calificaciones de exámenes a partir de ficheros derivados de
hojas Excel. Por último, se ofrece en este apartado acceso al servidor de
publicación de calificaciones (SCAIT), de forma que el profesor pueda decidir
qué exámenes publicar y en qué soporte (web, email, sms).
Todos los cambios realizados en esta sección y que afecten al SNAIT, producen
una sincronización con los ficheros correspondientes de dicho servidor, de forma
que la información albergada por el GSAIT y la albergada en el SNAIT sea
coherente el máximo tiempo posible.
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 46 UNIVERSIDAD DE SEVILLA
Tras esta descripción breve, se procede a continuación a describir detalladamente
cómo el GSAIT ofrece todas estas funcionalidades.
3.1 Terminología
Para entender la funcionalidad de la aplicación conviene hacer una breve discusión
acerca de la forma en que el GSAIT gestiona los permisos de usuario. Esta gestión está
basada en roles, de forma semejante a la gestión de usuarios que presenta, por ejemplo,
Jakarta Tomcat.
Un rol identifica a un grupo de usuarios que tienen permisos para realizar un
determinado conjunto de acciones. Es decir, el proceso para dar sentido a un rol sería el
siguiente:
1.- Crear el rol.
2.- Asignar ese rol como rol autorizado a todas las acciones a las que se desee que tenga
permiso (por ejemplo, asignar el rol a aquellos ficheros de servicios a los que se desee
que pueda configurar).
3.- Asignar ese rol a todos aquellos usuarios del sistema que se desee que esté
autorizado a relizar todas aquellas acciones a las que se autorizó el rol en cuestión en el
apartado 2.
De este modo, un usuario estará autorizado a realizar todas aquellas acciones que les
permita el conjunto de roles que tiene asignado.
Mención aparte merecen los roles del sistema. Por roles del sistema se conoce a un
grupo de roles básicos, con unos permisos perfectamente definidos y que son inherentes
al sistema. Estos roles son:
ROOT_GSAIT Es el rol que permite acceder a la administración del
GSAIT (roles, usuarios, servicios), así como a la administración de los datos
relacionados con el SNAIT (rutas y asignaturas).
CONFIGURADOR Es el rol que da acceso a la modificación de los archivos
de configuración de los diferentes servicios. Nótese que, además de disponer de
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 47 UNIVERSIDAD DE SEVILLA
este rol, para modificar un fichero en concreto es necesario que el usuario
disponga de un rol que se encuentre entre los autorizados para ese fichero (lo
cual se establece en la pantalla de “Gestión de Servicios”).
PROFESOR Es el rol que da acceso a la gestión de las diferentes asignaturas
que tenga asignado el usuario (y que se asignan en la pantalla de “Gestión de
Asignaturas”).
3.2 Gestión del Acceso a la Aplicación
3.2.1 Autenticación
Cuando el usuario accede a la aplicación, aparece la pantalla de login. En ella, el usuario
debe facilitar su nombre corto (o login) y su clave de acceso. Si los datos
proporcionados, por el usuario son correctos, se accede al Menú Principal de la
aplicación. En caso contrario, se vuelve a mostrar la pantalla de login y aparece un
mensaje de error.
Figura 8: Pantalla de login del GSAIT
3.2.2 Menú Principal
Una vez que el usuario ha accedido a la aplicación aparece el menú principal. El menú
principal mostrará sólo aquellos apartados a los que el usuario tenga acceso en función
de aquellos roles del sistema que posea. De cara a poder discutir todos los apartados,
supóngase el caso de un usuario que posee todos los roles de sistema (ROOT_GSAIT,
CONFIGURADOR y PROFESOR), de forma que el menú se presenta completo.
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 48 UNIVERSIDAD DE SEVILLA
Figura 9: Menú principal de GSAIT
Desde este menú se accede a las diferentes secciones de la aplicación.
3.3 Gestión del GSAIT
3.3.1 Gestión de Roles
Esta pantalla permite la inserción, actualización y eliminación de los roles de la
aplicación. Para ello se ofrece un formulario HTML como el que se muestra en la
Figura 10.
Figura 10: Formulario de Gestión de Roles
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 49 UNIVERSIDAD DE SEVILLA
3.3.2 Gestión de Usuarios
En este apartado se permite la inserción, actualización y eliminación de los datos
relativos a los usuarios de la aplicación. Para ello se ofrece un formulario como el que
se aprecia en la Figura 11.
Puede observarse en dicha figura la interfaz intuitiva que se proporciona para la
asignación de roles. En ella el usuario asigna y retira los roles seleccionándolos en unas
listas y pulsando el botón correspondiente.
Figura 11: Formulario de Gestión de Usuarios del GSAIT
3.3.3 Gestión de Servicios
Para comprender esta funcionalidad es conveniente discutir brevemente qué se entiende
por servicio en el GSAIT. El objetivo fundamental del GSAIT, como ya se ha
comentado, es ofrecer una interfaz Web para modificar ficheros de configuración en
texto plano. Dichos ficheros son ficheros de configuración de diferentes programas que
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 50 UNIVERSIDAD DE SEVILLA
se ejecutan como servidores en el Área de Ingeniería Telemática. Pues bien, es a cada
uno de esos programas, a los que se denomina “Servicio”, pudiendo tener por tanto cada
servicio cualquier número de ficheros de configuración asociados. Éste es el caso, por
ejemplo, del servidor de notas SNAIT, que posee entre otros, los ficheros de
configuración snait.ini y lista.cfg. De esta definición se excluyen ciertos ficheros
específicos del SNAIT, que albergan datos sobre calificaciones, y que son gestionados
desde la zona de Gestión de Asignaturas.
La pantalla de gestión de Servicios permite insertar, actualizar y eliminar los datos
relativos a los diferentes servicios sobre cuyos ficheros de configuración el GSAIT
puede actuar. Dicha funcionalidad se ofrece mediante un formulario como el que se
muestra en la Figura 12. En él puede observarse cómo, al seleccionar uno de los
servicios, se actualiza también la lista de ficheros de configuración que éste posee,
permitiendo la inserción, actualización y eliminación de los mismos.
Figura 12: Pantalla de Gestión de Servicios
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 51 UNIVERSIDAD DE SEVILLA
También se permite en esta pantalla la asignación de los roles que están autorizados a
modificar un determinado fichero de configuración, de forma análoga a como se realiza
la asignación de roles a los usuarios del sistema.
3.3.3.1 Procesamiento de los ficheros
GSAIT ofrece un motor que permite habilitar la modificación de ficheros de cualquier
formato, ofreciendo un formulario de configuración amigable y sencillo. Para ello, tal y
como se explicó someramente en la introducción, y tal y como se desarrollará en
profundidad en el capítulo de gestión del servidor, por cada fichero a configurar es
necesario facilitar tres archivos:
Procesador de Descarga: Es el fichero que guía la transformación a aplicar al
fichero de configuración, de forma que como resultado se tenga un documento
XML en formato específico de GSAIT (y que se detallará en su momento). Este
procesador puede ser:
o Un XML de transformación para atox Si el fichero a configurar es
de texto plano, el GSAIT lo transforma usando la herramienta ‘atox’.
Esta herramienta necesita un XML que indique las transformaciones a
efectuar (y cuyo formato será detallado en el apartado de Gestión del
Servidor).
o Una hoja XSLT Si el fichero a configurar es de por sí un
documento XML.
Descriptor de formulario Es necesario describir qué campos y de qué tipo
constará el formulario amigable que se mostrará al usuario. Para ello será
necesario facilitar un documento XML, cuya estructura se discute en el apartado
de Gestión.
Procesador de Subida Tras la intervención del usuario, el formulario
genera un XML en el mismo formato del que se obtuvo tras la aplicación del
procesador de descarga. Es necesario convertir este XML al formato propietario
original del fichero de configuración. Para ello se debe proporcionar una hoja
XSLT que realice esta transformación.
Pues bien, la pantalla de gestión de Servicios, más concretamente en la zona de gestión
de Ficheros, ofrece la posibilidad de asociar a cada fichero sus procesadores. Por cada
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 52 UNIVERSIDAD DE SEVILLA
uno de ellos (procesador de descarga, descriptor de formulario y procesador de subida),
se permite Subir una nueva versión, o bien visualizar la asignada actualmente.
3.4 Administración Específica del Servicio de Calificaciones
3.4.1 Rutas Ficheros SNAIT
En esta pantalla se permite especificar las rutas absolutas en el servidor SNAIT de:
El fichero que contiene la lista con las asignaturas, el nombre del fichero de
audio de cada una, y el nombre del fichero de calificaciones de cada una.
El directorio donde se ubican los ficheros de calificaciones de las asignaturas.
Para ello se ofrece un sencillo formulario, como se muestra en la Figura 13.
Figura 13: Gestión de Rutas del SNAIT
3.4.2 Gestión de Asignaturas
Esta pantalla permite la inserción, actualización y eliminación de los datos relativos a
las diferentes asignaturas que gestiona el SNAIT, y por extensión el GSAIT. Esto se
permite mediante el formulario que se muestra en la Figura 14.
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 53 UNIVERSIDAD DE SEVILLA
Figura 14: Gestión de Asignaturas
Como puede observarse, la asignación de los profesores a cada asignatura se realiza
mediante una interfaz muy parecida a la que se usa para la asignación de roles a los
usuarios.
Las modificaciones realizadas en esta pantalla que deban tener repercusión en alguno de
los ficheros del SNAIT, dan lugar a la inmediata actualización de los mismos, vía SSH,
y al reinicio del servidor. De este modo, se intenta mantener la máxima coherencia
posible entre los datos existentes en el GSAIT y los existentes en el SNAIT.
3.5 Gestión de Servicios
3.5.1 Configuración del funcionamiento de los servicios
Ésta es la sección que ofrece la funcionalidad fundamental para la cual el GSAIT fue
diseñado, esto es, la modificación, mediante una interfaz amigable de ficheros de
configuración de diferentes servicios.
Al acceder a esta sección, la aplicación muestra el árbol de los servicios que gestiona el
GSAIT. En dicho árbol, que se muestra en la Figura 15, el usuario selecciona el fichero
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 54 UNIVERSIDAD DE SEVILLA
que desea modificar. Para ello, el usuario debe disponer de los roles adecuados, pues en
caso contrario dicho fichero aparecería inhabilitado.
Figura 15: Captura del árbol de servicios del GSAIT
Una vez que el usuario selecciona el fichero que se desea configurar, la aplicación
descarga dicho fichero y le aplica los procesamientos oportunos, de forma que
finalmente muestra el formulario de configuración de dicho fichero (Figura 16).
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 55 UNIVERSIDAD DE SEVILLA
Figura 16: Formulario de Configuración de un archivo gestionado por GSAIT
El usuario puede modificar los valores que desee, hasta finalmente Actualizar. La
aplicación procesará los nuevos valores y generará la nueva versión del fichero de
configuración, que se sube al servidor. Finalmente, dicho servidor es reiniciado para que
los cambios tengan efecto.
3.6 Gestión de Calificaciones
Una vez que se accede a esta sección, el profesor dispone de acceso a todas aquellas
asignaturas que imparte. Asimismo, se ofrece acceso al servicio de Publicación de Notas
(mediante un enlace al servidor SCAIT). Todo esto se ofrece en un menú como el que
se muestra en la Figura 17.
Tras seleccionar la asignatura que se desea gestionar, aparece una nueva pantalla, el
llamado Panel de Control de la Asignatura. Desde dicha pantalla, que se muestra en la
Figura 18, el usuario tiene acceso a las siguientes funcionalidades:
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 56 UNIVERSIDAD DE SEVILLA
Figura 17: Panel de Control del Profesor
Figura 18: Panel de control de una asignatura
Inserción / Modificación del listado de alumnos de la asignatura Al
seleccionarlo, se accede a un formulario donde se permite al profesor insertar el
listado de alumnos de la asignatura. Se debe asignar dicho listado a alguno de
los años académicos, y debe facilitarse en formato CSV. Este formato se obtiene
fácilmente a partir de una hoja Excel. La hoja Excel con el listado debe estar
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 57 UNIVERSIDAD DE SEVILLA
compuesta exclusivamente por dos columnas, la primera de ellas con cabecera
DNI, y la segunda con cabecera NOMBRE. Al seleccionar Guardar Como, se
elige Formato CSV. El fichero así obtenido es el que debe facilitarse a través del
campo destinado a tal efecto en el formulario.
Si ya existe un listado de alumnos para esa asignatura y año académico, éste se
muestra en esta misma página. Si ya existe un listado, y se inserta otro nuevo,
éste sobrescribirá totalmente al anterior.
Figura 19: Gestión del Listado de Alumnos de una Asignatura
Al seleccionar un año académico distinto, los datos del listado se actualizan
consecuentemente.
Modificación / eliminación de los datos de exámenes ya introducidos El
panel de control de la asignatura ofrece un listado con los exámenes ya
introducidos. El usuario puede modificar los datos de alguno de ellos o
eliminarlo.
GSAIT Funcionalidades del Proyecto
PROYECTO FIN DE CARRERA 58 UNIVERSIDAD DE SEVILLA
Inserción de un nuevo examen
Tanto la modificación de un examen ya introducido como la inserción de uno nuevo dan
paso al formulario de gestión de exámenes, que se muestra en la .
Figura 20: Pantalla de gestión de datos de examen
Este formulario permite modificar todos los datos relativos al examen. Permite
asimismo, subir el fichero CSV derivado de la hoja Excel con las notas del examen. La
hoja Excel de origen debe contener las columnas DNI, Nota numérica y, opcionalmente,
Nota Literal. Todos estos formatos serán descritos detalladamente en el apartado de
Gestión del Servidor.
Toda actualización de los datos de notas de un examen, da lugar a una actualización del
fichero de configuración correspondiente en el SNAIT, de forma que la información de
dicho servidor permanezca lo más coherente posible con la del GSAIT.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 59 UNIVERSIDAD DE SEVILLA
4 Descripción detallada de la aplicaciónEn este apartado se va a llevar a cabo una descripción bastante detallada de cómo se han
implementado las funcionalidades que se han mencionado en capítulo anterior. El
GSAIT se trata de una aplicación de tres capas, y en ellas se desglosará la descripción
del presente apartado:
Capa de persistencia
Lógica de la aplicación
Capa de presentación
4.1 Capa de Persistencia
4.1.1 El patrón DAO / DTO.
La aplicación se ha diseñado intentando independizar lo máximo posible la lógica de la
misma del tipo concreto de capa de persistencia de datos sobre la que se base. Para
conseguir esto, se ha hecho uso del patrón DAO / DTO que, básicamente, consiste en
manejar la persistencia de datos usando dos tipos de objetos:
DTO (Data Transfer Objects): Son simples beans de Java que representarán a las
entidades de la capa de persistencia (por ejemplo, las tablas, en el caso de las
bases de datos relacionales).
DAO (Data Access Objects): Son los objetos Java que se encargan de acceder a
la capa de persistencia, obtener los datos y rellenar con ellos los DTOs.
Los DAOs se diseñan como interfaces que ofrecen los métodos de acceso a los datos.
Por cada tipo de capa de datos que se tenga, se empleará una implementación u otra de
estos DAOs. Al usar las interfaces DAO en el código, se consigue una aplicación en la
que puede cambiarse fácilmente la capa de persistencia sin cambiar la lógica, sino
únicamente la implementación concreta de dichas interfaces.
Para la elaboración de este Proyecto se ha escogido como capa de persistencia una base
de datos relacional. De ahí que, como se verá más adelante, además de las interfaces
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 60 UNIVERSIDAD DE SEVILLA
DAO de acceso a los diferentes objetos, se hayan desarrollado las implementaciones de
las mismas que emplean JDBC para la obtención de los datos.
4.1.2 Base de datos relacional.
El Proyecto se ha desarrollado sobre una base de datos relacional PostgreSQL. Esta
base de datos tiene la peculiaridad de que está compartida con el Servidor de
Calificaciones del Área de Ingeniería Telemática (SCAIT). El motivo es que el GSAIT
lee la información sobre los alumnos, asignaturas y notas de exámenes; y esta
información la necesita el SCAIT para llevar a cabo sus servicios de publicación.
4.1.3 Modelo de datos
Sin entrar en detalles concretos sobre los campos de cada tabla, el modelo de datos de la
aplicación puede verse en la Figura 21.
Figura 21: Modelo de datos del GSAIT
Relacion usuario rol Relacion fichero rolUSUARIO ROL* * FICHERO* *
SERVIDOR
*1
ASIGNATURA
**
Relacion_usuario_asignatura
ALUMNO* *
alumno_asignatura
EXAMEN*
1
*
*
alumno_examen
RUTASSNAIT
CURSOACADEMICO* 1
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 61 UNIVERSIDAD DE SEVILLA
Las diferentes entidades que participan en el modelo son:
USUARIO Representa a los diferentes usuarios del sistema: tanto
administradores, como configuradores, como profesores.
ROL Representa los diferentes roles que pueden tener los usuarios del sistema
FICHERO Representa cada uno de los ficheros de configuración que se
pueden gestionar mediante el GSAIT
SERVIDOR Representa cada uno de los “servicios” que contiene ficheros de
configuración que se pueden gestionar mediante el GSAIT
ASIGNATURA Representa a las asignaturas
ALUMNO Representa a los alumnos
EXAMEN Representa a los exámenes que se realicen de cada asignatura
RUTASSNAIT Tabla auxiliar de datos para almacenar rutas de interés en
el acceso a ficheros del servidor SNAIT
CURSOACADEMICO Representa a cada uno de los cursos académicos de
los cuales hay datos en el sistema.
Y las principales relaciones son:
Relación USUARIO ROL Un usuario puede tener varios roles y un
mismo rol puede estar asignado a varios usuarios (relación N-M)
Relación FICHERO ROL Un fichero puede ser modificado por varios
roles y un mismo rol puede estar autorizado a modificar varios ficheros (relación
N-M)
Relación USUARIO ASIGNATURA Un usuario (profesor) puede tener
asignadas varias asignaturas, y una asignatura puede estar asignada a varios
profesores (relación N-M)
Relación ALUMNO ASIGNATURA Un alumno puede estar
matriculado en varias asignaturas y una asignatura lo normal es que tenga
matriculados varios alumnos (relación N-M)
Relación ALUMNO EXAMEN Un alumno puede realizar varios
exámenes y un examen es realizado, normalmente, por varios alumnos (relación
N-M)
Relación FICHERO SERVIDOR Un fichero pertenece a un servidor,
un servidor puede contener varios ficheros (relación N-1)
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 62 UNIVERSIDAD DE SEVILLA
Relación ASIGNATURA EXAMEN Un examen pertenece a una
asignatura, y una asignatura puede tener varios exámenes (relación 1-N)
Relación EXAMEN CURSO ACADÉMICO Un examen pertenece
a un determinado curso académico, y a un curso académico pueden pertenecer
varios exámenes (relación N-1)
Relación CURSO ACADÉMICO ALUMNO_ASIGNATURA La
relación entre un alumno y una asignatura (matrícula), depende del curso
académico. Un curso académico puede tener muchas matrículas. Por tanto, se
trata de una relación 1-N.
4.2 Lógica de la aplicación
4.2.1 Extensión de Struts
Para facilitar el desarrollo de la aplicación, así como la legibilidad del código, se han
realizado algunas extensiones sobre el comportamiento tradicional de Struts. Estas
extensiones están ubicadas en el paquete edu.extensionStruts de la aplicación.
A grandes rasgos, toda petición que se hace en una aplicación Struts, se realiza a una
determinada URI, normalmente acabada en el prefijo “.do” (esto puede cambiarse en la
configuración del ActionServlet de Struts en el fichero web.xml). En el fichero struts-
config.xml (situado en el directorio WEB-INF de la aplicación), se asocia a cada URI de
ese tipo una clase de tipo Action (que es un servlet), y que será invocada cada vez que
se haga una petición a esa URI. Por defecto, toda petición a una clase Action, invocará
su método execute(); que responde al prototipo siguiente:
public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { // Aqui se hace toda la logica asociada a esta accion
return mapping.findForward(“destino”);
}
Listado 9 Esqueleto del método execute de la clase Action de Struts
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 63 UNIVERSIDAD DE SEVILLA
El método execute recibe cuatro parámetros (rellenados automáticamente por el
ActionServlet), que son:
• ActionMapping Es la clase que permite obtener información sobre las
relaciones entre páginas JSP y las etiquetas con las que se identifican en la
aplicación Struts (todo esto definido en el fichero struts-config.xml).
• ActionForm Es la clase que contiene los datos del formulario asociado a la
petición que se ha hecho. Este formulario es un bean, que debe crearse, que
extienda a la clase ActionForm, y debe asociársele a la URI de petición que se
desee en el fichero struts-config.xml
• HttpServletRequest Es la clase que contiene los datos sobre la petición HTTP.
Permite acceder a datos tales como los parámetros de request o la sesión
• HttpServletRespose Es la clase que contiene los datos sobre la respuesta HTTP
que se va a enviar
En el método execute, haciendo uso de estos parámetros, se lleva a cabo la lógica
deseada, y finalmente debe devolverse un objeto de la clase ActionForward. Este objeto,
como puede verse en el Listado 9, se obtiene a partir del ActionMapping. La cadena
“destino” es un identificador, al que debe habérsele asociado una página JSP en el
fichero struts-config.xml. Puede observarse que el programador tiene la capacidad de
elegir diferentes destinos para la petición en función de los resultados de la lógica, sin
más que devolver un ActionForward a otro destino distinto.
Respecto a esto, se han realizado diversas modificaciones para mayor comodidad:
Se ha creado la clase ContextoWeb (edu.extensionStruts), que simplemente
encapsula los cuatro parámetros con los que se llama al método execute.
Se ha creado una clase ExtensionAction (edu.extensionStruts), que se tomará
como clase base para que hereden de ellas todas las demás. Al invocar cualquier
acción que extienda de ella, será invocado el método execute() de la misma. Tal
método se ha modificado para que lleve a cabo las siguientes funciones:
o Comprobación de la validez de la sesión y de los permisos: Se
comprueba que existen en sesión los datos de login. En caso contrario, se
redirige a la página de login.
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 64 UNIVERSIDAD DE SEVILLA
o Se encapsulan los cuatro argumentos del método en un objeto
ContextoWeb.
o Se obtiene el valor de un parámetro del formulario que se llame
‘accion’ y se invoca, por reflexión, al método de la clase que se llame
de esa forma: Esto ha implicado la creación a su vez de una clase
llamada ExtensionActionForm, que extiende a ActionForm, y que
contiene los métodos get y set necesarios para garantizar que todo
formulario tenga un parámetro ‘acción’.
[...]
Class instanciaClaseActual = null; Class claseContextoWeb = null;
// Se obtiene el objeto de esta clase instanciaClaseActual = this.getClass();
// Y se instancia el tipo de los argumentos // que recibe claseContextoWeb = ContextoWeb.class; Class[] parametrosQueRecibeElMetodo = {claseContextoWeb };
// Se aplica reflexividad para obtener el metodo metodoAInvocar = instanciaClaseActual.getMethod(accion, parametrosQueRecibeElMetodo);
[...]
Listado 10: Código de obtención del objeto Method, que permite, por reflexividad, invocar a un
método de la clase actual que se llame de una forma determinada, en concreto, como indique la
variable ‘accion’
[...]
// Se obtiene el método a invocar y se invoca metodoAInvocar =
/** * Acción de mostrar el formulario de gestión de rutas * * @param contextoWeb * @return * @throws Exception */public String mostrarGestionRutas(ContextoWeb contextoWeb)
throws Exception{
// Logica del metodo mostrarGestionRutas}
/** * Acción de actualizar los datos de las rutas del SNAIT * * @param contextoWeb * @return * @throws Exception */public String actualizarRutas(ContextoWeb contextoWeb)
throws Exception{
// Logica del metodo actualizarRutas}
}
[...]
Listado 12: Ejemplo de una típica clase ExtensionAction
GSAIT Descripción detallada de la aplicación
PROYECTO FIN DE CARRERA 66 UNIVERSIDAD DE SEVILLA
Esto permite usar una misma clase ExtensionAction, para procesar diferentes peticiones
que hagan cosas relativamente distintas. Basta con especificar en cada petición el
parámetro ‘accion’, con el nombre del método que se desea que se invoque en cada
caso.
Así, por ejemplo, si se supone que para la clase del Listado 12, la URI que se le ha
asignado en el struts-config.xml es “GestionRutas.do”. Si se desea invocar el método
“mostrarGestionRutas” de la misma, una posibilidad sería la que aparece en el Listado
// 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());
Para el resto de apartados de la aplicación, se ha realizado un mecanismo continuo de
pruebas paralelo al proceso de desarrollo, en el que se han ido resolviendo los
problemas de forma escalonada, dando lugar a un conjunto bastante robusto de la
aplicación
Las principales pruebas versaron sobre la modificación de un archivo de configuración
remoto, el gwRDSIH323.cfg perteneciente al Gateway RDSI – H323 del Área de
Ingeniería Telemática.
5.1 Simulación de acceso SSH
En teoría, la aplicación debe ser capaz de descargar el fichero de un servidor remoto,
volver a subirlo y ejecutar comandos remotos, todo ello mediante SSH. Para la
realización de pruebas, se ha procedido a:
Habilitar el demonio de SSH en la máquina local (sshd)
Crear una cuenta de usuario ficticia en local, que simule la cuenta que se
habilitará en el servidor real de la aplicación.
Copiar el fichero gwRDSIH323.cfg al directorio local donde se desee (siempre y
cuando el usuario SSH ficticio creado al efecto tenga permisos de lectura y
escritura en él).
A continuación se ha dado de alta el servicio, introduciendo los datos del servidor local
(URL: localhost, etc), y los datos de la cuenta del usuario creado para las pruebas.
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 87 UNIVERSIDAD DE SEVILLA
5.2 Simulación de ejecución remota de comandos
Para comprobar la correcta ejecución de comandos vía SSH, se ha establecido como
comando de reinicio un simple ‘cat’ del fichero recién modificado a otro fichero de
copia. De este modo, toda modificación del fichero gwRDSIH323.cfg debe producir la
regeneración de dicho fichero de copia.
5.2.1 Generación de las plantillas de conversión
Como ya se ha introducido en apartados anteriores, para la modificación de un fichero
remoto, al GSAIT deben proporcionársele tres plantillas: el procesador de descarga, el
procesador de subida y el descriptor de formulario. El formato de cada una de estas
plantillas se discute en profundidad en el apartado 10.3, “Formularios dinámicos y
procesamiento de ficheros”.
Se muestra en este apartado cómo serían estas plantillas para el fichero de ejemplo
gwRDSIH323.cfg.
5.2.2 Formato original del fichero
El formato original del fichero gwRDSIH323.cfg es de texto plano, y se muestra en el
Listado 18.
# Nombre del GatewayGW_NAME = gwRDSIH323
# Número de canales activos (2 por cada BRI)NUM_CHANNELS = 2
# MSN (Multiple Subscriber Numbers) asociado a cada canal activo# IMPORTANTE: La extension "603" tiene asociado el "MSN = 3"# ("60" es añadido por centralita: "6"-Pasivo largo, "0"-Numero del bus)MSN_0 = 3MSN_1 = 4
# Números adicionales asociados a cada canal activo# ADN_MSN_0 = 3125;3126# ADN_MSN_1 = 3125;3127;3128
# Número de teléfono donde redireccionar las llamadas H.323 entrantesDEFAULT_NUMBER = 38
# Asociación para redireccionar a una determinada IP H323 en funcióndel
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 88 UNIVERSIDAD DE SEVILLA
# número teléfonico desde el que se ha realizado la llamada teléfonicaentrante.## NUMBER2ALIAS = <Numero_teléfono_llamante>-<IP_H323>## Si no se indica ninguno, se envia un tono de 400 Hz al teléfonollamante## Este parámetro es NECESARIO para encaminar la llamada de RDSI->H.323# IMPORTANTE: La extension "603" tiene asociado el "Número = 3"# ("60" es añadido por centralita: "6"-Pasivo largo, "0"-Numero del bus)#NUMBER2ALIAS = 3-193.147.162.162#NUMBER2ALIAS = 4-193.147.162.162NUMBER2ALIAS = 3-127.0.0.1NUMBER2ALIAS = 4-127.0.0.1
# Dirección IP H323 donde redireccionar las llamadas telefónicasentrantes# cuando no se ha hecho uso de la opción "NUMBER2ALIAS".# DEFAULT_TERMINAL = 193.147.162.166
# Puerto para llamadas H.323 entrantes (las salientes siempre usan el1720)LISTEN_PORT = 1721
# Codecs admitidos# Orden de preferencia por defecto: G711_A, G711_U, GSM (MS-GSM), LPCG711_ALAW_CODEC = yG711_ULAW_CODEC = yGSM_CODEC = nLPC_CODEC = n
# Monitorización de los canales RDSIUSE_MONITOR = y
# Fichero donde almacenar la monitorizacion de los canales RDSIMONITOR_FILE = ./registro/monitor.openisdngw
# Nivel de traza de la ejecución del servidor (0-4)TRACE_LEVEL = 0
# Fichero donde almacenar la traza de ejecuciónTRACE_FILE = ./registro/trace.openisdngw
# Tiempo de espera (en segundos) para las llamadas RDSI entrantesTIMEOUT_ANSWER = 30
# Buffer para la corrección del jitter (en milisegundos de retraso)JITTER = 30
# Usar GatekeeperUSE_GATEKEEPER = n
# Dirección IP del Gatekeeeper (usar "*" para broadcast)# GATEKEEPER_ADDR = 193.147.162.166# GATEKEEPER_ADDR = *
# Prefijos enviados al Gatekeeper# PREFIX_x = <prefix>
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 89 UNIVERSIDAD DE SEVILLA
# PREFIX = 9# PREFIX = 6# PREFIX = 0
# Dirección de callback# CALLBACK =
Listado 18: Formato original del fichero gwRDSIH323.cfg
5.2.3 Procesador de Descarga
El procesador de descarga se trata de un documento XML con formato adecuado para
que la aplicación atox sea capaz de convertir el fichero gwRDSIH323.cfg en un
documento XML que entienda el motor del GSAIT. Su contenido se muestra en el
<xsl:apply-templates select="fieldValue/field"/><!-- El numero de canales se puede obtener contando el numero devalores de MSN que se han dado -->NUM_CHANNELS = <xsl:value-of select="count(fieldValue/multiField[name= 'canalesActivos__X__MSN' and value != ''])"/>
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 94 UNIVERSIDAD DE SEVILLA
<!-- Campos que pueden aparecer multiples veces CAMPO = VALOR1 CAMPO = VALOR2 ... CAMPO = VALORN --><xsl:if test="name='NUMBER2ALIAS'"><xsl:for-each select="value"><xsl:if test=". != ''">NUMBER2ALIAS = <xsl:value-of select="."/></xsl:if></xsl:for-each></xsl:if>
<!-- Campos booleanos --><xsl:if test="name='G711_ALAW_CODEC' and value='on'">G711_ALAW_CODEC = y</xsl:if><xsl:if test="name='G711_ALAW_CODEC' and not(value = 'on')">G711_ALAW_CODEC = n</xsl:if>
<xsl:if test="name='G711_ULAW_CODEC' and value='on'">G711_ULAW_CODEC = y</xsl:if><xsl:if test="name='G711_ULAW_CODEC' and not(value = 'on')">G711_ULAW_CODEC = n</xsl:if>
<xsl:if test="name='GSM_CODEC' and value='on'">GSM_CODEC = y</xsl:if><xsl:if test="name='GSM_CODEC' and not(value = 'on')">GSM_CODEC = n</xsl:if>
<xsl:if test="name='LPC_CODEC' and value='on'">LPC_CODEC = y</xsl:if><xsl:if test="name='LPC_CODEC' and not(value = 'on')">LPC_CODEC = n</xsl:if>
<xsl:if test="name='USE_GATEKEEPER' and value='on'">USE_GATEKEEPER = y
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 95 UNIVERSIDAD DE SEVILLA
</xsl:if><xsl:if test="name='USE_GATEKEEPER' and not(value = 'on')">USE_GATEKEEPER = n</xsl:if>
</xsl:template>
<xsl:template match="fieldValue/multiField"><xsl:if test="name='canalesActivos__X__MSN' and value != ''">MSN_<xsl:value-of select="dimensionValue"/> = <xsl:value-ofselect="value"/></xsl:if>
<xsl:if test="name='canalesActivos__X__ADN-MSN' and value != ''">ADN_MSN_<xsl:value-of select="dimensionValue"/> = <xsl:value-ofselect="value"/></xsl:if>
</xsl:template></xsl:stylesheet>
Listado 20: Procesador de subida del fichero gwRDSIH323.cfg
5.2.5 Descriptor del formulario
El descriptor de formulario describe los campos de los que debe estar compuesto el
formulario que se muestre al usuario para modificar el fichero en cuestión. El empleado
para las pruebas se muestra en el
<?xml version="1.0" encoding="ISO-8859-1"?><formConfig> <section name="config" label="Configuracion general del Gateway del AIT">
<field name="GW_NAME" title="GW_NAME" type="TEXT" label="Nombre del Gateway"/>
type="TEXT" label="Número de telefono donde redireccionar las llamadas H.323 entrantes"/>
<field name="NUMBER2ALIAS" title="NUMBER2ALIAS" type="FSELECT" label="Asociacion para redireccionar a una determinada IP H.3232 en funcion del numero telefonico desde el que se ha realizado la llamada telefonica entrante.Formato: [Numero_Llamante]-[IP-H323]"/>
GSAIT Test del mecanismo de modificación de archivos
PROYECTO FIN DE CARRERA 96 UNIVERSIDAD DE SEVILLA
<field name="DEFAULT_TERMINAL" title="DEFAULT_TERMINAL" type="TEXT" label="Direccion IP H323 donde redireccionar las llamadas telefonicas entrantes cuando no se ha hecho uso de la opcion NUMBER2ALIAS"/>
<field name="LISTEN_PORT" title="LISTEN_PORT" type="TEXT" label="Puerto para llamadas H.323 entrantes (las salientes siempre usan el 1720)"/>