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
SCAIT: Servicios de calificaciones del Área de Ingeniería Telemática
Autor: José Luis Sánchez Jurado Tutor: Fco. Javier Muñoz Calle
SCAIT Índice
Proyecto Fin de Carrera 3 Universidad de Sevilla
ÍNDICE DEL PROYECTO 1. Introducción.................................................................................................................. 7
1.1. Objetivos iniciales ............................................................................................ 7 1.2. Proyectos relacionados ..................................................................................... 8 1.3. Estructura del proyecto..................................................................................... 9 1.4. Materiales y medios empleados...................................................................... 10
1.4.1. Tecnologías empleadas................................................................................. 10 1.4.2. Materiales ..................................................................................................... 12 1.4.3. Software........................................................................................................ 13
2. Base Teórica ............................................................................................................... 15 2.1. Tecnologías de programación Web ..................................................................... 15
2.1.1. XML ............................................................................................................. 15 2.1.1.1. Introducción........................................................................................... 15 2.1.1.2. Reglas sintácticas................................................................................... 15 2.1.1.3. DTD (Definición de Tipos de documentos) .......................................... 17 2.1.1.4. XML Schema......................................................................................... 19
2.1.2. JSP ................................................................................................................ 21 2.1.2.1. Introducción a JSP................................................................................. 21 2.1.2.2. Servidores web para Servlets.................................................................24 2.1.2.3. Librerías de etiquetas (Taglibs) .............................................................25
2.1.2.3.1. Introducción................................................................................... 25 2.1.2.3.2. Tipos de etiquetas ........................................................................... 26 2.1.2.3.3. Componentes de la librería de etiquetas......................................... 27
2.1.2.3.3.1. Descriptor de la librería.......................................................... 27 2.1.2.3.3.2. Controlador de etiquetas......................................................... 32
2.1.2.4. Java como base de JSP .......................................................................... 33 2.1.2.4.1. API SAX para el mapeo de XML a Java........................................ 34
2.1.2.4.1.1. Introducción............................................................................ 34 2.1.2.4.1.2. APIs: SAX vs DOM.................................................................. 34 2.1.2.4.1.3. Parser SAX: Xerces................................................................ 35 2.1.2.4.1.4. El interface ContentHandler...................................................35
2.1.2.4.2. API JavaMail. ................................................................................. 36 2.1.2.4.2.1. Clases principales................................................................... 36 2.1.2.4.2.2. La clase Session....................................................................... 36 2.1.2.4.2.3. La clase Message..................................................................... 37 2.1.2.4.2.4. La clase Address...................................................................... 38 2.1.2.4.2.5. La clase Authenticator............................................................. 39 2.1.2.4.2.6. La clase Transport ................................................................... 40
2.1.3. Base de datos relacional ............................................................................... 40 2.1.4. Seguridad...................................................................................................... 41
2.1.4.1. Protocolo Web Seguro HTTPS.............................................................. 41 2.1.4.1.1. Protocolo SSL................................................................................. 41
2.1.4.1. Algoritmo blowfish ............................................................................... 43 2.2. Tecnologías de Soporte de transmisión usadas para el envío de SMS................ 44
2.2.1. Servicio SMS en telefonía móvil.................................................................. 44 2.2.1.1. Envío SMS entre terminales móviles dentro de una red móvil. ............ 45
2.2.1.1.1. Arquitectura de red. ........................................................................ 46 2.2.1.2. Envío SMS desde un ordenador hacia la red móvil............................... 48
SCAIT Índice
Proyecto Fin de Carrera 4 Universidad de Sevilla
2.2.1.2.1. Conexión directa del ordenador a la red móvil............................... 49 2.2.1.2.2. Envío de SMS a través de Internet. ................................................ 49
3. Funcionalidades del proyecto ..................................................................................... 51 3.1. Consulta vía Web de calificaciones y suscripción a los distintos servicios. ....... 51 3.2. Publicación de calificaciones............................................................................... 58
3.2.1. Envío de calificaciones por correo electrónico............................................. 60 3.2.2. Envío de calificaciones por SMS.................................................................. 61
4. Descripción detallada del código................................................................................ 63 4.1. Base de datos relacional ...................................................................................... 63 4.2. Beans de datos ..................................................................................................... 70 4.3. Lógica general de SCAIT.................................................................................... 71
4.3.1. Paquete Scait ................................................................................................ 71 4.3.2. Paquete Tags................................................................................................. 74
4.3.2.1. Introducción........................................................................................... 74 4.3.2.2. Etiquetas creadas en el proyecto............................................................ 75
4.3.3. Paquete Utilidades ........................................................................................ 76 4.4. Servicio de correo electrónico ............................................................................. 77 4.5. Servicio SMS....................................................................................................... 79
4.5.1. Paquete ServicioSMS. .................................................................................. 79 4.5.1.1. Clase ServicioSMS................................................................................ 79 4.5.1.2. Clase ClaseGenericaEnvioSMS. ........................................................... 81
4.5.2. Paquetes con la lógica de cada proveedor. ................................................... 81 4.5.2.1. Solución de envío de SMS proporcionada por Vodafone. .................... 82 4.5.2.2. Solución de envío de alertas SMS proporcionada por Mediafusión. .... 84
4.6. Interfaces Web..................................................................................................... 85 4.7. Fichero de configuración de SCAIT.................................................................... 88
5. Planificación ............................................................................................................... 91 6. Pruebas realizadas ...................................................................................................... 92
6.1. Datos de partida................................................................................................... 92 6.2. Pruebas realizadas................................................................................................ 92
6.2.1. Comportamiento de las interfaces Web........................................................ 92 6.2.1.1. Interfaz de los alumnos.......................................................................... 92 6.2.1.2. Interfaz de publicación de exámenes..................................................... 92
6.2.2. Publicación de calificaciones ....................................................................... 92 7. Líneas de continuación ............................................................................................... 92 8. Conclusiones............................................................................................................... 92 9. Bibliografía................................................................................................................. 92
Libros.......................................................................................................................... 92 Sitios Web .................................................................................................................. 92
ANEXOS........................................................................................................................ 92 A. Servidores y paquetes instalados ............................................................................... 92
A.1. Servidores ........................................................................................................... 92 A.1.1. Postgres........................................................................................................ 92 A.1.2. SendMail...................................................................................................... 92
A. 2. Paquetes instalados ............................................................................................ 92 B. Contenido del CD del proyecto ................................................................................. 92
B.1. Directorio Raíz.................................................................................................... 92 B.1.1. Carpetas ....................................................................................................... 92
C. Proveedores del servicio de envío de SMS................................................................ 92
SCAIT Índice
Proyecto Fin de Carrera 5 Universidad de Sevilla
C.1. Listado de empresas del sector ........................................................................... 92 C.2. MediaFusion ....................................................................................................... 92
C.2.1. Definición del producto de alertas Premium MT ........................................ 92 Coste del servicio para el usuario:.................................................................. 92 Eleccion del Alias........................................................................................... 92 Información adicional del Servicio................................................................. 92
C.2.2. Pasarela de Alertas SMS-HTTP .................................................................. 92 C.2.2.1. Introducción .......................................................................................... 92 C.2.2.2. Requisitos previos................................................................................. 92 C.2.2.3. Notificaciones de Altas/Bajas de suscripción....................................... 92 C.2.2.4. Envío de Alertas.................................................................................... 92
Dirección de la pasarela de alertas ................................................................. 92 Formato de las peticiones ............................................................................... 92 Mensajes binarios ........................................................................................... 92 Códigos de retorno ......................................................................................... 92
C.2.2. Condiciones económicas para la contratación del servicio.......................... 92 C.2.2.1. Características de la acción................................................................... 92 C.2.3.2. Condiciones económicas.......................................................................92
C.3. Vodafone. Plug InRed......................................................................................... 92 C.3.1. Definición del producto Plug InRed ............................................................ 92 C.3.2. API suministrada.......................................................................................... 92
C.3.2.1. Clase SMS............................................................................................. 92 C.3.2.1. Clase SMSManager .............................................................................. 92
C.3.3. Condiciones económicas.............................................................................. 92 D. Manual de usuario de SCAIT .................................................................................... 92
D.1. Servicios ofrecidos a los alumnos ...................................................................... 92 D.2. Web de suscripción a los distintos servicios y consulta de calificaciones ......... 92
D.2.1. Acceso ......................................................................................................... 92 D.2.1. Pagina principal ........................................................................................... 92
14.2.1.1. Cierre de la sesión................................................................................ 92 D.2.1.2. Modificación de datos personales......................................................... 92 D.2.1.3. Suscripción a los distintos servicios ..................................................... 92 D.2.1.4. Visualización de notas ya publicadas ................................................... 92
D.3. Servicios ofrecidos a los profesores ................................................................... 92 D.4. Web de publicación de exámenes....................................................................... 92
E. Manual de administración de SCAIT......................................................................... 92 E.1. Instalación de la aplicación ................................................................................. 92 E.2. Configuración inicial de SCAIT ......................................................................... 92 E.3. Mantenimiento de la aplicación .......................................................................... 92
E.3.1. Seguimiento de trazas de las operaciones lanzadas en el servidor............... 92 E.3.2. Activación y desactivación del servicio de envío SMS ............................... 92 E.3.3. Modificaciones necesarias para cambiar de proveedor SMS....................... 92 E.3.4. Alumno de prueba........................................................................................ 92 E.3.5. Borrado de los datos anuales........................................................................ 92
SCAIT Índice
Proyecto Fin de Carrera 6 Universidad de Sevilla
SCAIT 1. Introducción
Proyecto Fin de Carrera 7 Universidad de Sevilla
1. Introducción
1.1. Objetivos iniciales
Una de las mayores preocupaciones de los alumnos es sin duda conocer cuanto antes los
resultados de la corrección de sus exámenes. Pasadas varias semanas de la fecha de
realización de cada examen la inquietud de los alumnos aumenta, deseando conocer
cuanto antes sus calificaciones. Revisan periódicamente los tablones de anuncios de las
asignaturas en busca de la lista con las calificaciones y en numerosas ocasiones se
ponen en contacto con los profesores para preguntar el día exacto de publicación de los
resultados, con la consiguiente molestia que ello acarrea para los profesores.
En algunos casos, las notas son publicadas en Internet al mismo tiempo que en el tablón
de anuncios de la asignatura. Esto evita que el alumno tenga que desplazarse hacia su
centro de estudios para conocer sus calificaciones, teniendo esa información disponible
desde cualquier PC con conexión a Internet.
Sin embargo, el alumno, al no conocer cuando estarán disponibles las notas del examen,
tendrá que acceder periódicamente a la página Web de la asignatura para comprobar si
ya están disponibles o no.
La inquietud por conocer las calificaciones por parte de los alumnos es especialmente
grande en la época de Junio-Julio, una vez finalizados todos los exámenes. Al no tener
clases, bastantes alumnos pueden optar por desplazarse a lugares de descanso como
playas, pueblos en la sierra,…, pero siempre con la intranquilidad de cuando saldrán las
notas, si se estará aprobado o no, y cuando será la fecha de la revisión. Si no se dispone
de Internet en dichos lugares, tendría que implicar a terceras personas para conocer sus
calificaciones.
Estudiada la situación anterior, se decidió ofrecer a la comunidad universitaria los
siguientes servicios:
SCAIT 1. Introducción
Proyecto Fin de Carrera 8 Universidad de Sevilla
• Ofrecer información de calificaciones vía Web de forma personalizada, de forma
que cada alumno pueda observar todas sus calificaciones del curso académico
desde una misma pagina Web, sin tener que ir recorriendo las distintas paginas
de las asignaturas en las que se encuentre matriculado.
• Ofrecer información de calificaciones a través del correo electrónico, de tal
forma que los alumnos reciban automáticamente un correo electrónico con sus
calificaciones y con la fecha de la revisión, en el mismo instante en el que las
notas sean publicadas. De esta forma, los alumnos no tendrán que visitar
periódicamente la Web de información de calificaciones, simplemente bastará
con mirar su correo para obtener información de sus calificaciones.
• Ofrecer información de calificaciones a través de SMS. Sin duda, este es el
servicio más novedoso y más eficaz a la hora de informar instantáneamente a los
alumnos de sus notas. Hoy en día la mayoría de los estudiantes universitarios
posee un móvil, que llevan consigo durante todo el día. Con este servicio, los
alumnos tendrían la seguridad de que conocerían sus calificaciones sin ninguna
demora, independientemente del lugar donde se encuentren.
1.2. Proyectos relacionados
En el Área de Ingeniería Telemática de la Escuela de Ingenieros de Sevilla se han
desarrollado con anterioridad otros proyectos en aras de ofrecer a la comunidad
Universitaria distintos servicios relacionados con la información de calificaciones. En
este sentido se ha de mencionar aquí el SNAIT (Servidor de Notas del Área de
Ingeniería Telemática). SNAIT ofrece el servicio de información de calificaciones a
través del teléfono, informando al alumno mediante voz digitalizada de la calificación
obtenida.
Así mismo, al mismo tiempo que este proyecto se ha estado desarrollando el proyecto
GSAIT (Gestor de Servidores del Área de Ingeniería Telemática). GSAIT 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 distintos servidores del Área.
SCAIT 1. Introducción
Proyecto Fin de Carrera 9 Universidad de Sevilla
GSAIT 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)
desarrollado en este proyecto.
1.3. Estructura del proyecto
En este apartado se exponen, de forma muy somera, las distintas partes que componen
el proyecto. De acuerdo con el apartado anterior, el objetivo del proyecto es crear tres
nuevos servicios relacionados con la información de las calificaciones de los exámenes
a los alumnos: vía Web, vía correo electrónico y vía SMS.
Para ofertar el servicio vía Web, se ha de crear un espacio Web donde cada alumno
pueda consultar todas sus notas conforme se van publicando.
Para ofertar los servicios vía correo electrónico y vía SMS, al tratarse de servicios
automáticos de envío desde el profesor hacia los alumnos, éstos deben tener la
posibilidad de elegir si desean suscribirse a ellos o no. Es necesario un espacio Web
donde cada alumno pueda suscribirse a estos servicios o cancelar su suscripción en el
momento en el que ya no la desee.
Por tanto, se ha creado una interfaz Web para los alumnos, donde tras pasar por un
proceso de autenticación, el alumno podrá ver sus calificaciones que hayan sido
publicadas hasta la fecha así como suscribirse al servicio de correo electrónico y/o SMS.
La suscripción es independiente de una asignatura a otra, es decir, un alumno podrá
suscribirse al servicio SMS en el caso de una serie de asignaturas, no deseando la
suscripción para otras.
SCAIT 1. Introducción
Proyecto Fin de Carrera 10 Universidad de Sevilla
Así mismo, se ha creado una interfaz Web para el profesor, desde la cual podrá publicar
los exámenes en la Web de los alumnos, enviar los correos electrónicos o enviar los
SMS. A esta interfaz Web se accederá desde el Gestor de Servidores del Área de
Ingeniería Telemática (GSAIT).
1.4. Materiales y medios empleados
1.4.1. Tecnologías empleadas
Para la realización del proyecto, se han empleado las tecnologías que se citan a
continuación:
• Soporte de datos: Para almacenar los datos de configuración del servidor
SCAIT, se ha optado por usar XML .
XML es un Lenguaje de Etiquetado Extensible muy simple, pero estricto que
juega un papel fundamental en el intercambio de una gran variedad de datos. Es
un lenguaje que puede parecer muy similar a HTML pero su función principal es
describir datos y no mostrarlos como es el caso de HTML.
Existen gran cantidad de herramientas que permiten la lectura de ficheros XML
por parte de diferentes aplicaciones. Por ejemplo, existen varias APIs Java
(DOM,SAX,..) para la lectura de ficheros XML por parte de programas escritos
en lenguaje Java.
• Lógica de las paginas Web: Para la construcción de las distintas interfaces
Web, se ha empleado la tecnología JSP.
JSP permite crear páginas Web dinámicas usando de fondo lenguaje Java. Dado
lo extendido que está Java, se optó por esta opción frente a otras tecnologías
como PHP. Se ha pretendido separar claramente el código JSP del código Java,
de forma que el fichero .jsp quedara lo más claro posible. Para ello, se ha
recurrido al uso de librerías de etiquetas (taglibs), que permiten encapsular la
SCAIT 1. Introducción
Proyecto Fin de Carrera 11 Universidad de Sevilla
lógica Java dentro de la invocación a una etiqueta personalizada con una sintaxis
equivalente a cualquier etiqueta propia del lenguaje HTML .
Para la comprobación de la validez de los datos introducidos por los usuarios en
distintos formularios que componen las interfaces Web, se ha usado la
tecnología JavaScript. JavaScript no es un lenguaje de programación
propiamente dicho. Es un lenguaje script u orientado a documento, como pueden
ser los lenguajes de macros que tienen muchos procesadores de texto. Se utiliza
para extender las capacidades del lenguaje HTML, siendo algunas de ellas la
revisión de formularios, efectos en la barra de estado, etc. El navegador del
cliente es el encargado de interpretar las instrucciones JavaScript y ejecutarlas.
Esta es la diferencia principal entre JavaScript y cualquier lenguaje CGI.
• Base de datos relacional: En toda aplicación Web en la que se necesite
almacenar, modificar y consultar datos es necesario el uso de una base de datos.
Debido a la diversidad de lenguajes y de bases de datos existentes, la manera de
comunicar entre unos y otras sería realmente complicada a gestionar de no ser
por la existencia de estándares que nos permiten el realizar las operaciones
básicas de una forma universal.
SQL (Structured Query Language) es un lenguaje estándar de comunicación
con bases de datos. Permite trabajar con cualquier tipo de lenguaje (ASP, PHP,
JSP,…) en combinación con cualquier tipo de base de datos (MS Access, SQL
Server, MySQL, POSTGRESQL...).
El hecho de que sea estándar no quiere decir que sea idéntico para cada base de
datos. En efecto, determinadas bases de datos implementan funciones específicas
que no tienen necesariamente que funcionar en otras.
SQL presenta una potencia y versatilidad notables al tiempo que contrasta con su
accesibilidad de aprendizaje.
SCAIT 1. Introducción
Proyecto Fin de Carrera 12 Universidad de Sevilla
La base de datos que se ha empleado en el proyecto ha sido PostgresSQL, ya
que se trata de una base de datos de código abierto muy avanzada.
• Envío de SMS: Existen dos método para realizar en envío de SMS desde una
aplicación instalada en un ordenador:
o Conectar directamente el ordenador a una red móvil, ya sea conectándolo
directamente a un Terminal móvil con un número operativo y crear una
rutina de conexión de la aplicación con el móvil mediante comandos AT;
o bien haciendo uso de una tarjeta PCMCIA que proporcione
directamente acceso a la red móvil (GMS o UMTS).
o Realizar el envío SMS a través de Internet realizando una conexión
contra el SMSC de cualquiera de las tres operadoras móviles que existen
actualmente en España o bien realizar la conexión contra las interfaces
de terceras compañías que ofrezca el servicio de envío de SMS. La
tecnología usada para esta conexión dependerá de la operadora a la que
se conecte el sistema.
1.4.2. Materiales
Para el desarrollo del proyecto se ha requerido lo siguiente:
• Un ordenador en el que se ha instalado el entorno de desarrollo necesario para la
implementación del SCAIT.
• Conexión a Internet para: búsqueda de información sobre las distintas
tecnologías usadas en el proyecto; petición vía correo electrónico de información
a las distintas empresas proveedoras del servicio de envió de SMS; pruebas de
funcionamiento de las interfaces Web, del envió de correo electrónico y envió
SMS.
• Teléfono para contactar telefónicamente con las empresas proveedoras del
servicio de envío SMS
SCAIT 1. Introducción
Proyecto Fin de Carrera 13 Universidad de Sevilla
Para la puesta en marcha de SCAIT se requiere lo siguiente:
• Un ordenador donde instalar los servidores, base de datos, paquetes y código
fuente necesario para el funcionamiento de SCAIT.
• Conexión permanente a Internet desde el ordenador donde se encuentra instalado
SCAIT para:
o Ofrecer las interfaces Web de suscripción a los distintos servicios a los
alumnos desde cualquier PC personal con conexión a Internet.
o Realizar el envío de las calificaciones a través del correo electrónico.
o Realizar el envío de las calificaciones en formato SMS. Los mensajes
cortos tendrán que enviarse a través de Internet hacia los distintos
proveedores que se contraten, para que éstos se encarguen del envío a
través de la red móvil.
1.4.3. Software
Para el desarrollo del proyecto se ha usado un entorno de desarrollo compuesto
exclusivamente por aplicaciones no comerciales de libre distribución. Se ha encontrado
una gran diversidad de aplicaciones para el desarrollo del proyecto, de entre las cuales
se ha optado por usar las siguientes:
• Eclipse: (Versión 3.0) Es un entorno de trabajo sobre el que se pueden montar
herramientas de desarrollo para cualquier lenguaje, mediante la implementación
de los plugins adecuados. Se ha usado como entorno de desarrollo del código
Java.
La arquitectura de plugins de Eclipse permite, además de integrar diversos
lenguajes sobre un mismo IDE, introducir otras aplicaciones accesorias que
pueden resultar útiles durante el proceso de desarrollo como: herramientas UML,
editores visuales de interfaces, ayuda en línea para librerías, etc.
El IDE Eclipse es una de las herramientas que se engloban bajo el denominado
Proyecto Eclipse. El Proyecto Eclipse aúna tanto el desarrollo del IDE eclipse
como de algunos de los plugins mas importantes (como el JDT, plugin para el
SCAIT 1. Introducción
Proyecto Fin de Carrera 14 Universidad de Sevilla
lenguaje Java, o el CDT, plugin para el lenguaje C/C++). La instalación de los
plugins de eclipse es tan sencilla como descargarlos de Internet, y
descomprimirlos en la carpeta “plugins” del directorio eclipse.
Al estar Eclipse escrito en Java, en necesario, para su ejecución, que exista un
JRE (Java Runtime Environment) instalado previamente en el sistema
• pgadminIII: Es un cliente de base de datos postgreSQL, usado durante el
desarrollo, para crear la base da datos, gestionar las distintas tablas y datos.
PgAdminIII es una interfaz para el diseño y administración de una base de datos
PostgreSQL, diseñada para ejecutarse en la mayoría de los Sistemas Operativos.
La aplicación corre bajo GNU/Linux, FreeBSD y Windows 2000/XP.
PgAdminIII esta diseñado para responder a las necesidades de todos los
usuarios, desde escribir simples consultas SQL a desarrollar bases de datos
complejas. La interfaz gráfica soporta todas las características de PostgreSQL y
facilita la administración. La aplicación también incluye un creador de consultas,
un editor SQL, un editor de código del lado del servidor y mucho más.
PgAdminIII se distribuye con un instalador y no requiere ningún driver adicional
para comunicarse con la base de datos.
• Bluefish: (Versión 1.0) Bluefish es un editor para desarrolladores Web y
programadores. Es un edito básico pero suficiente para lo que se necesitaba
desarrollar en el proyecto.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 15 Universidad de Sevilla
2. Base Teórica
2.1. Tecnologías de programación Web
2.1.1. XML
2.1.1.1. Introducción
XML es un Lenguaje de Etiquetado Extensible muy simple, pero estricto que juega un
papel fundamental en el intercambio de una gran variedad de datos. Es un lenguaje que
puede parecer muy similar a HTML pero su función principal es describir datos y no
mostrarlos como es el caso de HTML. XML es un formato que permite la lectura de
datos a través de diferentes aplicaciones. Sirve para estructurar, almacenar e
intercambiar información.
Existen dos tipos de documentos XML: válidos y bien formados.
• Bien formados: son todos los que cumplen las especificaciones del lenguaje
respecto a las reglas sintácticas.
• Válidos: Además de estar bien formados, siguen una estructura y una semántica
determinada por un fichero de “definición” (que es una especie de definición de
la gramática del documento). Existen distintas formas de definir estos ficheros
de “definición” entre ellas DTD y XML Schema.
2.1.1.2. Reglas sintácticas
A continuación se expone un ejemplo muy simple de un archivo XML.
<?xml version="1.0" encoding="UTF-8" standalone="ye s"?> <Alumno> <nombre>Jose Luis</nombre> <apellido>Sánchez Jurado</apellido> <direccion>C\Asencio y toledo 20</direccion> . . . . . </ficha>
En la primera línea se indica que lo que la sigue es XML. Puede tener varios atributos
(los campos que van dentro de la declaración), algunos obligatorios y otros no:
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 16 Universidad de Sevilla
• version: indica la versión de XML usada en el documento. La actual es la
versión 1.0, con lo que no debe haber mucho problema. Es obligatorio ponerlo, a
no ser que sea un documento externo a otro que ya lo incluía
• encoding: la forma en que se ha codificado el documento. Por defecto es UTF-8,
aunque podrían ponerse otras, como UTF-16, US-ASCII, ISO-8859-1, etc. No es
obligatorio salvo que sea un documento externo a otro principal.
• standalone: indica si el documento va acompañado de un DTD ("no"), o no lo
necesita ("yes"); en principio no hay porqué ponerlo, porque luego se indica el
DTD si se necesita.
En cuanto a la sintaxis del documento se han de resaltar las siguientes:
• Los documentos XML son sensibles a mayúsculas, esto es, en ellos se diferencia
las mayúsculas de las minúsculas. Por ello <alumno> sería una etiqueta diferente
a <Alumno>.
• Además todos los espacios y retornos de carro se tienen en cuenta (dentro de las
etiquetas, en los elementos).
• Hay algunos caracteres especiales reservados, que forman parte de la sintaxis de
XML: <, >, &, " y '. En su lugar cuando queramos representarlos deberemos usar
las entidades < , > , & , " y ' respectivamente.
• Los valores de los atributos de todas las etiquetas deben ir siempre
entrecomillados. Son válidas las dobles comillas (") y la comilla simple (').
Observando el contenido del ejemplo se puede diferenciar entre elementos y etiquetas:
los elementos son las entidades en sí, lo que tiene contenido, mientras que las etiquetas
sólo describen a los elementos. Un documento XML está compuesto por elementos, y
en su sintaxis éstos se nombran mediante etiquetas.
Hay dos tipos de elementos: los vacíos y los no vacíos. Hay varias consideraciones
importantes a tener en cuenta al respecto:
• Toda etiqueta no vacía debe tener una etiqueta de cerrado: <etiqueta> debe estar
seguida de </etiqueta>
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 17 Universidad de Sevilla
• Todos los elementos deben estar perfectamente anidados, es decir, las etiquetas
deben ser cerradas en orden inverso al que se abrieron.
<Alumno><nombre>Jose Luis</Alumno></nombre> -- > I NCORRECTO <Alumno><nombre>Jose Luis</ficha></Alumno> -- > C ORRECTO
• Los elementos vacíos son aquellos que no tienen contenido dentro del
documento. Un ejemplo en HTML son las imágenes. La sintaxis correcta para
estos elementos implica que la etiqueta tenga siempre esta forma: <etiqueta/>.
2.1.1.3. DTD (Definición de Tipos de documentos)
Un DTD no son más que definiciones de los elementos que puede incluir un documento
XML, de la forma en que deben hacerlo (qué elementos van dentro de otros) y los
atributos que se les puede dar.
Hay varios modos de referenciar un DTD en un documento XML:
• Incluir dentro del documento una referencia al documento DTD en forma de
URI (Universal Resource Identifier, o identificador universal de recursos) y
mediante la siguiente sintaxis:
<!DOCTYPE Alumno SYSTEM "http://www.esi.us.es/~jlsa nchez/DTD/Alumno.dtd >
En este caso la palabra SYSTEM indica que el DTD se obtendrá a partir de un
elemento externo al documento e indicado por el URI que lo sigue.
• O bien incluir dentro del propio documento el DTD de este modo:
<?xml version="1.0"?> <!DOCTYPE Alumno [ <!ELEMENT Alumno (nombre+, apellido+, direccion+, foto?)> <!ELEMENT nombre (#PCDATA)> <!ATTLIST nombre sexo (masculino|femenino) #IMPLIE D> <!ELEMENT apellido (#PCDATA)> <!ELEMENT direccion (#PCDATA)> <!ELEMENT foto EMPTY>]> <Alumno> <nombre>Jose Luis</nombre> <apellido>Sánchez Jurado</apellido> <direccion>C\Asencio y toledo 20</direccio n>
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 18 Universidad de Sevilla
</ficha>
La forma de incluir el DTD directamente como en este ejemplo pasa por añadira
la declaración <!DOCTYPE y después del nombre del nombre del tipo de
documento, en vez de la URI del DTD, el propio DTD entre los símbolos '[' y ']'.
Todo lo que hay entre ellos será considerado parte del DTD.
En cuanto a la definición de los elementos, es bastante intuitiva: después de la cláusula
<!ELEMENT se incluye el nombre del elemento (el que luego se indicara en la
etiqueta), y después diferentes cosas en función del elemento:
• entre paréntesis, si el elemento es no vacío, se indica el contenido que puede
tener el elemento: la lista de elementos hijos o que descienden de él si los tiene,
separados por comas; o el tipo de contenido, normalmente #PCDATA, que
indica datos de tipo texto, que son los más habituales.
• si es un elemento vacío, se indica con la palabra EMPTY.
A la hora de indicar los elementos descendientes (los que están entre paréntesis) vemos
que van seguidos de unos caracteres especiales: '+', '*', '?' y '|'. Sirven para indicar qué
tipo de uso se permite hacer de esos elementos dentro del documento:
• + : uso obligatorio y múltiple; permite uno o más elementos de ese tipo dentro
del elemento padre, pero como mínimo uno.
• * : opcional y múltiple; puede no haber ninguna ocurrencia, una o varias.
• ? : opcional pero singular; puede no haber ninguno o como mucho uno.
• | : equivale a un OR, es decir, da la opción de usar un elemento de entre los que
forman la expresión, y solo uno.
De este modo, si por ejemplo encontramos en un DTD la siguiente declaración:
<!ELEMENT Alumno (nombre+, apellido+, direccion*, f oto?, telefono*|fax*)>
Indica que elemento Alumno puede contener los siguientes elementos: un nombre y un
apellido como mínimo, pero puede tener más de uno de cada; opcionalmente puede
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 19 Universidad de Sevilla
incluirse una o varias direcciones, pero no es obligatorio; opcionalmente también se
puede incluir una única foto; y por fin, pueden incluirse, aunque no es obligatorio en
ninguno de los dos casos, uno o más teléfonos o uno o más números de fax.
2.1.1.4. XML Schema
XML Schema es algo similar a un DTD, es decir, que define qué elementos puede
contener un documento XML, cómo están organizados, y que atributos y de qué tipo
pueden tener sus elementos.
Las ventajas de XML Schema con respecto a los DTDs son:
• Usan sintaxis de XML, al contrario que los DTDs.
• Permiten especificar los tipos de datos.
• Son extensibles.
Por ejemplo, XML Schema permite definir el tipo del contenido de un elemento o de un
atributo, y especificar si debe ser un número entero, o una cadena de texto, o una fecha,
etc. Los DTDs no nos permiten hacer estas cosas.
Veamos un ejemplo de un documento XML, y su Schema correspondiente:
<documento xmlns="x-schema:personaSchema.xml"> <persona id="Jose Luis"> <nombre>Jose Luis Sanchez </nombre> </persona> </documento>
Como se puede ver en el documento XML anterior, se hace referencia a un espacio de
nombres llamado "x-schema:personaSchema.xml". Es decir, le estamos diciendo al
analizador sintáctico XML que valide el documento contra el Schema
"personaSchema.xml".
El Schema sería algo parecido a esto:
<Schema xmlns="urn:schemas-microsoft-com:xml-data" xmlns:dt="urn:schemas-microsoft-com:datatyp es"> <AttributeType name='id' dt:type='string' require d='yes'/> <ElementType name='nombre' content='textOnly'/> <ElementType name='persona' content='mixed'>
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 20 Universidad de Sevilla
<attribute type='id'/> <element type='nombre'/> </ElementType> <ElementType name='documento' content='eltOnly'> <element type='persona'/> </ElementType> </Schema>
El primer elemento del Schema define dos espacios de nombre. El primero “xml-data”
le dice al analizador que esto es un Schema y no otro documento XML cualquiera. El
segundo “datatypes” nos permite definir el tipo de elementos y atributos utilizando el
prefijo "dt".
En la siguiente tabla se muestra el significado de cada uno de las etiquetas contenidas en
el XML Schema.
Significado de las etiquetas contenidas en el XML Schema
Nombre Significado
ElementType Define el tipo y contenido de un elemento,
incluyendo los sub-elementos que pueda
contener.
AttributeType Asigna un tipo y condiciones a un
atributo.
Attribute Declara que un atributo previamente
definido por AttributeType puede aparecer
como atributo de un elemento
determinado.
Element Declara que un elemento previamente
definido por ElementType puede aparecer
como contenido de otro elemento.
Es necesario empezar el Schema definiendo los elementos más profundamente anidados
dentro de la estructura jerárquica de elementos del documento XML. Las declaraciones
de tipo ElementType y AttributeType deben preceder a las declaraciones de contenido
Element y Attribute correspondientes.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 21 Universidad de Sevilla
2.1.2. JSP
2.1.2.1. Introducción a JSP
Los servlets y Java Server Pages (JSPs) son dos métodos de creación de páginas Web
dinámicas en servidor usando el lenguaje Java. En ese sentido son similares a otros
métodos o lenguajes tales como el PHP, los CGIs (common gateway interface),
programas que generan páginas Web en el servidor, o los ASP (Active Server Pages),
un método específico de Microsoft.
Para empezar, los JSPs y servlets se ejecutan en una máquina virtual Java, lo cual
permite que, en principio, se puedan usar en cualquier tipo de ordenador, siempre que
exista una máquina virtual Java para él.
El concepto inherente en un archivo JSP es permitir ver un servlet Java como una
pagina HTML, es decir, trata de permitir que se pueda incluir código Java dentro de una
pagina HTML normal.
Una pagina JSP es preprocesada a un archivo “.java”, que luego es compilado para
generar un archivo “.class”. Esta es la innovación que proporciona la tecnología JSP y
que la diferencia de otras semejantes, por ejemplo, una pagina ASP, se compila en
memoria, no en un archivo separado. La figura 1 muestra el flujo de la conversión de
una pagina JSP
Figura 1. Flujo de conversión de una pagina JSP.
Cuando en un servidor Web1 se recibe la petición de una pagina JSP, éste lanza el motor
JSP, que se ejecuta en el mismo proceso que ese servidor Web. El motor JSP
comprueba si la pagina es nueva o ha cambiado, en cuyo caso realiza el proceso de
traslación de la pagina y luego compila el resultado. El proceso de traslación es la parte
principal del funcionamiento de la tecnología JSP, y consiste en la conversión de la
1 En el siguiente apartado se muestran distintos servidores web para servlets y JSP.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 22 Universidad de Sevilla
pagina JSP en un servlet java. Este servlet es compilado mediante el compilador
estándar y ejecutado utilizando el API estándar Java.
El proceso de traslación es el que ralentiza la ejecución de las paginas JSP; sin embargo,
una vez que la pagina JSP ha sido convertida a servlet y compilada, su ejecución es tan
rápida como si su origen hubiese sido un servlet normal.
La figura 2 muestra los componentes involucrados en el procesamiento de la petición
HTTP realizada por el cliente de una pagina JSP:
Figura 2. Componentes involucrados en el procesamiento de la petición HTTP
realizada por el cliente de una pagina JSP
Como muestra la figura anterior y se puede observar en la figura 3, que muestra el
proceso de la petición HTTP en más detalle, todo tratamiento de la petición HTTP que
se hace en el servidor Web hasta que se devuelve la respuesta al cliente, se resume en
cuatro pasos:
1. El motor JSP analiza la página solicitada y crea un fichero de código
fuente Java correspondiente al servlet.
2. El servlet generado se compila para obtener el archivo .class que pasa al
control del motor servlet, que lo ejecuta del mismo modo que si se
tratase de cualquier otro servlet.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 23 Universidad de Sevilla
3. El motor servlet carga la clase del servlet generado para ejecutarlo.
4. El servlet se ejecuta y devuelve su respuesta al solicitante.
La figura muestra el flujo completo desde la petición de la página JSP hasta la
obtención de la respuesta de forma detallada:
Figura 3. Flujo de una petición JSP.
EL proceso es mucho más eficiente de lo que puede deducirse observando la figura
anterior. El análisis de la página y la traslación a servlet solamente ocurre una vez, la
primera ocasión en que se realiza la solicitud de la pagina, o cuando se modifica ésta. La
carga de la clase en el motor servlet también ocurre una sola vez desde la última vez en
que se haya arrancado el motor servlet. Después de esto, el servlet ya está disponible
durante toda la vida de la maquina virtual Java. Incluso para mejorar la eficiencia del
ultimo paso, hay algunos servidores Web que proporcionan un mecanismo de caché de
páginas que reduce el coste de ejecutar la petición y mejora el rendimiento de la
aplicación; es decir, mediante este mecanismo, la generación de la respuesta puede
realizarse una única vez. O bien solamente cuando su contenido dinámico haya variado.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 24 Universidad de Sevilla
2.1.2.2. Servidores web para Servlets
Como se ha mencionado anteriormente, se necesita un programa que sea el que envíe
efectivamente páginas Web al servidor, y reciba las peticiones, las distribuya entre los
servlets, y lleve a cabo todas las tareas de gestión propias de un servidor Web. Mientras
que servidores como el Apache están especialmente pensados para páginas Web
estáticas CGIs, y programas ejecutados por el servidor, tales como el PHP, hay otros
servidores específicos para servlets y JSPs llamados contenedores de servlets (servlet
containers) o servlet engines. Los principales son los siguientes:
• Resin, de Caucho Technologies, un motor especialmente enfocado al servicio de
páginas XML, con una licencia libre para desarrolladores. Incluye soporte para
JavaScript además de Java. Incluye también un lenguaje de templates llamado
XTP.
• BEA Weblogic es un servidor de aplicaciones de alto nivel. Está escrito
íntegramente en Java, y se combina con otra serie de productos, tales como
Tuxedo, un servidor de bases de datos para XML. Su licencia es cara.
• JRun, de Macromedia, un servidor de aplicaciones de Java, de precio medio y
no muy altas prestaciones. Existen versiones gratuitas de evaluación.
• Lutris Enhydra , otro servidor gratuito y Open Source, aunque tiene una versión
de pago. También enfocado a servir XML, y para plataformas móviles.
• El más popular, Open Source, y continuamente en desarrollo, es el Jakarta
Tomcat, del consorcio Apache, un contenedor de servlets con muchos
desarrollos adicionales alrededor; por ejemplo, Cocoon para servir páginas
XML. Puede servir páginas sólo o bien como un añadido al servidor Apache. Es
Open Source, relativamente rápido, y fácil de instalar. Ha sido elegido para la
puesta en marcha del proyecto.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 25 Universidad de Sevilla
2.1.2.3. Librerías de etiquetas (Taglibs)
2.1.2.3.1. Introducción
En la tecnología JSP, las acciones son elementos que pueden crear y accedes a objetos
Java. Estas acciones pueden ser acciones estándar definidas por la especificación Java
Server Pages o acciones personalizadas, creadas por el programador. Una acción
personalizada se invoca en una pagina JSP mediante una etiqueta personalizada. Una
librería de etiquetas es una colección de etiquetas personalizadas.
La tecnología JSP está encaminada a separar en las aplicaciones Web, la capa de
presentación de las demás capas que constituyen las aplicaciones .Las librerías de
etiquetas permiten que el programador Java escriba código para proporcionar acceso a
datos y a otros servicios a los diseñadores Web, de modo que estos utilicen estas
acciones al estilo XML, es decir, casi como si se tratase de las etiquetas HTML
definidas. Cualquier acción que se realice en un aplicación Web es susceptible de
convertirse en una acción de un pagina JSP. Por ejemplo, para acceder a una base de
datos, usando una librería de etiquetas, no se ha de conocer nada sobre excepciones,
conexiones, drivers JDBC,…
A continuación se citan las características más interesantes y atractivas de las librerías
de etiquetas:
• Las etiquetas personalizadas pueden reducir o eliminar la presencia de scriptlets
en las paginas JSP. Cualquier parámetro necesario puede ser pasado a través de
atributos o en el contenido de una etiqueta. No es necesario ningún código Java
para inicializar o fijar sus propiedades.
• Las etiquetas personalizadas tienen una sintaxis muy simple. Los scriptlets están
escritos en Java, pero las etiquetas personalizadas pueden ser utilizadas como
cualquier etiqueta HTML.
• Las etiquetas personalizadas pueden mejorar la calidad de los desarrollos
creados por no-programadores, permitiéndoles realizar acciones que no es
posible llevar a cabo mediante HTML.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 26 Universidad de Sevilla
• Las etiquetas personalizadas tiene acceso a todos los objetos implícitos de las
paginas JSP, incluyendo entre ellos a los objetos implícitos request, response y
out.
• Las etiquetas personalizadas pueden modificar la respuesta generada por la
página que las ha invocado.
• Las etiquetas personalizadas se pueden comunicar entre si.
• Las etiquetas personalizadas se pueden anidar, permitiendo conseguir iteraciones
muy complejas dentro de una misma pagina JSP.
• Las etiquetas personalizadas encapsulan funciones simples o complejas que
facilitan la legibilidad de las páginas JSP.
• Las etiquetas personalizadas facilitan la reutilización del código, porque pueden
ser utilizadas en cualquier aplicación Web que necesite la funcionalidad que
proporcionan, lo cual además aumenta la portabilidad
• Las etiquetas personalizadas, a partir de la especificación 1.2, disponen de la
interfaz tryCatchFinally para el control de la liberación de recursos en el caso de
que se produzca una excepción inesperada.
2.1.2.3.2. Tipos de etiquetas
Hay dos tipos de etiquetas, las etiquetas con cuerpo y las que carecen de él.
Sintaxis de etiquetas con cuerpo:
<Etiqueta Atributo=”valor” [Atributo=”valor”…] > Cuerpo de la etiqueta </Etiqueta>
Sintaxis de etiquetas sin cuerpo:
<Etiqueta Atributo=”valor” [Atributo=”valor”…] />
Los dos tipos de etiquetas pueden tener atributos que sirven para configurar el
funcionamiento de la etiqueta. Así mismo, estos atributos pueden ser pasados en las
etiquetas con cuerpo formando parte del cuerpo. Véase el ejemplo
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 27 Universidad de Sevilla
Etiqueta sin cuerpo:
<libreria:hola usuario=”<%= nombre%>” />
Etiqueta con cuerpo:
<libreria:hola> <%= nombre%> <libreria:hola />
2.1.2.3.3. Componentes de la librería de etiquetas
Para que una pagina JSP pueda utilizar una librería de etiquetas, ésta debe estar
compuesta por dos tipos de componentes: el descriptor de la librería de etiquetas y los
controladores o manejadores de etiquetas.
2.1.2.3.3.1. Descriptor de la librería
El fichero descriptor de la librería de etiquetas, o fichero Tag Library Decriptor (TLD ),
es un documento XML que describe la librería. Este fichero contiene información
acerca de la librería en su conjunto y acerca de cada una de las etiquetas que la
componen en particular. Este fichero es el utilizado por el contenedor JSP a la hora de
validar la utilización de las etiquetas de la librería.
El fichero TLD normalmente contiene información de cabecera previa a los elementos
utilizados para describir la librería. Entre esta información se encuentra:
Información de la cabecera del fichero TLD
<taglib> La librería de etiquetas en si misma.
<tlibversion> Versión de la librería de etiquetas.
<jspversion> Versión de la especificación Java Server Pages soportada por
la librería de etiquetas. Por defecto es 1.2.
<shortname> Nombre corto y nemotécnico que suele utilizarse como prefijo
en la directiva taglib o para crear prefijos para los
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 28 Universidad de Sevilla
Información de la cabecera del fichero TLD
identificadores.
<uri> URI opcional que identifica la librería de etiquetas.
<info> Descripción opcional de la librería de etiquetas.
Tras esta cabecera se encuentra la descripción de cada una de las etiquetas que la
integran. De los elementos que describen a estas etiquetas, solamente uno de ellos es
obligatorio:
<tagclass>nombreClase</tagclass>
Puede haber más elementos, pero dependerá de la forma en que se haya implementado
la etiqueta en el controlador. Si una etiqueta tiene atributos asociados, estos tienen que
definirse dentro del elemento <tag>. Si cualquiera de estos atributos es necesario, se fija
el atributo <required> a true o yes. Para que la etiqueta pueda utilizar el valor de una
expresión calculada en tiempo de ejecución, hay que asignar true o yes al atributo
<rtexpvalue>. Para cada atributo de una etiqueta se necesitan definir los métodos set( ) y
get( ) en la clase controladora del JavaBean correspondiente. También es posible definir
variables que se puedan utilizar en las etiquetas, mediante el uso de la clase
TagExtraInfo , en cuyo caso la clase debe ser definida dentro de la definición de la
etiqueta de la forma:
<teiclass>nombreClase</teiclass>
Para utilizar la librería de etiquetas descrita en el archivo TLD en una pagina JSP, es
suficiente con importar esa librería a través de la directiva taglib, cuya sintaxis es al
siguiente:
<%@ taglib uri = “ uri “ prefix = ” Prefijo ” %>
donde uri es la dirección Uniform Resource Identifer (URI) que indica la localización
del archivo TLD descriptor de la librería y prefijo es el identificador con le que se
reconocen las etiquetas pertenecientes a esa librería en la pagina JSP.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 29 Universidad de Sevilla
A continuación se describen detalladamente cada una de las etiquetas englobadas entre
los elementos tag que permiten definir una etiqueta personalizada en el fichero
descriptor de la librería, TLD.
Descripción de las etiquetas englobadas entre los elementos tag
<name>nombreEtiqueta</name> Requerido. Definir el nombre de la
etiqueta. Este nombre se utiliza luego en
la página JSP a la hora de usar la
etiqueta: se coloca después de los dos
puntos (:), Por ejemplo:
<libreria : nombreEtiqueta>.
<tagclass>
paquete.clase.nombre
</tagclass>
Requerido. Declarar la clase en la que se
implementa la funcionalidad de la
etiqueta. La clase tiene que estar
completamente cualificada, indicando su
construcción a partir del directorio WEB-
INF/classes, para reflejar la estructura del
paquete y la clase.
<teiclass>paquete.clase.nombre</teiclass> Opcional. Declarar la subclase de
TagExtraInfo que describe las variables
de script introducidas para la etiqueta. Si
la etiqueta no describe ninguna variable,
no es necesario utilizar este elemento. Al
igual que en la clase definida en
<tagclass> debe estar perfectamente
cualificada, representando la estructura
del paquete a partir del directorio WEB-
INF/classes.
<body content>
tagdependent | JSP | empty
</bodycontent>
Opcional. Define el contenido del cuerpo
de la etiqueta. Si se indica empty, en la
página JSP se utilizara la etiqueta con el
formato <librería:nombreEtiqueta/>.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 30 Universidad de Sevilla
Descripción de las etiquetas englobadas entre los elementos tag
Si se indica JSP, el contenido de la
etiqueta puede ser interpretado como JSP
y se puede utilizar la etiqueta en el
formato <librería:nombreEtiqueta>. Si se
indica tagdependent, el contenido de la
etiqueta será interpretado como no-JSP,
por ejemplo, una sentencia SQL. En caso
de no definir este elemento, el valor por
defecto que toma es JSP.
<attribute>
Opcional. Este elemento se utiliza para
definir cada uno de los atributos que se
pueden asignar a la etiqueta. A través de
estos atributos, el autor de la pagina JSP
podrá alterar el comportamiento de la
etiqueta. Las etiquetas dependientes de
este elemento son:
• <name>atributo</name>
Requerido. Define el nombre del atributo
que aparece en la etiqueta dentro de la
pagina JSP. Por ejemplo:
<librería:nombreEtiqueta
atributo=”valorAtributo” />
• <required>true | false</required>
Opcional. Indica si el atributo es o no
opcional a la hora de utilizar la etiqueta
en una pagina JSP. Si no se indica nada,
el valor por defecto es false, es decir, por
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 31 Universidad de Sevilla
Descripción de las etiquetas englobadas entre los elementos tag
defecto el atributo es opcional. Si se
asigna true en este elemento y el atributo
no se indica en el momento de emplear la
etiqueta en la pagina JSP, se producirá un
error cuando se realice la traslación de la
pagina a servlet.
• <rtexpvalue>true|false</rtexpvalue>
Opcional. Indica si el atributo permite una
expresión como valor, de forma que el
valor real del atributo sea calculado
dinámicamente en le momento de la
petición de la pagina. Si no se especifica
este elemento, el valor que toma por
defecto es false.
A continuación se lista parte del archivo taglibs.tld definido en el proyecto. En el se
observa como todas las etiquetas creadas carecen de atributos.
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Li brary 1.1//EN" "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dt d"> <taglib> <tlibversion>1.0</tlibversion> <jspversion>1.2</jspversion> <shortname>etiquetas</shortname> <info> Librería de Etiquetas del Proyecto Fin de Carre ra </info> <!-- Etiqueta para al autenticación de un alumno- -> <tag> <name>compruebaIdentidad</name> <tagclass>tags.CompruebaIdentidadTag</tagclass> </tag> <!-- Etiqueta que realiza la seleccion de alumno --> <tag> <name>seleccionAlumno</name> <tagclass>tags.SeleccionAlumnoTag</tagclass> </tag>
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 32 Universidad de Sevilla
. . . . . . . . . . </taglib>
2.1.2.3.3.2. Controlador de etiquetas
Cada etiqueta personalizada integrante de una librería de etiquetas debe estar definida
en una clase controladora. Una clase controladora para una etiqueta es la que permite
instanciar un objeto que será invocado por el motor JSP a la hora de evaluar la etiqueta
durante la ejecución de la pagina JSP en la que se integra dicha etiqueta. Los métodos
de este objeto pueden ser invocados por la clase que implemente la pagina JSP en todas
la ocasiones en que sea necesario durante la evaluación de la etiqueta.
Cuando el motor JSP se encuentra con el elemento de comienzo de una etiqueta
personalizada, inicializa el controlador de la etiqueta y luego invoca al método
doStartTag(), de esa etiqueta. Cuando se encuentra la etiqueta de cierre, invoca al
método doEndTag() de la etiqueta personalizada. Entre ambas etiquetas se puede
invocar cualquier método que se necesite para interactuar con el cuerpo de la etiqueta.
La interfaz Tag es la que define el protocolo de comunicación entre la clase que
implementa la etiqueta y la clase que implementa la página JSP. Asi, la clase que
implemente la pagina invoca a una serie de métodos previos al llamar al método
doStartTag(),de forma que se garantice que la etiqueta disponga de los elementos que
necesite para sus acciones, como puede ser el conocer el valor de sus atributos. La clase
que implemente la página también garantiza que tras llamar al método doEndtag(),
todos los recursos será devueltos al sistema a través de la llamada al método release().
Si se extiende la interfaz Tag mediante BodyTag, se definen métodos adicionales que
permitirán el acceso del controlador de etiquetas al cuerpo de la etiqueta.
Para no tener que implementar todos los métodos de la interfaz Tag, la especificación
JSP define la clase abstract TagSupport, que es una clase de conveniencia, o adaptadora,
que proporciona implementaciones por defecto para todos los métodos de la interfaz
Tag. Por tanto, la forma más fácil de escribir etiquetas simples es extender la clase
TagSupport, en lugar de implementar la interfaz Tag.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 33 Universidad de Sevilla
La clase TagSupport es pues la clase base que se utiliza en etiquetas simples. La
implementación de la etiqueta dependerá de los métodos que se pueden invocar y de las
necesidades especificas de la etiqueta. La implementación TagBodySupport
proporcionará implementaciones por defecto para todos los métodos de las etiquetas con
cuerpo. La tabla siguiente indica los métodos que se deben implementar en función de
las necesidades de la etiqueta:
Clase Metodos a implementar
Sin atributos ni cuerpo doStartTag, doEndTag, release
Con atributos doStartTag, doEndTag, set/getAtributo1…n
Con cuerpo y sin iteracion doStartTag, doEndTag, release
Con cuerpo y con iteracion doStartTag, doEndTag, doInitBody, doAfterBody
2.1.2.4. Java como base de JSP
Las librerías de etiquetas de JSP encapsulan en si interior código Java para realizar las
funcionalidades deseadas, por ello, se hablará brevemente del lenguaje de programación
Java ya que es bastante conocido y difundido en la actualidad.
Las características de Java se resumen a continuación:
• Lenguaje de propósito general.
• Lenguaje Orientado a Objetos.
• Sintaxis inspirada en la de C/C++.
• Lenguaje multiplataforma: Los programas Java se ejecutan sin variación (sin
recompilar) en cualquier plataforma soportada (Windows, UNIX, Mac...)
• Lenguaje interpretado: El intérprete a código máquina (dependiente de la
plataforma) se llama Java Virtual Machine (JVM). El compilador produce un
código intermedio independiente del sistema denominado bytecode.
• Lenguaje gratuito: Creado por SUN Microsystems, que distribuye gratuitamente
el producto base, denominado JDK (Java Development Toolkit) o actualmente
J2SE (Java 2 Standard Edition).
• API distribuida con el J2SE muy amplia. Código fuente de la API disponible.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 34 Universidad de Sevilla
El entorno mínimo necesario para escribir, compilar y ejecutar programas Java es el
siguiente:
• J2SE (Java 2 Standard Edition) y la documentación (Se descargan por
separado). Esto incluye el compilador Java, la JVM, el entorno de tiempo de
ejecución y varias herramientas de ayuda. La documentación contiene la
referencia completa de la API. Se puede descargar desde la página de SUN
http://java.sun.com/j2se
• Un editor de texto, aunque es muy recomendable usar un Entorno de Desarrollo
Integrado para Java (IDE). Una herramienta de este tipo resulta aconsejable
como ayuda para desarrollar aplicaciones o componentes. En el desarrollo de
este proyecto se ha usado el IDE Eclipse, como ya se ha comentado
anteriormente.
2.1.2.4.1. API SAX para el mapeo de XML a Java.
2.1.2.4.1.1. Introducción
En este apartado se plantea una introducción a la lectura de ficheros XML y su mapeo a
clases de Java con el SAX (Simple Api for Xml) . Así mismo, se explicará por que en
muchas ocasiones este API es superior al DOM (Document Object Model), aunque su
manejo pueda resultar más confuso.
2.1.2.4.1.2. APIs: SAX vs DOM
Pasar un fichero XML a clases de Java es un proceso de parsing, hay que leer y
procesar todo el fichero para hacerlo, por lo que si tenemos que leer gran cantidad de
XML nos comeremos la memoria del sistema de forma rápida.
SAX como DOM son dos APIs, no dos parsers, son dos ideas de como afrontar un
problema, y son muchos los parsers existentes que implementan estas APIs. También
existe una versión de DOM optimizada para Java, llamada JDOM, siendo su
funcionamiento es muy similar al DOM.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 35 Universidad de Sevilla
Quizás el API mas usado sea el DOM, pero no por ello es el mejor. El DOM lee todo el
contenido del fichero de una pasada, y crea en memoria una estructura jerárquica en
forma de árbol que representa el fichero y que luego puede usarse para hacer el mapeo a
clases de Java. La primera de las desventajas es clara, se ha de crear la imagen de los
datos en memoria, por lo que si es muy grande puede ocupar mucho espacio, con una
gran cantidad de pequeños elementos, cuyo control, recorrido y manipulación requieren
aun más memoria y tiempo. Pero sus desventajas van más allá, ya que se han de recorrer
los datos en varias ocasiones, la primera para cargar la imagen en memoria y después
varias veces para sacar la infamación necesaria para nuestra aplicación.
SAX no trabaja así. SAX extrae la información para nuestra aplicación según procesa el
fichero, sin crear ninguna estructura adicional en memoria más que la estrictamente
necesaria para la lectura del fichero. SAX trabaja respondiendo a eventos, eventos que
se producen al procesar el fichero XML, como pueden ser el fin o principio del
documento, el fin o principio de un elemento, etc. Al hacer todo el proceso en una sola
pasada obtenemos un mejor rendimiento.
SAX no es valida en casos en los que la aplicación requiera de algún tipo de
manipulación del documento XML, como por ejemplo para combinar varios o aplicar
una hoja de estilo, entonces DOM (o el más moderno JDOM) es el API que se debería
utilizar.
2.1.2.4.1.3. Parser SAX: Xerces
Lo primero de todo es conseguir un parser real, que implemente SAX (normalmente los
parser de XML pueden trabajar con SAX y DOM). Se ha optado por usar el Xerces para
Java de Apache, que se puede descargar de la página http://xml.apache.org/xerces-j/ . En
dicha página se puede obtener el parser (para varios lenguajes de programación) y otras
herramientas Java para trabajar con XML.
2.1.2.4.1.4. El interface ContentHandler
Este interface es el centro de todo proceso de XML con SAX. Es el que define todos los
eventos que se producen a los largo del proceso del documento, por tanto, las clases de
proceso de XML deberán implementar este interface para que el parser haga lo que se
necesite.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 36 Universidad de Sevilla
Existe una clase, llamada DefaultHandler, que implementa esta interface con los
métodos vacíos, de forma que solo sea necesario sobrescribir los métodos que hagan
falta. Al estar basado el API SAX en eventos que se producen al procesar el fichero, del
estilo de inicio/fin del documento, inicio/fin de un elemento, datos entre tags,…, así
pues los métodos de ContentHandler son del estilo startDocument , endDocument ,
startElement , endElement , characters , etc, que se ejecutaran cuando ocurra dicho
suceso.
2.1.2.4.2. API JavaMail.
2.1.2.4.2.1. Clases principales
En este apartado se hace un repaso de las distintas clases dentro de la interfaz JavaMail
que se han empleado en el desarrollo del proyecto. Dichas clases son: Session,
Message, Address, Authenticator, Transport. Para usarlas, se ha de importar el paquete
javax.mail.
2.1.2.4.2.2. La clase Session
La clase Session define una sesión de correo básica. Es a través de esta de sesión de la
que todas las demás funcionan. El objeto Session se aprovecha de un objeto
java.util.Properties para obtener información como el servidor de correo, el nombre
de usuario, la clave, y otra información que puede compartirse a lo largo de toda la
aplicación. En la aplicación se ha establecido la siguiente información en el objeto
properties:
// Se definen los parámetros de Session Properties props = new Properties(); props.put("mail.transport.protocol",prmProfile.getP rotocoloCorreo()); props.put("mail.smtp.host", prmProfile.getHostCorre o()); props.put("mail.smtp.port", prmProfile.getPuertoCor reo()); props.put("mail.smtp.auth", prmProfile.getAutentica cionCorreo());
El constructor para las clases es privado. Se puede obtener una sola sesión por defecto
que puede ser compartida con el método getDefaultInstance():
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 37 Universidad de Sevilla
Properties props = new Properties(); // Se completa el objeto properties con la informac ion correspondiente Session session = Session.getDefaultInstance(props, null);
O bien, se puede crear una única sesión con getInstance():
Properties props = new Properties(); // Se completa el objeto properties con la informac ion correspondiente Session session = Session.getInstance(props, null);
En ambos casos, el segundo argumento de la función que se utiliza para obtener la
sesión es un objeto Authenticathor, pudiendo tener el valor null si se desea omitir la
autentificación. El objeto Authenticathor se verá mas tarde.
2.1.2.4.2.3. La clase Message.
Una vez obtenido el objeto Session , se crea un mensaje para enviar. Esto se hace con un
objeto Message. Se trata de una clase abstracta, por lo que se trabaja con una subclase,
que en la mayoría de los casos será javax.mail.internet.MimeMessage .
Un MimeMessage es un mensaje de e-mail que entiende los tipos MIME, definidos en
las distintas RFCs. Las cabeceras de mensajes están restringidas a caracteres US-ASCII,
aunque en ciertos campos de cabecera se pueden codificar caracteres no ASCII.
Para crear un Message, es necesario pasar el objeto Session al constructor de
MimeMessage:
// Se crea el message MimeMessage message = new MimeMessage(session);
Una vez creado el mensaje, se ha de configurar sus diferentes partes, como Message
implementa el interface Part (con MimeMessage implementando MimePart).
El mecanismo básico para configurar el contenidos es el método setContent(), con los
argumentos para el contenido y tipo MIME:
message.setContent(“Servicio de calificación del …” ,”text/plian”);
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 38 Universidad de Sevilla
Sin embargo, si se trabaja con un MimeMessage y el mensaje es texto plano, se puede
usar directamente el método setText() que sólo requiere el contenido real, dejando por
defecto el tipo MIME a text/plain:
message.setText (“Servicio de calificación del …”);
Para mensajes de texto plano la última forma es el mecanismo preferido para
seleccionar el contenido. Para enviar otros tipos de mensajes, se emplean otros métodos
Para seleccionar el subject, usamos el método setSubject():
message.setSubject (“Asunto del mensaje”);
2.1.2.4.2.4. La clase Address.
Una vez creada la sesión y el mensaje con todo su contenido, se ha de indicar la
dirección a la que dicho mensaje ha de ser enviado. Esto se realiza mediante el objeto
Address. Al ser una clase abstracta, se usa la clase javax.mail.internet.InternetAddress .
Para crear una dirección con sólo la dirección e-mail, se la pasamos al constructor:
Address arddress = new InternetAddress(“jl.sanchez. [email protected]”);
Si se desea que aparezca el nombre junto a la dirección e-mail, se le ha de pasar al
constructor:
Address address = new InternetAddress(“jl.sanchez.j [email protected]”,”Jose Luis Sanchez”);
Se ha de crear objetos Address para los campos from y to del mensaje. A menos que el
servidor lo evite, no hay nada que nos impida enviar un mensaje que parezca que viene
de otra persona. Por ello, en el mensaje de la aplicación de envío de calificación del
presente proyecto, se ha incorporado un campo llamado código de autenticidad, para
que el alumno sepa que el mensaje recibido procede verdaderamente de la Universidad.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 39 Universidad de Sevilla
Una vez creadas las direcciones, se conectan al mensaje usando los siguientes métodos:
Para identificar al que lo envía, se usan los métodos setFrom() y setReply().
message.setFrom(address); message.setReplyTo (address);
En el caso de que el mensaje necesitara varias direcciones from, se usaría el método
addFrom():
Address address[] = …; message.addFrom(address);
Para identificar a los receptores del mensaje, se usa el método addRecipient(). Este
método requiere un Message.RecipientType junto a la dirección.
message.addRecipient(type,address);
Los tres tipos predefinidos de direcciones son:
Message.RecipientType.TO, receptor directo del mensaje
Message.RecipientType.CC, receptor al que se desea enviar una copia del mensaje
Message.RecipientType.BCC, receptor al que se desea enviar una copia del mensaje
pero sin que el receptor directo tenga constancia de este hecho.
NOTA: El API JavaMail no proporciona mecanismo para chequear la validez de una
dirección e-mail. Por tanto se ha de buscar algún mecanismo de validación fuera del
ámbito del API JavaMail.
2.1.2.4.2.5. La clase Authenticator
El API JavaMail puede aprovecharse de un Authenticator para proteger accesos a
recursos mediante un nombre de usuario y una clave. Para el API JavaMail, el recurso
es el servidor de correo. El Authenticator JavaMail se encuentra en el paquete
javax.mail .
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 40 Universidad de Sevilla
Para usar el Authenticator, se subclasifica la clase abstracta y se devuelve un ejemplar
PasswordAuthentication del método getPasswordAuthentication(). Se debe registrar el
Authenticator con la sesión cuando se crea. Dicho Authenticator será notificado cuando
sea necesaria una autentificación. En la aplicación de envío de correos, el nombre de
usuario y la password se leen desde un fichero de configuración.
Properties props = new Properties(); // Se completa el objeto properties con la informac ion correspondiente Authenticathor auth = new MyAuthenticathor() Session session = Session.getDefaultInstance(props, auth);
2.1.2.4.2.6. La clase Transport
Para el envío de un mensaje se usa la clase Transport. Esta clase entiende el lenguaje
específico del protocolo para enviar mensajes (normalmente SMTP). Es una clase
abstracta y funciona como Session.
Se puede usar la versión por defecto de la clase sólo llamando al método estático send():
Transport.send(message);
Otra posibilidad es obtener un ejemplar específico desde la sesión para nuestro
protocolo, pasándole el nombre de usuario y la clave (en blanco si no son necesarias),
enviar el mensaje, y cerrar la conexión:
message.saveChanges(); // Implicito con send() Transport transport = session.getTransport("smtp"); transport.connect(host, username,password); transport.sendMessage(message,message.getAllRecipie nts()); transport.close()
Esta última forma es mejor cuando se necesita enviar varios mensajes, porque
mantendrá activa la conexión entre mensajes. El mecanismo básico send() hace un
conexión separada al servidor para cada llamada a método.
2.1.3. Base de datos relacional
En el proyecto, se ha optado por el uso de la base de datos relacional POSTGRES ya
que se trata de una base de datos de código abierto muy avanzada. Proporciona un gran
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 41 Universidad de Sevilla
número de características que normalmente solo se encontraban en las bases de datos
comerciales tales como DB2 u Oracle.
PostgreSQL nace en 1985 en la Universidad de Berkley, inicialmente con el nombre de
Postgres, para pasar más tarde, en 1995, a llamarse Postgres95, una vez que se
añadieron las funcionalidades SQL ("Structured Query Language"). En 1996 cambió de
nombre una vez más, y pasó a denominarse PostgreSQL, que es como ha quedado
definitivamente.
PostgreSQL es una base de datos de plataforma múltiple, y se puede encontrar tanto en
forma de fuente como compilada para los siguientes sistemas: Solaris, SunOS, HPUX,
AIX, Linux, Irix, Digital Unix, BSD,NetBSD, FreeBSD, SCO unix, NEXTSTEP y en
general para todos los dialectos Unix, además de para Windows NT.
2.1.4. Seguridad
En este apartado se va a analizar dos mecanismos empleados para garantizar la
seguridad y no vulnerabilidad de datos sensibles (datos personales, claves,…), uno de
ellos en el ámbito de las comunicaciones establecidas entre servidores y navegadores
Web, y otro en el ámbito de el almacenamiento de datos sensibles en base de datos.
El primero de ellos será el uso del protocolo Web seguro HTTPS (basado en el
protocolo SSL), mientras que el segundo se trata de Blowfish, que se ha usado para
encriptar las claves almacenadas en la base de datos.
2.1.4.1. Protocolo Web Seguro HTTPS
Los servidores Web suelen proporcionar mecanismos de seguridad mediante el uso del
protocolo SSL (Secure Sockets Layer), basado en una combinación de técnicas de
encriptación y la utilización de un Certificado Digital. El uso de HTTP sobre SSL se
denomina protocolo seguro HTTPS, recogido en la RFC 2818.
2.1.4.1.1. Protocolo SSL
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 42 Universidad de Sevilla
El protocolo SSL es un sistema diseñado y propuesto por Netscape Communications
Corporation. Se encuentra en la pila OSI entre los niveles de TCP/IP y de los protocolos
HTTP, FTP, SMTP, etc. Proporciona sus servicios de seguridad cifrando los datos
intercambiados entre el servidor y el cliente con un algoritmo de cifrado simétrico,
típicamente el RC4 o IDEA, y cifrando la clave de sesión de RC4 o IDEA mediante un
algoritmo de cifrado de clave pública, típicamente el RSA. La clave de sesión es la que
se utiliza para cifrar los datos que vienen del y van al servidor seguro. Se genera una
clave de sesión distinta para cada transacción, lo cual permite que aunque sea reventada
por un atacante en una transacción dada, no sirva para descifrar futuras transacciones.
MD5 se usa como algoritmo de hash.
Proporciona cifrado de datos, autenticación de servidores, integridad de mensajes y,
opcionalmente, autenticación de cliente para conexiones TCP/IP.
Cuando el cliente pide al servidor seguro una comunicación segura, el servidor abre un
puerto cifrado, gestionado por un software llamado Protocolo SSL Record, situado
encima de TCP. Será el software de alto nivel, Protocolo SSL Handshake, quien utilice
el Protocolo SSL Record y el puerto abierto para comunicarse de forma segura con el
cliente.
El Protocolo SSL Handshake
Durante el protocolo SSL Handshake, el cliente y el servidor intercambian una serie de
mensajes para negociar las mejoras de seguridad. Este protocolo sigue las siguientes
seis fases (de manera muy resumida):
• La fase Hola, usada para ponerse de acuerdo sobre el conjunto de algoritmos
para mantener la intimidad y para la autenticación.
• La fase de intercambio de claves, en la que intercambia información sobre las
claves, de modo que al final ambas partes comparten una clave maestra.
• La fase de producción de clave de sesión, que será la usada para cifrar los datos
intercambiados.
• La fase de verificación del servidor, presente sólo cuando se usa RSA como
algoritmo de intercambio de claves, y sirve para que el cliente autentique al
servidor.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 43 Universidad de Sevilla
• La fase de autenticación del cliente, en la que el servidor solicita al cliente un
certificado X.509 (si es necesaria la autenticación de cliente).
• Por último, la fase de fin , que indica que ya se puede comenzar la sesión segura.
El Protocolo SSL Record
El Protocolo SSL Record especifica la forma de encapsular los datos transmitidos y
recibidos. La porción de datos del protocolo tiene tres componentes:
• MAC-DATA, el código de autenticación del mensaje.
• ACTUAL-DATA, los datos de aplicación a transmitir.
• PADDING-DATA, los datos requeridos para rellenar el mensaje cuando se usa
cifrado en bloque.
2.1.4.1. Algoritmo blowfish
Respecto al sistema que se utiliza para encriptar la información de la claves que se
almacenan en la base de datos, se trata del algoritmo Blowfish, un algoritmo de
hashing2 (como son, por ejemplo DES o SHA, utilizados para encriptar las claves de
usuario en diferentes versiones de UNIX), lo que dicho de manera sencilla es un sistema
que permite codificar la información con un método sencillo pero bastante difícil de
descodificar si no se dispone de la clave original. Este tipo de algoritmos de
encriptación depende de dos cosas, la clave (que cuanto más larga sea mejor, ya que se
utiliza para realizar los cálculos) y el tamaño de los bloques de la información que
utiliza para codificar en cada pasada.
En concreto el algoritmo Blowfish es libre, sin patentes y utiliza bloques de 448 bits
para generar el código después. Además es un algoritmo que lleva ya unos años
funcionando y parece ser que es de los más difíciles de romper si se genera
adecuadamente el cifrado, haciendo prácticamente imposible conseguirlo por ataques de
fuerza bruta y similares.
Para hacer uso de este algoritmo se ha empleado la API blowfish de Java.
2 Un algoritmo de hashing es una función matemática que toma una cadena de longitud variable y la convierte a una cadena de longitud fija.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 44 Universidad de Sevilla
2.2. Tecnologías de Soporte de transmisión usadas
para el envío de SMS
2.2.1. Servicio SMS en telefonía móvil.
Las iniciales corresponden a las palabras inglesas Short Message Service (Servicio de
Mensajes Cortos). Este servicio de telefonía móvil consiste básicamente en el
intercambio de mensajes que pueden incluir letras, números y otros caracteres.
Este intercambio, además de realizarse entre teléfonos móviles, también se puede
producir entre aplicaciones informáticas y terminales e incluso entre aplicaciones
(mensajería máquina-máquina) (Figura 4), por ejemplo:
• envío desde aplicaciones: mensajes publicitarios a una base de datos de clientes.
• envío desde un móvil a una aplicación: votaciones en concursos, petición de un
contenido (logo o melodía para personalizar el móvil).
• intercambio de mensajes entre aplicaciones: envío automático de un mensaje de
alarma disparada por un dispositivo de lectura (por ejemplo un termómetro); el
mensaje lo recibe una aplicación que actúa en función de la información
recibida, por ejemplo enviando un aviso a un técnico de mantenimiento.
Figura 4. Servicio SMS
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 45 Universidad de Sevilla
En las normas GSM y UMTS únicamente se especifica la parte de comunicaciones entre
las estaciones móviles (MS) y el centro de servicio. La comunicación entre el centro del
servicio y las entidades fijas, quedan fuera de estas normas (Figura 5).
Figura 5. Envío de un SMS entre MS y entidad fija.
2.2.1.1. Envío SMS entre terminales móviles dentro de una red móvil.
El servicio SMS se divide en dos servicios Básicos (Figura 6):
1. SM MT (Short Message Mobile Terminated Point-to-Point). Servicio de
entrega de un mensaje desde el SC hasta una MS, obteniéndose un informe
sobre lo ocurrido.
2. SM MO (Short Message Mobile Originated Point-to-Point). Servicio de envío
de un mensaje desde una MS hasta un SC, obteniéndose un informe sobre lo
ocurrido.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 46 Universidad de Sevilla
Figura 6.Servicios básicos SM MT y SM MO.
2.2.1.1.1. Arquitectura de red.
La estructura básica de la red para el servicio SMS se muestra en la figura 7. Las
entidades involucradas son las siguientes:
• MS: Estación móvil
• MSC: Centro de conmutación
• SMS-GMSC: MSC pasarela para el servicio de mensajes cortos (Servicio SM
MT)
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 47 Universidad de Sevilla
• SMS-IWMSC: MSC de interconexión entre PLMN y el SC (Servicio SM MO)
• SC: Centro de Servicio
• HLR (Home Location Register). Base de datos centralizada de la red que
almacena y maneja a todos los suscriptores móviles de un operador en
específico.
• VLR (Visitor Location register). Base de datos que contiene información
temporal, acerca de todos los terminales móviles presentes localizados dentro
del área que atiende un MSC.
Figura 7. Estructura básica de la red para la transferencia de mensajes cortos.
Para la descripción detallada de la arquitectura, se utiliza un modelo de capas, en el que
cada capa o nivel proporciona un servicio a la capa superior, y este servicio se
implementa mediante el protocolo correspondiente. La arquitectura se divide en 4 capas
(Figura 8):
• SM-AL (Short Message Aplication Layer): Nivel de aplicación.
• SM-TL (Short Message Transfer Layer): Nivel de transferencia. Servicio de
transferencia de un mensaje corto entre una MS y un SC (en ambos sentidos) y
obtención de los correspondientes informes sobre el resultado de la transmisión.
Este servicio hace abstracción de los detalles internos de la red, permitiendo que
el nivel de aplicación pueda intercambiar mensajes.
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 48 Universidad de Sevilla
• SM-RL (Short Message Relay Layer): Nivel de repetición. Proporciona un
servicio al nivel de transferencia que le permite enviar TPDU (Transfer Protocol
Data Units) a su entidad gemela.
• SM-LL (Short Message Lower Layers): Niveles inferiores.
Figura 8. Niveles y servicios para el envío de mensajes cortos
2.2.1.2. Envío SMS desde un ordenador hacia la red móvil.
Según se ha mencionado en la introducción del proyecto, existen dos métodos para
enviar SMS desde una aplicación alojada en un ordenador hacia un usuario final:
• Conectar el ordenador directamente a la red móvil, ya sea a través de una tarjeta
PCMCIA que permita el acceso a la red móvil (GSM o UMTS) o bien mediante
conexión directa entre el ordenador y un móvil (por ejemplo con un cable USB).
Figura 9. Conexión directa del ordenador a un Terminal móvil
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 49 Universidad de Sevilla
• Realizar el envío de SMS a través de Internet realizando una conexión contra el
SMSC (Centros de mensajes cortos) de cualquiera de las tres operadoras móviles
que existen actualmente en España o bien realizar la conexión contra las
interfaces de terceras compañías que ofrezca el servicio de envío de SMS.
Figura 10. Conexión a través de Internet
2.2.1.2.1. Conexión directa del ordenador a la red móvil.
Se cita como una posibilidad más dentro de las existentes para el envío de mensajes
cortos SMS desde una aplicación, que corre en un ordenador, hacia los usuarios finales
de la red móvil.
2.2.1.2.2. Envío de SMS a través de Internet.
Para realizar el envío de SMS a través de Internet es necesario realizar una conexión
contra el SMSC de cualquiera de las tres operadoras móviles que existen actualmente en
España. Existen varios protocolos para establecer esta conexión: X.25, SMTP,
CGI/HTTP . Otros servicios como la conexión al MMSC, tienen otros interfaces
diferentes y no compatibles con los actuales, MM7 para MMS o XML sobre HTTP
para Localización.
La gran variedad de protocolos existentes provoca además de confusión a las empresas
que desean conectarse a estos servicios, una clara complejidad en la gestión de los
recursos propios de las compañías. Por tanto, para simplificar la labor de los
desarrolladores y reducir al mínimo los problemas que se derivan de todas estas
SCAIT 2. Base Teórica
Proyecto Fin de Carrera 50 Universidad de Sevilla
circunstancias, las compañías suelen unificar los protocolos de interconexión existentes
en un único interfaz.
Figura 11. Posible torre de protocolos para la comunicación entre una entidad fija y la
SMSC de la operadora de telefonía móvil.
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 51 Universidad de Sevilla
3. Funcionalidades del proyecto
En la introducción se expuso de forma bastante somera, las distintas partes que
componen el proyecto. En este apartado se va a profundizar dando al lector una visión
mas especifica de las distintas funcionalidades que se incluyen:
1. Información de calificaciones a los alumnos mediante el acceso a una
interfaz Web donde se agruparan todas las calificaciones, ya publicadas,
de los exámenes en los que ha participado un alumno.
2. Información de calificaciones a los alumnos, mediante el envío a sus
direcciones de correo electrónico, de los resultados de los exámenes a los
que hayan asistido.
3. Información de calificaciones a los alumnos, mediante el envío de
mensajes cortos (SMS) a sus teléfonos móviles, con los resultados de los
exámenes a los que hayan asistido.
4. Posibilidad de configuración por parte del alumno sobre en que servicios
desea estar suscrito y en cuales no.
5. Publicación, por parte de los profesores responsables de las distintas
asignaturas, de los resultados de un exámenes mediante vía Web, correo
electrónico o SMS. Se ha provisto una interfaz Web gestión de envío de
calificaciones para los profesores, a la cual se accederá a través GSAIT.
6. Interfaz simple para el cambio de proveedor del servicio SMS. El
proveedor elegido con el que se enviarán los SMS condicionará el código
que se ha de implementar para hacer posible en envío. Para que el
impacto del cambio de proveedor sea el mínimo posible, se ha
desarrollado una interfaz genérica que ocultará la lógica propietaria de
envío de los SMS de cada proveedor.
3.1. Consulta vía Web de calificaciones y suscripci ón a
los distintos servicios.
La principal funcionalidad que se ha tratado de conseguir en este proyecto es ofrecer a
los alumnos unas serie de servicios relacionados con la información de sus
calificaciones a través de distintos medios. Estos medios, como se han comentado
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 52 Universidad de Sevilla
anteriormente, se corresponde con la publicación Web, mediante envío SMS y mediante
correo electrónico.
Para conseguir estas funcionalidades, se ha desarrollado una interfaz Web donde los
alumnos podrán ver sus calificaciones y donde podrán suscribirse a los servicios de
recepción de notas por correo electrónico o por SMS.
A continuación se muestra un esquema del flujo de pantallas que componen la interfaz
que agrupa estas dos funcionalidades.
Figura 12. Esquema del flujo de pantallas que componen la interfaz Web de suscripción
a los servicios
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 53 Universidad de Sevilla
Como se muestra en el diagrama, la interfaz Web para la suscripción a los distintos
servicios se compone de tres páginas JSP:
• Index.jsp – Pagina de entrada, en la que se solicita al alumno que teclee su DNI
y su clave de acceso. En principio la clave coincidirá con el DNI, pudiéndose
cambiar en paginas interiores.
Con respecto al DNI Pueden ser posibles las tres siguientes casuísticas: alumno
español que introduce el DNI sin la letra, alumno español que introduce el DNI
con la letra, y el caso de un alumno extranjero que introduce su número de
identificación personal.
Si el alumno introduce 9 caracteres, se asumirá que se trata de un alumno
español que ha introducido además de los dígitos, la letra. En este caso el
sistema comprobará que la letra introducida es valida, y posteriormente buscará
en base de datos si existe o no la pareja DNI-clave introducida.
Mediante código JavaScript se comprueba que el usuario de la aplicación no
deja ninguno de los campos en blanco, no permitiendo el avance hasta que los
campos sean completados.
A continuación se muestra una captura de esta página:
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 54 Universidad de Sevilla
Figura 13. Vista en el Explorer de la paginas index.jsp
• Principal.jsp – Pagina a la que se accede una vez pasado con éxito el proceso de
autenticación por parte del alumno. En esta página se pueden observar tres
partes diferenciadas: Actualización de datos personales, suscripción a los
distintos servicios, visualización Web de las notas ya publicadas
En esta página se pueden observar tres partes diferenciadas.
• Datos personales: En esta parte se muestra el nombre completo, DNI
del alumno, móvil (necesario para el envío SMS), correo electrónico
(necesario para el envío vía mail) así como un código de autenticidad
de mensajes, gracias al cual cuando al alumno le llegue un correo o
SMS con su calificación comprobará la autenticidad del mensaje si en
él se indica coincidentemente este código de autenticidad.
Inicialmente el móvil, correo electrónico y código de autenticidad
aparecerán en blanco. El alumno ha de introducir estos datos la
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 55 Universidad de Sevilla
primera vez que entre en la aplicación, teniendo la opción de
cambiarlos todas las veces que desee. Así mismo, existe un botón
para acceder a una página donde cambiar la clave de acceso.
Mediante código JavaScript se obliga que al insertar la primera vez
los datos personales o en las posteriores modificaciones se completen
los tres campos: codigo_autenticidad, móvil y dirección de correo
electrónico.
Así mismo se comprueba que el número de teléfono móvil está
compuesto por 9 cifras y además comienza por el digito “6”. En
cuanto a la dirección de correo electrónico, la única comprobación
realizada es que en su interior alberga el carácter”@”.
• Configuración de servicios: En esta parte se muestran las distintas
asignaturas en las que el alumno se encuentra matriculado. Para cada
una de ellas, el alumno tiene la opción de suscribirse al servicio de
envió SMS y/o de correo electrónico.
La suscripción a los servicios de correo electrónico y SMS a cobro
revertido, es independiente para cada una de las asignaturas. El
alumno tiene libertar para elegir para cada asignatura que servicios
desea y cuales no.
Para facilitar la suscripción en bloque en un servicio para todas las
asignaturas, se ha establecido un botón “Todas”, que mediante código
JavaScript selecciona todos los checkboxs correspondientes al
servicio para todas las asignaturas. Así mismo se ha establecido un
botón “Ninguna”, que me mediante código JavaScript deselecciona
todos los checkboxs correspondientes al servicio para todas las
asignaturas.
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 56 Universidad de Sevilla
Una vez elegidas las distintas suscripciones se ha de pulsar el botón
“Aplicar Cambios” para que los cambios se almacenen en base de
datos.
• Notas publicadas: En esta parte se listan los resultados de todos los
exámenes en los que ha participado el alumno, indicando la fecha,
hora y lugar de la revisión si las notas son provisionales. En caso de
ser definitivas, solo aparecerá la calificación definitiva junto con la
fecha en la que se realizó dicho examen.
A continuación se muestran diferentes capturas de esta página:
Figura 14. Vista en el Explorer de la pagina principal.jsp, centrada en parte de
configuración de datos personales y suscripción de servicios.
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 57 Universidad de Sevilla
Figura 15. Vista en el Explorer de la pagina principal.jsp, centrada en la parte de
configuración de servicios y en la parte de visualización de calificaciones.
• cambioClave.jsp – Pagina a la que se accede desde la pagina principal. En ella
se puede cambiar la clave de acceso a la interfaz de suscripción a los distintos
servicios.
Mediante código JavaScript, se comprueba que los tres campos (clave actual,
clave nueva, confirmación de la clave) se completan, y que la clave nueva y la
confirmación de la clave contengan el mismo valor. Solo en ese caso se ejecuta
la operación, cambiando la clave en el caso de que la clave actual introducida
coincidiera con la existente en base de datos.
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 58 Universidad de Sevilla
Figura 16. Vista en el Explorer de la pagina de cambio de clave.
3.2. Publicación de calificaciones.
Para que los alumnos puedan ver sus calificaciones a través de la interfaz Web así como
recibirlas ya sea mediante correo electrónico o mediante mensajes corto SMS, ha sido
necesario crear esta funcionalidad.
Gracias a ella, los profesores podrán fácilmente publicar las calificaciones en cualquier
de los tres formas ya comentadas.
A demás de elegir la modalidad de publicación (Web, SMS, Correo electrónico), se
puede seleccionar los alumnos a los que afectara dicha publicación. La publicación Web
afectará a todos los alumnos, mientras que en el resto de publicaciones se puede
distinguir entre:
• Enviar a todos los alumnos
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 59 Universidad de Sevilla
• Enviar solo a los alumnos suspensos
• Enviar solo a los alumnos cuya calificación sea aprobado (entre 5.0 y 6.9)
• Enviar solo a los alumnos cuya calificación sea notable (entre 7.0 y 8.9)
• Enviar solo a los alumnos cuya calificación sea Sobresaliente (entre 9.0 y 10)
• Enviar solo a los alumnos cuya calificación sea Matricula de honor (cuya nota
sea igual a 10 y se le haya otorgado esta distinción).
• Enviar a aquellos alumnos cuyas notas se encuentren comprendidas dentro de un
rango, que se fija manualmente.
Para implementar esta funcionalidad, se ha desarrollado dentro de SCAIT, una interfaz
Web a la que podrán acceder los profesores que hayan superado con éxito el proceso de
autenticación en GSAIT, que es el gestor de servidores del área.
A continuación se explica brevemente como funciona dicha Interfaz Web.
Figura 17. Vista en el Explorer de la interfaz de gestión de envió de calificaciones
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 60 Universidad de Sevilla
Aparecerán todos los exámenes corregidos que se encuentre ya incluidos en la base de
datos del sistema y que corresponda a asignaturas impartidas por el profesor que accede
a la página. Cada examen mostrará información de cuando se realizó, los datos de la
fecha de la revisión, si el examen ha sido revisado o no, y las distintas modalidades de
publicación que se han aplicado sobre él con anterioridad.
Para cada examen se ha de indicar la modalidad de publicación deseada. En el caso que
no se elija ningún examen a publicar en ninguna de las tres modalidades ofertadas, el
botón publicar no permitirá avanzar de pantalla y no invocará a ninguna operación.
La publicación de un examen puede afectar a distintos rangos de alumnos como ya se
indico anteriormente.
Tras presionar el botón “Publicar” , se lanza la operación contra el servidor,
generándose un informe por pantalla con los exámenes que se han publicado y en que
modalidad.
3.2.1. Envío de calificaciones por correo electróni co. Todo alumno suscrito al servicio de recepción de calificaciones mediante envío de un
correo electrónico, recibirá en su cuenta de correos cuando el profesor lo publique, los
resultados obtenidos en sus distintos exámenes.
Esta funcionalidad se ha conseguido haciendo uso de la API JAVA MAIL, como se
verá en mayor profundidad en apartado 4 de la presente memoria y gracias a la
instalación del servidor de correo electrónico SendMail que será el encargado final de
distribuir los correos a los alumnos.
El mensaje recibido por cada alumno tendrá el formato siguiente:
• Si el examen está por revisar
Servicio de información de calificaciones del Área de telemática Universidad de Sevilla. Asignatura: Arquitectura de Computadores Examen: Primer Parcial
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 61 Universidad de Sevilla
Fecha de realización: 2005-01-29 Fecha de la revisión: 2005-03-13 Hora de la revisión: 17:00 Lugar de la revisión: Aula 007 Nota: 8.3 Calificación: Notable Codigo de autenticidad: Pedrin
• Si el examen ya ha sido revisado
Servicio de información de calificaciones del Área de telemática Universidad de Sevilla. Asignatura: Arquitectura de Computadores Examen: Primer Parcial Fecha de realización: 2005-01-29 CALIFIACION DEFINITIVA Nota: 8.3 Calificación: Notable Codigo de autenticidad: Pedrin
3.2.2. Envío de calificaciones por SMS. Todo alumno suscrito al servicio de recepción de calificaciones mediante envío de
SMS, recibirá en su móvil cuando el profesor lo publique, los resultados obtenidos en
sus distintos exámenes.El mensaje recibido tendrá el formato siguiente:
• Si el examen está por revisar
SCAIT, Arquitectura de Computadores (Primer Parcial ): 8.3,Revision: 13-03; Aula 007 (17:00) - Pedrin
• Si el examen ya ha sido revisado
SCAIT, Arquitectura de Computadores (Primer Parcial ): 8.3,DEFINITIVO - Pedrin
Para conseguir implementar esta funcionalidad en el presente proyecto, ha contactado
con distintas empresas para estudiar cómo tendría que realizarse el envío de la
información de calificaciones y bajo qué formato, para que llegaran en forma de SMS al
alumno destinatario.
El proveedor de servicio elegido, condicionará la forma final de envío, ya que, cada
proveedor requiere que los datos sean enviados con un formato, protocolo, específico.
Para evitar el impacto que supondría cambiar de proveedor, se ha desarrollando una
SCAIT 3. Funcionalidades del proyecto
Proyecto Fin de Carrera 62 Universidad de Sevilla
interfaz genérica de envío que trata ocultar el código final propietario de envío SMS de
cada proveedor. En el apartado 4 de la memoria se hablará mas a fondo de cómo
funciona esta interfaz genérica.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 63 Universidad de Sevilla
4. Descripción detallada del código
Una vez expuesta las funcionalidades contempladas en el proyecto, en este apartado se
mostrará como se ha llegado a ellas. Se expondrán y detallarán las distintas partes que
componen la solución adoptada para alcanzar las distintas funcionalidades. La
descripción del código se ha agrupado según las distintas funcionalidades que realizan:
• Base de datos relacional. Para el almacenamiento de los datos necesarios
para el funcionamiento de SCAIT.
• Beans de datos. Para el almacenamiento temporal de los datos necesarios
para la ejecución de la lógica de SCAIT.
• Lógica general de SCAIT: Lógica general que forma el núcleo de SCAIT.
• Servicio Mail: Para el envío de los correos electrónicos con las calificaciones
a los alumnos.
• Servicio SMS: Para el envío de los mensajes cortos SMS con las
calificaciones a los alumnos.
• Interfaces Web: Código Web que compone la capa de presentación de las
interfaces Web desarrolladas en el proyecto.
• Fichero de configuración de SCAIT: Fichero donde se guardan todos los
datos de configuración de SCAIT.
El código se encuentra disponible en el CD del Proyecto. Véase el apartado del Anexo
donde se expone el contenido del CD del Proyecto.
4.1. Base de datos relacional
Para el almacenamiento de los datos con los que va a tratar SCAIT se ha empleado la
base de datos relacional Postgres. En el anexo, se puede encontrar información de cómo
Postgres se ha instalado en el sistema.
El primer paso consistió en el estudio del modelo de datos necesario para el
funcionamiento de SCAIT. Como conclusión del estudio se obtuvo un modelo
compuesto por cuatro entidades y tres relaciones entre ellas:
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 64 Universidad de Sevilla
• Alumno: Entidad que modela los alumnos que usaran SCAIT. Contiene los
siguientes datos:
Nombre del campo Descripción
DNI DNI del alumno
Nombre Nombre del alumno
Apellido1 Primer apellido del alumno
Apellido2 Segundo apellido del alumno
Email Dirección de correo electrónico a la cual se enviaran
los correos con las calificaciones en caso de que el
alumno este suscrito al servicio de envió de correo
electrónicos.
Movil Numero de teléfono móvil al cual se enviaran los
SMS con las calificaciones en caso de que el alumno
este suscrito al servicio de envió de SMS.
Clave Clave necesario para poder acceder a la interfaz
Web de suscripción de servicios.
Codigo_autenticidad Código que el alumno configurará y que será
enviado junto con las calificaciones en los correos y
SMS, para evitar engaños por parte de terceros
suplantando la identidad de SCAIT.
Las sentencias SQL necesarias para generar esta tabla se muestra a continuación:
-- ********************** TABLA ALUMNO ************ *********************** CREATE TABLE alumno ( dni varchar(9) NOT NULL, nombre varchar(20), apellido1 varchar(20), apellido2 varchar(20), email varchar(30), clave varchar(20), codigo_autenticidad varchar(20), movil varchar(9), CONSTRAINT pk_dni PRIMARY KEY (dni) ) ;
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 65 Universidad de Sevilla
• Asignatura: Entidad que modela las asignaturas que estarán integradas dentro
de los servicios de SCAIT. Contiene los siguientes datos:
Nombre del campo Descripción
Id_asignatura Identificador interno para el tratamiento de la
asignatura
Nombre Nombre de la asignatura
Curso Curso en el que se imparte la asignatura
Area Área que imparte dicha asignatura
Tipo Tipo de asignatura de la que se trata: Cuatrimestral,
anual,…
Las sentencias SQL necesarias para generar esta tabla se muestra a continuación:
-- ******************** TABLA ASIGNATURA ********** *********************** CREATE TABLE asignatura ( id_asignatura numeric(10) NOT NULL, nombre varchar(40), curso varchar(40), area varchar(40), tipo varchar(40), CONSTRAINT asignatura_pkey PRIMARY KEY (id_asigna tura) ) ;
• Examen: Entidad que modela los exámenes de las asignaturas que estarán
integradas dentro de los servicios de SCAIT. Contiene los siguientes datos:
Nombre del campo Descripción
Id_examen Identificador interno para el tratamiento de los
exámenes.
Id_asignatura Identificador de la asignatura a la que pertenece
dicho examen.
Nombre_asignatura Nombre de la asignatura de la que forma parte el
examen.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 66 Universidad de Sevilla
Nombre del campo Descripción
Tipo_examen Si se trata de un examen parcial, final,…: Primer
Parcial, Segundo Parcial, Final Febrero,…
Curso Curso al que pertenece el examen
Fecha_realizacion Fecha de realización del examen
Fecha_revision Fecha en la que tendrá lugar la revisión del examen
Hora_revision Hora a la que tendrá lugar la revisión del examen
Revisado Valor booleano que indica si el examen ha sido
revisado ya o no.
Publicado_web Valor booleano que indica si el examen ha sido
publicado (vía Web) ya o no.
publicado_sms Valor booleano que indica si el examen ha sido
publicado (vía SMS) ya o no.
publicado_mail Valor booleano que indica si el examen ha sido
publicado (vía correo electrónico) ya o no.
Las sentencias SQL necesarias para generar esta tabla se muestra a continuación:
-- ********************* TABLA EXAMEN ************* ******************* CREATE TABLE examen ( id_examen numeric(10) NOT NULL, id_asignatura numeric NOT NULL, tipo_examen varchar, hora_revision varchar, lugar_revision varchar, nombre_asignatura varchar(20), fecha_realizacion timestamp, fecha_revision timestamp, revisado bool, curso numeric, publicado_web bool, curso numeric, publicado_sms bool, publicado_mail bool, CONSTRAINT examen_pkey PRIMARY KEY (id_examen), CONSTRAINT id_asignatura_fkey FOREIGN KEY (id_asi gnatura) REFERENCES asignatura (id_asignatura) ON UPDATE RESTRICT ON DE LETE RESTRICT ) ;
• Usuario: Entidad que modela los usuario de GSAIT. A SCAIT solo le
interesaran los usuarios que tengan el rol de profesor. Contiene los siguientes
datos:
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 67 Universidad de Sevilla
Nombre del campo Descripción
Idusuario Identificador interno para el tratamiento de los
usuarios.
Nombre Nombre del usuario.
Clave Clave para la autenticación del usuario dentro del
Sistema GSAIT.
Las sentencias SQL necesarias para generar esta tabla se muestra a continuación:
-- ****************** TABLA USUARIO *************** ********************** CREATE TABLE usuario ( idusuario INTEGER default nextval('seq_usuario') not null primary key, nombre VARCHAR(50), clave VARCHAR(200) );
• Alumno_Asignatura: Relación entre las entidades alumno y asignatura. Por
cada asignatura en la que este matriculado el alumno, se creará una entrada en
esta relación. La relación es N:N, ya que un usuario puede estar matriculado en
N asignaturas y una asignatura puede tener matriculados a N alumnos. Contiene
los siguiente datos:
Nombre del campo Descripción
Servicio_sms Valor booleano que indicará para cada asignatura en
la que esté matriculado un alumno en particular, si el
alumno desea estar suscrito en el servicio de envío
de SMS.
Servicio_email Valor booleano que indicará para cada asignatura en
la que esté matriculado un alumno en particular, si el
alumno desea estar suscrito en el servicio de envío
de correo electrónico.
Las sentencias SQL necesarias para generar esta tabla se muestra a continuación:
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 68 Universidad de Sevilla
-- ***************** TABLA ALUMNO_ASIGNATURA ****** ********************* CREATE TABLE alumno_asignatura ( id_asignatura numeric NOT NULL, id_alumno_asignatura numeric NOT NULL, dni varchar(9) NOT NULL, servicio_sms bool, servicio_email bool, CONSTRAINT pk_id_alumno_asingatura PRIMARY KEY (i d_alumno_asignatura), CONSTRAINT fk_dni FOREIGN KEY (dni) REFERENCES al umno (dni) ON UPDATE RESTRICT ON DELETE RESTRICT );
• Alumno_examen: Relación entre las entidades alumno y examen. Por cada
examen en el que participe el alumno, se creará una entrada en esta relación. La
relación es N:N, ya que un alumno puede realizar N exámenes y un examen
puede ser realizado por N alumnos Contiene los siguiente datos:
Nombre del campo Descripción
Nota Valor numérico de la calificación del examen.
Calificación Calificación del examen: suspenso, aprobado,
notable, sobresaliente o matricula de honor.
Las sentencias SQL necesarias para generar esta tabla se muestra a continuación:
-- ********************* TABLA ALUMNO_EXAMEN ****** ******************** CREATE TABLE alumno_examen ( id_alumno numeric(10) NOT NULL, id_examen numeric(10) NOT NULL, id_alumno_examen numeric NOT NULL, nota_provisional numeric, nota_definitiva numeric, calificacion varchar(10), dni varchar(20) NOT NULL, nota numeric, CONSTRAINT alumno_examen_pkey PRIMARY KEY (id_alu mno_examen), CONSTRAINT alumno_examen_idexamen_fkey FOREIGN KE Y (id_examen) REFERENCES examen (id_examen) ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT fk_dni FOREIGN KEY (dni) REFERENCES al umno (dni) ON UPDATE RESTRICT ON DELETE RESTRICT ) ;
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 69 Universidad de Sevilla
• Relacion_usuario_asignatura: Relación entre las entidades usuario y
asignatura. Contendrá para cada usuario (profesor), las asignaturas que imparte.
La relación es N:N, ya que un usuario (profesor) puede impartir N asignaturas y
una asignatura puede estar impartida por N usuarios (profesores)
Las sentencias SQL necesarias para generar esta tabla se muestra a continuación:
-- *********** TABLA RELACION_USUARIO_ASIGNATURA ** *********************** -- Relacion usuario - asignatura -- (Para usuarios con rol profesor, se interpreta -- como la relacion entre los profesores y las asig naturas -- que imparten) CREATE TABLE relacion_usuario_asignatura ( idusuario INTEGER references usuario(idusuario), idasignatura INTEGER REFERENCES asignatura(id_asi gnatura) );
En la siguiente figura, se resume gráficamente el modelo Entidad-Relación de SCAIT.
Figura 18. Modelo Entidad-Relación de SCAIT
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 70 Universidad de Sevilla
NOTA: El fichero de generación de la base de datos completa usada conjuntamente por
SCAIT y GSAIT, se proporciona en el CD del proyecto dentro del directorio Scripts
Base de Datos.
4.2. Beans de datos
Los beans de datos de SCAIT son las clases de datos necesarias para la ejecución de la
lógica de SCAIT. Todos ellos se agrupan dentro del paquete Beans. En la siguiente
tabla se resumen todos los beans que se han creado indicando para que han sido
empleados.
Beans de Datos
Nombre Descripción
Alumno Contiene la información del alumno. Sus atributos se
corresponden con los de la tabla Alumno.
AlumnoAsignatura Representa la relación entre las asignaturas y los alumnos
matriculados en ellas. Sus atributos se corresponden con los de
la tabla AlumnoAsignatura.
AlumnoExamen Representa la relación entre un examen y la nota de cada uno de
los alumnos que realizaron dicho examen. Sus atributos se
corresponden con los de la tabla AlumnoExamen.
Asignatura Contiene información de cada una de las asignaturas que
disponen de estos servicios. Sus atributos se corresponden con
los de la tabla asignatura.
CambioClave Clase usada para almacenar los datos necesarios para realizar el
proceso de cambio de clave de un alumno.
Criterios Clase usada para almacenar los criterios de selección de los
alumnos a los que se les enviará información de sus
calificaciones por correo o por SMS. Criterios: Rango de notas.
DatosExamen Clase usada para almacenar todos los datos necesarios por cada
alumno y por cada examen para construir los mensajes de
correo y los mensajes SMS.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 71 Universidad de Sevilla
Examen Clase usada para almacenar los datos generales de un examen.
Sus atributos se corresponden con los de la tabla Examen.
ExamenCorregido Clase usada para almacenar los datos recuperados de base de
datos con la información de los exámenes que hasta la fecha
actual hayan sido corregidos
GestionNotas Clase usada para la gestión de las notas que se van a publicar.
4.3. Lógica general de SCAIT
El código que compone el núcleo del servidor SCAIT se encuentra repartido en tres
paquetes dentro del código fuente, que son los siguientes:
• Paquete Scait: Concentra la mayor parte de las operaciones de SCAIT, como son
el acceso a las tablas de la base de datos, el tratamiento de dicha información
para obtener los resultado necesarios y que serán devueltos a las etiquetas
(taglibs) a las que se invoca desde el código JSP.
• Paquete tags: Paquete donde se encuentra el código de cada una de las etiquetas
(taglibs) que se han creado para lograr las funcionalidades requeridas.
• Paquete utilidades: Aquí se agrupan una serie de funcionalidades que será
usadas en otras partes de la aplicación, como pudieran ser el caso de
almacenamiento de constantes, generación de mensajes de aviso en las páginas
Web mediante código JavaScript,…
En los siguientes apartados se expondrán mas a fondo el contenido de cada uno de los
paquetes citados en este punto.
4.3.1. Paquete Scait En este paquete se concentra la mayoría de la lógica de SCAIT. Dicha lógica se ha
subdivido en dos niveles representados por dos clases:
• OperacionesLogicas: Esta clase contiene los métodos que serán invocados
directamente desde las etiquetas JSP. En ellos se concentra la mayor parte de las
operaciones lógicas necesarias para el funcionamiento SCAIT. A continuación
se muestra una tabla indicando los métodos contenidos en esta clase:
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 72 Universidad de Sevilla
OperacionesLogicas
Nombre Descripción
comprobarIdentidad Método de comprobación de la identidad del usuario.
seleccionAlumno Método de selección de alumno. Selecciona los datos
personales configurables de un alumno (código de
autenticidad, móvil, correo electrónico).
modificarDatosAlumno Método de modificación de los datos de un alumno.
Actualiza los datos personales configurables de un
alumno (código de autenticidad, móvil, correo
electrónico).
seleccionAsignaturas Método de selección de las asignaturas en las que está
matriculado un alumno.
cambiarClave Método lógico para realizar el cambio de clave.
actualizarSuscripciones Método para la actualización de las suscripciones a los
distintos servicios de envío de calificación.
obtenerNotasExamen Obtiene la colección de Datos examen con todos los
datos necesarios para informar, a los alumnos que
cumplan los criterios indicados, de sus calificaciones.
enviarNotasCorreo Función que realiza a nivel lógico el envío de correos
con las calificaciones.
enviarNotasSMS Función que realiza a nivel lógico el envío de SMS con
las calificaciones.
obtenerTodosExamenes Obtiene para un alumno todos los exámenes a los que ha
asistido y cuyas notas han sido publicadas.
obtenerProfile Método que lee el fichero de configuración con los datos
y los mapea en el bean correspondiente.
obtenerExamenesCorregidos Obtiene los distintos exámenes ya corregidos impartidos
por el profesor que se pasa como parámetro.
publicarNotas Función a la que se invoca desde le etiqueta de Gestión
de notas.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 73 Universidad de Sevilla
• Operaciones BD: Esta clase contiene los métodos a los que se invoca para
acceder directamente a la base da datos. Aquí se concentran todas las
operaciones de Selección y actualización de datos en la base de datos.
OperacionesBD
Nombre Descripción
selectAlumno Método que realiza una selección de los datos de la
tabla Alumno.
updateAlumno Método para realizar actualizaciones de datos en la
tabla alumno. Solo son actualizables:
codigoAutentificacion, móvil, correo electrónico y
clave.
updateAlumnoClave Método para el cambio en base de datos de la clave del
alumno.
selectAsignatura Realiza una selección de las asignaturas en las que está
matriculado un alumno identificado por su DNI. Así
mismo, obtiene de la tabla alumnoAsignatura los
servicios sobre dichas asignaturas a los que el alumno
se encuentra en este momento suscrito.
updateAlumnoAsingatura Actualiza las suscripciones a los distintos servicios
sobre las asignaturas en las que un alumno se encuentra
matriculado.
selectDatosExamen Obtiene una colección de DatosExamen con los datos
necesarios para informar a los alumnos que cumplan
con los criterios, sus calificaciones.
selectTodosExamenes Selecciona todos los exámenes en los que ha
participado un alumno.
selectExamenesCorregidos Selecciona los exámenes ya corregidos pertenecientes
a las distintas asignaturas que un profesor imparte
actualmente.
UpdateExamenPublicarWeb Establece como publicado en Web los exámenes que se
le pasan como parámetro dentro del bean
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 74 Universidad de Sevilla
OperacionesBD
Nombre Descripción
GestionNotas.
UpdateExamenPublicarSMS Establece como publicado vía SMS los exámenes que
se le pasan como parámetro dentro del bean
GestionNotas
UpdateExamenPublicarCorreo Establece como publicado vía correo electrónico los
exámenes que se le pasan como parámetro dentro del
bean GestionNotas.
Para la construcción del esqueleto de las sentencias SQL, se ha creado una clase en este
paquete denominada SQLOperacionesBD. Esta clase esta compuesta exclusivamente
por cadenas estáticas y públicas con los esqueletos de las sentencias SQL, que serán
referenciadas desde la clase Operaciones BD.
Así mismo, en este paquete se incluye la clase ObtenerConfiguracion, necesaria para la
lectura de los datos de configuración de SCAIT desde el fichero de configuración del
servidor.
4.3.2. Paquete Tags
4.3.2.1. Introducción
En este apartado se describen cada unas de las etiquetas creadas en el proyecto y que
serán invocadas desde las distintas paginas JSP.
La totalidad de las etiquetas creadas en este proyecto, son etiquetas sin cuerpo y sin
atributos. Desde el código JSP se invoca cada etiqueta usando la marca de apertura e
inmediatamente después, la marca de cierre.
En cuanto al código Java que implementa cada una de las etiquetas se puede comentar
lo siguiente:
• Todas las clases que forman la etiqueta extienden a la clase BodyTagSupport
• Al tratarse de etiquetas sin parámetros, no contendrán métodos Get y Set.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 75 Universidad de Sevilla
• Solo se han implementado de manera obligatoria en todas las etiquetas los
siguientes métodos:
o doStartTag: Método que se invoca cuando se encuentra la marca que
indica la presencia de la etiqueta en la página JSP. En este método es
donde se concentra toda la lógica de la etiqueta.
o doEndTag: Método que se invoca cuando se encuentra la marca de cierre
de la etiqueta. Simplemente, se indica que se siga evaluando la página
JSP.
o Release: Método para la liberación de recursos.
• Los datos necesarios para la evaluación de la etiqueta, se suelen recoger del
contexto, o bien del objeto request de la session, dado que la mayoría de
etiquetas se invocan siempre al cargarse la pagina JSP, evaluando únicamente
aquellas que recojan y no sean nulos, los datos que necesitan para ejecutarse.
• Es el método doStartTag donde se obtiene la conexión con la base de datos a
través del driver correspondiente. La conexión con la base de datos, se encapsula
dentro de un método que se encuentra alojado en la clase Utilidades, que será
comentada posteriormente.
4.3.2.2. Etiquetas creadas en el proyecto
Etiquetas (Taglibs)
Nombre Descripción
ActualizarSuscripcionesTag Realiza la actualización de las suscripciones a los
distintos servicios para cada una de las asignaturas en
las que esta matriculado el alumno.
CambiarClaveTag Etiqueta que realiza la modificación de la clave de
acceso del alumno.
CompruebaIdentidadTag Etiqueta que comprueba si en base da datos existe la
pareja DNI y CLAVE que recoge del contexto de la
pagina JSP en la que se invoca la etiqueta.
GestionNotasTag Etiqueta para el envío de los correos a los alumnos.
IsAutenticadoTag Comprueba si se ha accedido a la página, desde donde
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 76 Universidad de Sevilla
Etiquetas (Taglibs)
Nombre Descripción
se llama a esta etiqueta habiendo pasado con éxito por
el proceso de autenticación.
ModificarDatosAlumnoTag Etiqueta que modifica los datos configurables de un
alumno, seleccionándolo mediante su DNI.
MostrarNotasTag Etiqueta que muestra en la Web las notas publicadas
hasta ahora para el alumno en cuestión.
SeleccionAlumnoTag Etiqueta que obtiene los datos de un alumno,
seleccionándolo mediante su DNI.
SeleccionAsignaturasTag Etiqueta que crea la tabla de asignaturas con la
posibilidad de seleccionar los distintos servicios
CerrarSessionTag Cierra la sesión actual. Tras la ejecución de esta
etiqueta, para poder acceder a la página principal de la
interfaz del alumno, se ha de superar nuevamente con
éxito el proceso de autenticación.
4.3.3. Paquete Utilidades
Dentro de este paquete, se ha agrupado dos clases que servirán de utilidades para las
demás partes de la página. Una de las utilidades mas destacadas es la creación de
ventanas de avisos mediante escritura en el flujo JSP de código JavaScript que generará
ventanas de alerta con los mensajes que se le pasen como parámetro. Los mensajes que
se podrán mostrar en las ventanas de alerta de la aplicación, se encuentran almacenados
como variables públicas estáticas en la clase Constantes, alojada en este mismo paquete.
En la clase utilidades se encuentran agrupados los siguientes métodos:
Funciones
Nombre Descripción
PopupWindow Método para la creación mediante lenguaje JavaScript de
pantallas de aviso en la aplicación.
stringToDate Convierte una cadena en formato fecha a un objeto Date.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 77 Universidad de Sevilla
Funciones
Nombre Descripción
obtenerConexion Obtiene una conexión con la base de datos.
comprobarValidezLetraDNI Comprueba si la letra del DNI español introducida es
correcta.
obtenerLetraDNI Obtiene la letra del DNI introducida por el usuario a
partir de la cadena completa del DNI.
isDNIExtranjero Indica si un DNI es extranjero o no.
isNumeric Comprueba si una cadena esta formada únicamente por
caracteres numéricos o no.
4.4. Servicio de correo electrónico
Para ofrecer este servicio se ha hecho uso de la API JavaMail a la que se ha hecho
referencia de forma general en el apartado segundo de esta memoria. En este apartado
se explicará la implementación concreta que se ha desarrollado para ofrecer este
servicio.
Para separar esta funcionalidad del resto del código propio de SCAIT, se ha creado el
paquete ServicioMail. En su interior se han recogido dos clases:
• ServicioMail: Clase que encapsula todos los métodos implementados para el
tratamiento y envío de correos electrónicos.
Métodos
Nombre Descripción
crearMensaje Crea el cuerpo del mensaje que se va a enviar al
alumno.
crearAsuntoMensaje Crea el asunto del mensaje que se va a enviar al
alumno.
enviarCorreos Realiza el envío de los mensajes de calificaciones.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 78 Universidad de Sevilla
• MyAuthenticator: Clase que extiende a la clase Authenticator, necesaria para el
envío de correo electrónico bajo autentificación con el servidor de correos
electrónico.
A continuación se expone el fragmento de código que realiza el envío de cada uno de
los correos electrónicos.
private static void envioMensaje(DatosExamen prmDat osExamen,Profile prmProfile) { Logger log = Logger.getLogger(ServicioMail.class ); String from = "AreaIngenieriaTelematica@Universi dadSevilla.es "; String to = prmDatosExamen.getEmail(); try { // Se definen los parametros de Session Properties props = new Properties(); props.put("mail.transport.protocol",prmProfile .getProtocoloCorreo()); props.put("mail.smtp.host", prmProfile.getHostCorreo()); props.put("mail.smtp.port", prmProfile.getPuer toCorreo()); props.put("mail.smtp.auth", prmProfile.getAutenticacionCorreo()); // Se crea el objeto Authenticator Authenticator auth = new MyAuthenticator(); Session session = Session.getDefaultInstance(p rops,auth); // Se crea el MimeMessage MimeMessage message = new MimeMessage(session) ; // Se establece la direccion de destino message.setFrom(new InternetAddress(from)); // Se establece la direccion origen message.addRecipient(Message.RecipientType.TO, new InternetAddress(to)); // Se estable el asunto del mensaje String asunto = crearAsuntoMensaje(prmDatosExa men); message.setSubject(asunto); // Se establece el cuerpo del mensaje String mensaje = crearMensaje(prmDatosExamen); message.setText(mensaje); // Se envia el mensaje Transport.send(message); }catch(Exception ex){ log.error("SCAIT | SevicioMail | envioMensaje: " + ex.getMessage() ); }
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 79 Universidad de Sevilla
4.5. Servicio SMS
Todo el código necesario para la implementación de este servicio se ha agrupado bajo el
paquete ServicioSMS. Como se ha comentado, la puesta en marcha de este servicio
requiere el contratar con alguna empresa el servicio de envío de SMS a través de la
conexión desde un PC. Por tanto, la implementación final de esta funcionalidad,
dependerá de la empresa con la que se contrate el servicio. Sin embargo, se ha buscado
que el cambio de proveedor no suponga un gran impacto en SCAIT.
4.5.1. Paquete ServicioSMS. Dentro del paquete principal de envío SMS llamado ServicioSMS, existen dos clases:
• ServicioSMS: Esta clase contiene los métodos necesarios para el tratamiento de
la información que llega desde los métodos invocados por la etiqueta de
publicación de exámenes.
• ClaseGenericaEnvioSMS: Clase abstracta que necesaria para el mecanismo de
selección dinámica de clase en tiempo de ejecución a través de la ruta de la clase
que se ha de invocar leída desde el fichero de configuración.
4.5.1.1. Clase ServicioSMS.
Como se ha mencionado anteriormente, esta clase contiene los métodos necesarios para
el tratamiento de la información que llega desde los métodos invocados por la etiqueta
de publicación de exámenes.
A continuación se muestran en una tabla los distintos métodos contenidos en ella:
Métodos de la clase ServicioSMS
Nombre Descripción
tratarPeticionEnvioSMS A partir de la información de las calificaciones de todos
los alumnos que están suscritos al servicio, se construye el
cuerpo del mensaje SMS particular para cada uno de los
alumnos y se invoca la operación de envío de SMS.
crearMensaje Método que crea el cuerpo del mensaje SMS para cada
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 80 Universidad de Sevilla
Métodos de la clase ServicioSMS
Nombre Descripción
alumno.
envioMensajeSMS Método que realiza la invocación a la función de envío
SMS particular del proveedor con el que se tenga
contratado el servicio. Esta invocación será dinámica es
decir, la clase propietaria del proveedor a la que se
invocará desde aquí, es leída del fichero de configuración
del servidor.
A continuación de expone el código correspondiente al método envioMensajeSMS para
explicar un poco más a fondo su funcionamiento:
private static void envioMensajeSMS(String prmMensa je,String prmMovil,Profile prmProfile) { Logger log = Logger.getLogger(ServicioSMS.class); try{ // Se obtiene la clase desde la que se ha de inv ocar al metodo de envio de // SMS Class clase = Class.forName(prmProfile.getPlata formaEnvioSMS()); ClaseGenericaEnvioSMS envioSMS=(ClaseGenericaEnv ioSMS) clase.newInstance(); // Se realiza en el envio SMS envioSMS.enviar(prmMensaje,prmMovil); }catch(Exception ex){ log.error("SCAIT | SevicioSMS | envioMensajeSMS : " +ex.getMessage()); } }
Comentarios
• Se obtiene una referencia a la clase que especifica dentro del objeto profile que
recordemos se obtenía de la lectura del fichero de configuración.
• Se crea una nueva instancia de la clase obtenida. Para ello y debido que en
tiempo de compilación no se tiene constancia de cual será esa clase, se utiliza
una clase abstracta que tendrá que ser implementada por cada una de las clases
que contengan la tecnología de envío propietaria de cada uno de los distintos
proveedores.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 81 Universidad de Sevilla
4.5.1.2. Clase ClaseGenericaEnvioSMS.
Como se ha mencionado anteriormente, es una clase abstracta necesaria para el
mecanismo de selección dinámica de la clase final en tiempo de ejecución, a partir de la
lectura del fichero de configuración.
A continuación se muestra su definición:
public abstract class ClaseGenericaEnvioSMS { public abstract void enviar(String pMensaje,String pMovil); }
Comentarios
• Es una clase abstracta con un método abstracto que debe se implementado
por las clases que la extiendan. Dentro del método enviar de cada clase que
extienda a ClaseGenericaEnvioSMS se recogerá toda la lógica especifica
necesaria para el envío SMS a través del proveedor en cuestión.
4.5.2. Paquetes con la lógica de cada proveedor.
En este apartado se expondrá la estructura que se ha de seguir para la inserción del
código necesario para efectuar en el envío de SMS a través de un proveedor específico.
Por cada proveedor de envío se ha de crear un paquete denominado
servicioSMS.NombreProveedor y en su interior una clase denominada EnvioSMS que
extenderá a la clase abstracta ClaseGenericaEnvioSMS.
La clase EnvioSMS tendrá que implementar el método enviar que tiene como
parámetros el texto del SMS y el móvil al que se desea enviar. En su interior residirá el
código específico requerido por cada proveedor para el envío de los SMS.
En el siguiente apartado se expondrán las dos soluciones 3 de envío SMS recogidas en el
proyecto. Una de ellas es usando como proveedor de envío a Vodafone y otra usando el
servicio Premiun MT proporcionado por la empresa mediafusion.
3 En el Anexo se expone el estudio realizado de los distintos proveedores de envío SMS.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 82 Universidad de Sevilla
4.5.2.1. Solución de envío de SMS proporcionada por Vodafone.
Dentro de todas las posibles opciones que proporciona Vodafone para el envío SMS
desde una aplicación Web hacia un usuario móvil final, se he incluido en el proyecto el
servicio Plug InRed.
Servicio Plug InRed
Es un Software que instalado en un ordenador, permite a cualquier cliente de contrato
de Vodafone Empresas acceder a toda una gama de servicios de mensajería y
localización para dotar de movilidad a sus procesos de negocio.
Figura 19. Solución de envío SMS proporcionada por Vodafone.
Este software será el encargado de comunicar las diferentes aplicaciones residentes en el
ordenador, ya sean las desarrolladas por Vodafone, como aquellas desarrolladas por
terceros o por el propio cliente, permitiendo así el acceso total a la movilidad de datos.
Para adoptar esta solución, un cliente tiene que:
• Instalar en su ordenador el Plug InRed de Vodafone. Se trata de una API
Java para la conexión y envío de SMS.
• Activar la conexión en Vodafone, en ese momento se le asignará un número
móvil.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 83 Universidad de Sevilla
• Instalar tantas aplicaciones compatibles con el Plug InRed de Vodafone
como se desee.
En el anexo, se hablará sobre las distintas clases de la API proporcionada por Vodafone
necesarias para el envío SMS, así como la forma de contratar dicho servicio.
A continuación se expondrá el código contenido en la clase EnviarSMS escrito para
enviar los SMS a través del proveedor de servicios Vodafone y a través de su solución
Plug InRed. Lo único que interesa hacer notar al lector mostrando el código es que
observe que el código propietario va encapsulado dentro de la función Enviar, cuya
interfaz hacia el exterior es genérica.
// Paquete al que pertenece el fichero package servicioSMS.vodafone; import servicioSMS.ClaseGenericaEnvioSMS; // Importaciones especificas de la API de Vodafone import vodafone.connector.exception.*; import vodafone.connector.managers.*; import vodafone.connector.structs.*; /** * Clase que encapsula la tecnologia propietaria de Vodafone para el envio de SMS */ public class EnvioSMS extends ClaseGenericaEnvioSMS { // Parametros de configuracion necesarios para e l envio de SMS private static final String username="600000000" ; private static final String password="password"; private static final String appId="123456789"; private static final String appName="AplicacionC urso"; private static final String appWord="CUR"; public void enviar(String pMensaje,String pMovil ) { boolean validate = false; // Validación del usuario Plug InRed try { LoginManager loginMng = new LoginManager(); loginMng.login(username, password,appId, appName,a ppWord); validate = true; } catch (LoginException le) { System.out.println("Error de validación : " + le.g etMessage()); } catch (VodafoneException ve) { System.out.println("Error inesperado : " + ve.getM essage()); } if (validate) { SMS sms = new SMS();
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 84 Universidad de Sevilla
// Se establece el numero de teléfono destino sms.setDestAddress(pMovil); // Se establece el cuerpo del Mensaje SMS sms.setMessageBody(pMensaje); //Tipo de SMS : emergente o no emergente sms.setDataCodingScheme(SMS.DATA_CODING_SCHEME_EME RGENT); //Prioridad de envío del SMS sms.setPriorityFlag(SMS.PRIORITY_MEDIUM); SMSManager manager = new SMSManager(); try { System.out.println("Enviando SMS...."); manager.submit(sms); System.out.println("SMS enviado correctamente") ; } catch (SubmitException se) { System.out.println("Error en el envío del SMS : " + se.getMessage()); } catch (VodafoneException ve) { System.out.println("Error inesperado : " + ve.g etMessage()); } } } }
4.5.2.2. Solución de envío de alertas SMS proporcio nada por Mediafusión.
Se trata de un servicio Premium MT, o comúnmente conocido como “alertas”, donde el
coste de los mensajes es asumido por el destinatario en el mismo instante de la
recepción del mensaje.
Mediafusión ofrece la posibilidad de enviar estas alertas a través de protocolo estándar
HTTP. Las alertas con destino a terminales móviles (MT) serán entregados a la pasarela
de Mediafusión por las aplicaciones del cliente, asimismo la pasarela Mediafusión
entregará al cliente las notificaciones de altas y bajas de suscripciones que se produzcan,
todo ello vía TCP/IP y protocolo HTTP.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 85 Universidad de Sevilla
Figura 20. Solución de envío SMS mediante el servicio Premium MT de Mediafusion
En cuanto a la seguridad de la comunicación, las transmisiones entre Mediafusión y el
cliente sean seguras (encriptadas), la pasarela será accesible sobre SSL para aquellos
clientes que así lo deseen.
En el anexo, se hablará sobre el formato de las peticiones HTTP necesario para el envío
de las alertas a los terminales móviles.
4.6. Interfaces Web Las distintas interfaces Web que se ha desarrollado en el proyecto, se han realizado
usando la tecnología JSP y dentro de ella el uso de las etiquetas (taglibs) como se ha
comentado ya a lo largo de esta memoria. Sin embargo, también de ha recurrido a
ficheros exclusivamente con código HTML y un fichero con código JavaScript.
A continuación se muestra un cuadro resumen con todos los ficheros que componen las
interfaces Web y con la función que realizan cada uno de ellos.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 86 Universidad de Sevilla
Ficheros que componen la interfaz Web
Nombre Función
Index.jsp Pagina de autenticación para acceder a la interfaz Web de
suscripción a los distintos servicios y consulta de las
calificaciones.
Principal.jsp Pagina principal de la interfaz Web de suscripción a los
distintos servicios y consulta de las calificaciones.
CambioClave.jsp Pagina a la que se accede desde principal.jsp donde el
alumno podrá cambiar su clave.
publicarExamenes.jsp Pagina a la que se accede desde GSAIT y desde la que los
profesores pueden publicar los exámenes.
Comprobaciones.html Fichero en el que se agrupan todas las comprobaciones
JavaScript de las dos interfaces Web que componen el
proyecto. Dichas funciones son:
• cheqFLogin -- Comprueba que en la pagina inicial
(index.jsp), se indique obligatoriamente el DNI y
la clave de acceso. Si el alumno no completa
dichos campos se muestra un mensaje de aviso y
no deja que se procese el formulario.
• cheqDatosAlumno -- Realiza en la página
principal (principal.jsp) a la hora de modificar los
datos personales del alumno las siguientes
comprobaciones: 1.Los tres campos (móvil,
teléfono, código de autenticidad) han de ser
completados; 2.El móvil es un número de 9 cifras
y que comienza obligatoriamente por 6; 3.La
dirección de correo electrónico tiene la estructura
normal de una dirección de este tipo.
• cheqCambioClave -- Realiza en la pagina de
cambio de clave (CambioClave.jsp) las siguientes
comprobaciones: 1. Todos los campos son
completados, 2. La nueva clave y la confirmación
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 87 Universidad de Sevilla
Ficheros que componen la interfaz Web
Nombre Función
de la nueva clave contiene valores idénticos
• selecTodoSMS -- Selecciona todas las casillas de
suscripción al servicio de recepción de notas
mediante SMS.
• selecNingunSMS -- Deselecciona todas las
casillas de suscripción al servicio de recepción de
notas mediante SMS.
• selecTodoEMAIL -- Selecciona todas las casillas
de suscripción al servicio de recepción de notas
mediante correo electrónico.
• selecNingunEMAIL -- Deselecciona todas las
casillas de suscripción al servicio de recepción de
notas mediante correo electrónico.
• comprobarGestionNotas -- Realiza en la pagina
publicación de exámenes (publicarExamenes.jsp)
las siguientes comprobaciones para continuar con
el flujo de publicación: 1. En el caso de que se
filtre por rango de notas, como criterio para enviar
o no notificación a los alumnos, se comprueba que
los límites son correctos en cuanto a formato y
consistencia del intervalo. 2. Ha sido seleccionado
al menos un examen y modalidad de publicación.
encabezadoAlumno.html Cabecera de página que se incluirá en todas las paginas
que compone la interfaz Web de los alumnos.
encabezadoProfesores.html Cabecera de página que se incluye en la interfaz Web del
profesor.
pieDePagina.html Pie que se incluirá en todas las interfaces Web que
componen el proyecto.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 88 Universidad de Sevilla
4.7. Fichero de configuración de SCAIT
Se denomina configuracion.xml. Se trata de un fichero XML bien formado, ya que
cumple las especificaciones del lenguaje con respecto a las reglas sintácticas, en le que
se exponen los parámetros configurables de SCAIT.
Fichero de configuración
Parámetro Descripción
urlInicio Dirección URL en la que se encuentra la pagina de inicio de la
interfaz de suscripción a los servicios e información vía Web
de calificaciones.
urlPrincipal Dirección URL a la que se ha de acceder en caso de pasar con
éxito el proceso de autenticación por parte del alumno.
driverBD Especificación del driver de la base de datos.
conexionBD Especificación de la conexión de la base de datos.
nombreBD Nombre de la base de datos a la que accede SCAIT.
usaurioBD Nombre de usuario de la base de datos.
claveBD Clave del usuario de la base de datos.
cuentaCorreo Cuenta de correo desde la que se realizará el envió de los
correos electrónicos.
claveCorreo Clave de la cuenta de correos desde la que se realiza en el
envió de los correos electrónicos.
protocoloCorreo Protocolo usado para el envío de correos electrónicos.
puertoCorreo Puerto usado para el envío de correos electrónicos.
autenticacionCorreo Variable que indica si se requiere de autentificación para el
envío de correos electrónicos.
claveEncriptacion Clave de encriptación usada para encriptar las claves de los
alumnos para almacenarlas en la base de datos
activoSMS Bandera que indica si el servicio SMS esta o no activo
platarfomaEnvioSMS Ruta de paquetes don de se encuentra la clase EnvioSMS que
se ha de utilizar para realizar el envío de los SMS.
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 89 Universidad de Sevilla
El fichero configuracion.xml inicial con el que se ha puesto en marcha SCAIT es el
siguiente:
<?xml version="1.0" encoding="iso-8859-1"?> <configuracionSCAIT> <urlInicio>index.jsp</urlInicio> <urlPrincipal>principal.jsp</urlPrincipal> <driverBD>org.postgresql.Driver</driverBD> <conexionBD>jdbc:postgresql:</conexionBD> <nombreBD>bd_scait-gsait</nombreBD> <usuarioBD>scait-gsait</usuarioBD> <claveBD>*******</claveBD> <cuentaCorreo>No Necesario</cuentaCorreo> <claveCorreo>No Necesario</claveCorreo> <protocoloCorreo>smtp</protocoloCorreo> <hostCorreo>localhost</hostCorreo> <puertoCorreo>25</puertoCorreo> <autenticacionCorreo>false</autenticacionCorreo> <claveEncriptacion>123456</claveEncriptacion> <activoSMS>true</activoSMS> <plataformaEnvioSMS>servicioSMS.vodafone.EnvioSMS< /plataformaEnvioSMS> </configuracionSCAIT>
SCAIT 4. Descripción detallada del código
Proyecto Fin de Carrera 90 Universidad de Sevilla
SCAIT 5. Planificación
Proyecto Fin de Carrera 91 Universidad de Sevilla
5. Planificación
EL desarrollo del proyecto ha constado de las siguientes fases:
• Reunión con el tutor de proyecto para definir el contenido del proyecto y las
tecnologías a usar.
• Búsqueda de documentación sobre las tecnologías a emplear en el desarrollo de
las distintas interfaces Web (Interfaz de suscripción por parte del alumno a los
distintos servicios y la interfaz de publicación de exámenes para los profesores).
• Instalación y configuración del entorno de desarrollo
• Desarrollo del modelo de datos necesario para la aplicación.
• Programación de las interfaces Web.
• Programación del servicio de envío de de calificaciones mediante correo
electrónico.
• Estudio de la implantación del servicio de información de calificaciones
mediante envío de SMS a cobro revertido. En esta fase del proyecto, se contacto
con diversas empresas para ver las distintas posibilidades para la implantación
de éste servicio.
• Programación del servicio de envío de calificaciones mediante SMS a cobro
revertido.
• Pruebas de funcionamiento.
• Reuniones de seguimiento con el tutor del proyecto.
• Redacción de esta memoria.
• Instalación de SCAIT en el servidor PISCIS3 situado en el laboratorio del área.
• Realización de las transparencias para la presentación del Proyecto Fin de
Carrera.
Agrupando las distintas fases del proyecto bloques generales, se han obtenido las
siguientes estadísticas:
Estimación general del tiempo dedicado a la realización del proyecto
Tareas de documentación 110 Horas (21.78%)
Reuniones con el tutor 35 Horas (6.93%)
SCAIT 5. Planificación
Proyecto Fin de Carrera 92 Universidad de Sevilla
Estimación general del tiempo dedicado a la realización del proyecto
Desarrollo del código 174 Horas (34.46%)
Instalación de SCAIT en la maquina
Piscis3.
10 Horas (1.98%)
Pruebas 10 Horas (1.98%)
Redacción de la memoria y realización de
la presentación.
166 Horas (32.87%)
TOTAL DE HORAS 505 Horas
Véase lo anterior de forma gráfica en el siguiente diagrama:
Documentación
Desarrollo del código
Memoria y presentación
Runiones con el tutor
Instalación en Piscis3
Pruebas
Figura 21. Estadística del tiempo dedicado a cada fase del proyecto.
Desglosando las distintas tareas necesarias para la realización del proyecto, se obtiene la
siguiente tabla.
Estimación detallada del tiempo dedicado a cada una de las tareas necesarias para
la realización del proyecto
Reuniones con el tutor de proyecto para
definir el contenido del proyecto y las
tecnologías a usar.
10 Horas (1.98%)
Búsqueda y estudio de documentación
sobre las tecnologías a emplear en el
desarrollo de las distintas interfaces Web
60 Horas (11.89%)
Instalación y configuración del entorno de
desarrollo
10 Horas (1.98%)
SCAIT 5. Planificación
Proyecto Fin de Carrera 93 Universidad de Sevilla
Desarrollo del modelo de datos necesario
para la aplicación.
8 Horas (1.58%)
Programación de las interfaces Web 140 Horas (27.72%)
Programación del servicio de envío de de
calificaciones mediante correo
electrónico.
6 Horas (1.19%)
Estudio de la implantación del servicio de
información de calificaciones mediante
envío de SMS. Obtención de las APIs de
las empresas proveedoras del servicio.
50 Horas (9.9%)
Programación del servicio de envío de
calificaciones mediante SMS.
10 Horas (1.98%)
Pruebas de funcionamiento 10 Horas (1.98%)
Reuniones de seguimiento con el tutor del
proyecto.
25 Horas (4.95%)
Redacción de esta memoria.
160 Horas (31.68%)
Instalación de SCAIT en el servidor
PISCIS 3
10 Horas (1.98%)
Realización de las transparencias para la
presentación del Proyecto Fin de Carrera.
6 Horas (1.19%)
TOTAL DE HORAS 505 Horas
Se obtiene un total de 505 Horas empleadas en la elaboración del proyecto Fin de
Carrera. Si se divide este tiempo entre 40 horas laborables por semana se obtiene un
total de 12 semanas y un día.
SCAIT 5. Planificación
Proyecto Fin de Carrera 94 Universidad de Sevilla
SCAIT 6. Pruebas realizadas
Proyecto Fin de Carrera 95 Universidad de Sevilla
6. Pruebas realizadas
6.1. Datos de partida
Con el objeto de comprobar el funcionamiento de la aplicación, se han generado unos
datos ficticios con los que se ha trabajado a la hora de realizar las distintas pruebas a las
que se ha sometido la aplicación. En el CD adjunto del proyecto y en su directorio
pruebas, se puede encontrar el archivo “ScriptDatosPruebasSCAIT.sq” que contiene los
scripts necesarios para cargar los datos que se han usado para realizar las pruebas de
funcionamiento.
6.2. Pruebas realizadas
En este apartado se va a describir las distintas pruebas realizadas para verificar el
correcto funcionamiento de SCAIT. Durante el proceso de realización de pruebas,
salieron a relucir distintos errores, los cuales fueron solucionados.
6.2.1. Comportamiento de las interfaces Web
Las primeras pruebas que fueron realizadas se orientaron a la correcta navegación a
través de las interfaces Web que componen SCAIT (Interfaz de los alumnos e interfaz
de los profesores).
6.2.1.1. Interfaz de los alumnos
Las primeras pruebas se enfocaron a analizar el comportamiento de la interfaz ante el
uso incorrecto por parte del alumno. Es decir, tratar de avanzar en las pantallas sin
completar los cuadros de texto requeridos, introducir valores no validos,….
Básicamente, estas pruebas lo que hacen es analizar el comportamiento de las
restricciones introducidas en el código mediante lenguaje JavaScript. A continuación,
se exponen las pruebas realizadas para cada una de las páginas que componen la interfaz
Web.
Pagina de autenticación
Prueba Resultado
Dejar el DNI en blanco Popup avisando que se ha de rellenar el campo.
SCAIT 6. Pruebas realizadas
Proyecto Fin de Carrera 96 Universidad de Sevilla
Dejar la clave de acceso en blanco Popup avisando que se ha de rellenar el campo.
Pagina Principal
Prueba Resultado
A la hora de Guardar los datos
personales, dejar en blanco
alguno de los siguientes campos:
el código de autenticidad, el
móvil y el correo electrónico
Popup avisando que se ha de rellenar los campos
que faltan.
Verificación de formato del
móvil: Numero de 9 cifras que
comienza por 6.
Si el formato no es correcto, se muestra un popup
avisándolo.
Pagina Principal
Prueba Resultado
Verificación del formato típico
del correo electrónico.
Si el formato no es correcto, se muestra un popup
avisándolo.
Para cualquiera de los dos
servicios a los que es posible
suscribirse, presionar el botón
“Todas”.
Se selecciona correctamente el servicio del que se
trate para todas las asignaturas en las que se
encuentra el alumno matriculado.
Para cualquiera de los dos
servicios a los que es posible
suscribirse, presionar el botón
“Ninguna”.
Se deselecciona correctamente el servicio del que
se trate para todas las asignaturas en las que se
encuentra el alumno matriculado.
Cambio de clave
Prueba Resultado
Dejar en blanco cualquier de los
siguientes campos: Clave actual,
clave nueva, confirmación de
clave.
Popup avisando que se ha de rellenar los campos
que faltan
Introducir una confirmación de
clave que no coincida con la clave
nueva.
Popup avisando que la confirmación de la clave y
la clave nueva introducida no coinciden.
SCAIT 6. Pruebas realizadas
Proyecto Fin de Carrera 97 Universidad de Sevilla
Al mismo tiempo que se han realizado las comprobaciones anteriores, se ha
comprobado que el flujo de las páginas funciona correctamente, es decir, que si se pulsa
un botón para cambiar de página, se accede a la página deseada.
Una parte importante de la esta interfaz Web es el uso correcto del control de sesión, es
decir, para que un alumno pueda acceder a la pagina principal, ha de pasar con éxito un
proceso de autenticación. De nada serviría este proceso de autenticación, si existiera
alguna forma de evadirlo. Por ello, se ha de comprobar que si un usuario escribe
directamente en el navegador Web la dirección de la página principal, esta ha de
redireccionarse a la pagina de autenticación. Esta comprobación ha sido realizada. Se ha
escrito en el navegador Web las direcciones de las páginas posteriores al proceso de
autenticación, comprobándose que el sistema no permite la carga de dichas paginas.
Así mismo, se ha comprobado que una vez pulsado el botón “Cerrar Sesión” de la
página principal, el usuario si desea volver a acceder a la página principal, ha de pasar
de nuevo con éxito el proceso de autenticación.
Las siguientes pruebas están relacionadas con el comportamiento de la interfaz en
cuanto a lectura y escritura de datos en las base de datos del sistema. Se ha comprobado
que todos los datos cargados en las páginas de la interfaz: Datos personales, datos de
suscripción a los servicios, datos de los exámenes ya publicados vía Web, se
corresponden con los existentes en base de datos. Así mismo, cualquier modificación de
los datos es actualizada correctamente en base de datos.
Por ultimo, se ha comprobado en el caso de que el servicio SMS no este activo en el
fichero de configuración de SCAIT, no aparecerá la posibilidad de que el alumno se
suscriba a el.
6.2.1.2. Interfaz de publicación de exámenes
Las primeras pruebas se enfocaron a analizar el comportamiento de la interfaz ante el
uso incorrecto por parte del profesor. Es decir, tratar de avanzar en las pantallas sin
completar los cuadros de texto requeridos, introducir valores no validos,….
Básicamente, estas pruebas lo que hacen es analizar el comportamiento de las
SCAIT 6. Pruebas realizadas
Proyecto Fin de Carrera 98 Universidad de Sevilla
restricciones introducidas en el código mediante lenguaje JavaScript. A continuación,
se exponen las pruebas.
Pagina de autenticación
Prueba Resultado
Pulsar el botón de “Publicar”, sin
haber seleccionado ningún
examen a publicar.
No se permite el avance de la aplicación y se
muestra un popup avisando la situación.
Introducir un rango de
publicación de calificaciones no
valido. Un rango es valido
siempre y cuando el valor
máximo sea mayo que el valor
mínimo y ambos valores estén
comprendidos entre el 0 y el 10.
NOTA: Los valores decimales
ha de marcase con puntos “.”
En lugar de con comas “,”.
Se muestra un Popup indicando que el intervalo no
es valido.
Se han realizado pruebas para ver comportamiento de la interfaz en cuanto a lectura de
datos en las base de datos del sistema. Se ha comprobado que todos los datos referentes
a cada uno de los exámenes expuesto en la página son cargados correctamente.
Una vez realizada la publicación, se muestra un informe de los exámenes y modalidades
de publicación recién publicados. Se ha comprobado que dicho informe refleja
fielmente las publicaciones realizadas.
6.2.2. Publicación de calificaciones
Las siguientes pruebas han sido las pruebas de publicación de las calificaciones:
• Publicación vía Web: Al elegir esta opción, la calificación del examen ya sea
provisional o definitiva, aparecerá en la interfaz de los alumnos, para aquellos
SCAIT 6. Pruebas realizadas
Proyecto Fin de Carrera 99 Universidad de Sevilla
alumnos que se encuentre matriculados en la asignatura correspondiente. Se ha
comprobado que este hecho se produce correctamente.
• Publicación vía Correo electrónico: Al elegir esta opción, la calificación del
examen ya sea provisional o definitiva, se enviará a aquellos alumnos que se
hayan suscrito al servicio y cuya calificación esté acorde con el filtro de
selección de publicación establecido por el profesor. Se ha comprobado que este
hecho se produce correctamente.
• Publicación vía SMS: No ha sido posible realizar pruebas de este tipo de envío,
ya que requieren la firma de un contrato con la compañía proveedora del
servicio: en este caso, Vodafone o Mediafusion, sin posibilidad de que estas
empresas nos ofrecieran un servicio de pruebas. De todos modos, los métodos de
envío SMS, se han desarrollado siguiendo fielmente las especificaciones
marcadas por cada uno de los proveedores del servicio.
SCAIT 6. Pruebas realizadas
Proyecto Fin de Carrera 100 Universidad de Sevilla
SCAIT 7. Líneas de continuación
Proyecto Fin de Carrera 101 Universidad de Sevilla
7. Líneas de continuación
La principal línea de Continuación del presente Proyecto Fin de Carrera radica en
adaptar el servicio para que sea accesible desde dispositivos móviles.
Dentro de las posibles ampliaciones del proyecto encontramos:
• Adaptación de SCAIT para ser accesible la tecnología WAP, que es un
protocolo basado en los estándares de Internet que ha sido desarrollado para
permitir a teléfonos celulares navegar a través de Internet. Con la tecnología
WAP se pretende que desde cualquier teléfono celular WAP se pueda acceder a
la información que hay en Internet así como realizar operaciones de comercio
electrónico.
• Adaptación de SCAIT para ser accesible mediante dispositivos PDA, ya que
éstos dispositivos no leen HTML
• Inserción de la tecnología Voicemail, para transmitir mensajes de voz,
codificados en lenguaje XML, dentro de una página Web. Gracias a esta
tecnología, los usuarios al acceder a las distintas páginas que componen las
interfaces Web podrán escuchar la información contenida en ella al mismo
tiempo que la visualizan.
SCAIT 7. Líneas de continuación
Proyecto Fin de Carrera 102 Universidad de Sevilla
SCAIT 8. Conclusiones
Proyecto Fin de Carrera 103 Universidad de Sevilla
8. Conclusiones
Con la realización de este proyecto fin de carrera, se han desarrollado una serie de
servicios de información de calificaciones que se espera que sean acogidos
positivamente por parte de los alumnos.
Se ha unificado la interfaz Web donde los alumnos podrán visualizar las calificaciones
de todos los exámenes de las distintas asignaturas en los que hayan participado y cuya
corrección haya sido realizada. Así mismo, se ha puesto a disposición de los alumnos
dos nuevos servicios de recepción de calificaciones mediante correo electrónico o
mediante SMS.
Se han analizado distintas tecnologías existentes para el desarrollo de sistemas de
información e interfaces Web:
• JSP para el desarrollo de las páginas Web. Dentro de este lenguaje se ha
estudiado como crear de etiquetas para ocultar toda la lógica Java que se realice
para dar lugar a las operaciones deseadas.
• Se ha trabajado con el lenguaje JAVA, lenguaje muy extendido en la actualidad.
• Se ha trabajado con base de datos, en este caso con Postgres, para almacenar los
datos.
• Se ha trabajado con XML, lenguaje para el soporte de datos, que en los últimos
años ha adquirido gran popularidad, y que sirve para estructurar, almacenar e
intercambiar información.
Se ha trabajado con entornos de desarrollo no comerciales, entre ellos Eclipse, que es un
IDE bastante potente y empleado en la actualidad por la mayoría de las empresas que
se dedican al desarrollo de aplicaciones.
Se ha realizado un estudio de la viabilidad de la puesta en marcha del servicio de
información de calificaciones a los alumnos mediante el envío de mensajes SMS,
tecnológica y comercialmente. En este proceso ha sido necesario contactar con un gran
número de empresas.
SCAIT 8. Conclusiones
Proyecto Fin de Carrera 104 Universidad de Sevilla
Desde el punto de vista tecnológico, se ha estudiado las distintas posibilidades de envío
de SMS desde una aplicación Web hacia terminales móviles:
• Conexión del ordenador en el que se encuentra la aplicación a la red móvil, (ya
sea mediante una tarjeta GSM o UMTS conectada al ordenador, o bien a través
de la conexión vía cable USB a un Terminal móvil).
• Envío a través de Internet de los SMS hacia las centrales de proveedores del
servicio SMS, implementándose para este caso el envío de SMS mediante dos
proveedores distintos: Vodafone y Mediafusion.
Desde el punto de vista comercial, se ha realizado un estudio para sondear las distintas
formulas que permitan la puesta en marcha del servicio acarreando los mínimos costes
posibles al área de Ingeniería de Telemática. Se ha barajado el envío de mensajes SMS
publicitados por terceros, así como el uso del servicio de alertas, gracias al cual, es el
usuario final el que soporta el gasto del envío.
SCAIT ANEXOS
Proyecto Fin de Carrera 105 Universidad de Sevilla
9. Bibliografía
Libros
[1] XML al descubierto / Michael Morrison et al. Prentice Hall, 2000.
[2] JavaServer Pages. Manual de usuario y Tutorial. Agustin Froufe. Ra-Ma.
[3] Java Manual de Referencia. McGraw-Hill.
Sitios Web
[1] http://www.pgadmin.org/
[2] http://www.eclipse.org
[3] http://java.sun.com/j2se
[4] http://jakarta.apache.org/tomcat/
[5] http://www.sendmail.org/
[6] http://bluefish.openoffice.nl/
[7] http://java.sun.com/products/javamail/
[8] http://fedora.redhat.com/
[9] http://logging.apache.org/log4j/docs/
[10] http://jdbc.postgresql.org/
[11] http://www.faqs.org/rfcs/rfc2246.html
[12] http://vodafone.es
[13] http://partner.vodafone.es
SCAIT ANEXOS
Proyecto Fin de Carrera 106 Universidad de Sevilla
SCAIT ANEXOS
Proyecto Fin de Carrera 107 Universidad de Sevilla
ANEXOS
SCAIT ANEXOS
Proyecto Fin de Carrera 108 Universidad de Sevilla
SCAIT A. Servidores y paquetes instalados
Proyecto Fin de Carrera 109 Universidad de Sevilla
A. Servidores y paquetes instalados
A.1. Servidores
Para el funcionamiento de SCAIT es necesario instalar los servidores que se citan a
continuación.
La instalación final de SCAIT se ha realizado en la maquina PICIS3 del laboratorio del
Área de Ingeniería telemática. El sistema operativo que se ha instalado es el Fedora
Core 3. En los CDs de instalación de Fedora nos encontramos directamente tres de los
servidores necesarios para el funcionamiento de SCAIT. Se trata de:
• Apache. Servidor de aplicaciones Web. Soporta el protocolo HTTP y HTTPS.
Por si solo no puede servir paginas Web dinámicas, pudiendo hacerlo en
colaboración con Tomcat (otro servidor que se ha instalado). La versión
instalada es la 2.0.
• Postgres: Base de datos en la que se almacenaran los datos para su posterior
manejo por SCAIT. La versión instalada con Fedora Core 3 es la 7.4.6.
• Sendmail: Servidor de correo electrónico mediante el cual se realiza el envío de
los correos electrónicos con las calificaciones a los distintos alumnos.
A parte de la instalación de estos servidores que se realiza en el proceso de instalación
del Fedora Core 3, se ha de instalar el servidor Tomcat, que será en encargado de servir
las paginas Web dinámicas (jsp) que compongan SCAIT. Tomcat se ha configurado
para interactuar con Apache para servir el conjunto global de páginas que componen
SCAIT. Las paginas .HTML serán servidas por apache, mientras que las paginas JSP
son reenviadas desde apache hasta Tomcat, para que sea este último quien las procese.
Se remite al lector interesado en el proceso de configuración de Tomcat colaborando
con Apache, a los distintos manuales de configuración específicos de cada servidor.
En los siguientes dos apartados se habla de la instalación y configuración del servidor
Postgres y el servidor Sendmail.
SCAIT A. Servidores y paquetes instalados
Proyecto Fin de Carrera 110 Universidad de Sevilla
A.1.1. Postgres
Como se ha mencionado, la instalación se realiza conjuntamente con el Fedora Core 3.
A la hora de la instalación del sistema operativo se indica que se desea instalar el
servidor de base de datos Postgres.
En este apartado se verá brevemente los pasos necesarios para arrancarlo.
• Crear el usuario particular para la base de datos del Proyecto. Se ha optado por
llamar al usuario 'scait-gsait'.
createuser scait-gsait
A este usuario se le permitirá la creación de bases de datos (de hecho él será quien
creará la base de datos del Proyecto), y no se le permitirá la creación de nuevos
usuarios.
• Para que el recién creado usuario 'scait-gsait' pueda actuar, es necesario indicarle
a postgres que acepte peticiones de usuarios locales. Para ello, es necesario
descomentar la línea siguiente del fichero /usr/share/pgsql/data/pg_hba.conf :
Local all all trust
• Reiniciar postgres. El siguiente paso es crear la base de datos del Proyecto. Se
llamará 'bd_scait-gsait'. El comando que la crea es el siguiente:
createdb U gsait bd_gsait
La opción U gsait indica que el usuario gsait sea el que cree la base de datos gsait.
• Ya se puede actuar sobre la base de datos recién creada. Para ello, basta con
iniciar el Terminal interactivo de postgres:
psql U gsait bd_gsait
SCAIT A. Servidores y paquetes instalados
Proyecto Fin de Carrera 111 Universidad de Sevilla
A.1.2. SendMail
Se ha usado la versión de SendMail contenida en la instalación del Fedora Core 3. Se ha
configurado el servidor de correos para que los correos los envíe a través de mail.us.es.
Con esto solo bastará enviar desde SCAIT los correos al puerto 25 de localhost y
sendmail se encargara de redirigirlos hacia mail.us.es, Para ello se ha editado el fiero de
configuración: /etc/mail/sendmail.cf estableciendose lo siguiente:
# "Smart" relay host (may be null) DSmail.us.es
Una vez hecho lo anterior se rearranca el servicio con el comando:
/etc/rc.d/init.d/sendmail restart
A. 2. Paquetes instalados
En este apartado se va a exponer un cuadro resume de los paquetes que han sido
necesarios incluir dentro de SCAIT para conseguir su funcionamiento. Todos los
paquetes aquí mencionados, se pueden encontrar en el CD del proyecto dentro del
directorio anexos\Paquetes.
Paquetes instalados
Nombre Descripción
JavaMail: mail.jar ,
activation.jar
API para el envió de correos electrónicos
Xerces: xercesImpl.jar,
xercesSamples.jar
API SAX, para parsear documentos XML
Blowfish API para la encriptación de las claves en la base de datos
Log4j: log4j-1.2.9.jar Para la creación de archivos de log.
Driver de la base de datos
pg74.216.jdbc3.jar
Driver de la base de datos
FileServlet.jar API para el envío de los mensajes SMS a través de
Vodafone.
SCAIT A. Servidores y paquetes instalados
Proyecto Fin de Carrera 112 Universidad de Sevilla
SCAIT B. Contenido del CD del proyecto
Proyecto Fin de Carrera 113 Universidad de Sevilla
B. Contenido del CD del proyecto
Con la memoria del proyecto fin de Carrera se adjunta un CD. En este apartado se
desglosará su contenido. Así mismo, en el propio CD, existen ficheros de texto donde se
indica el contenido de cada uno de los directorios en los que se encuentran. A
continuación se muestra un esquema de los ficheros y carpetas contenidos en el CD.
Figura B1. Estructura del CD.
B.1. Directorio Raíz
En el directorio raíz del CD se encuentran los siguientes archivos
SCAIT B. Contenido del CD del proyecto
Proyecto Fin de Carrera 114 Universidad de Sevilla
Archivos
Nombre Descripción
Archivo Indice.txt Contiene información sobre el contenido
del CD, es decir, indica los archivos y
carpetas que contiene.
Memoria.pdf Archivo PDF que contiene la memoria del
proyecto
B.1.1. Carpetas
En el directorio raíz se encuentran las carpetas que se indican a continuación:
Carpetas
Nombre Descripción
Código Contiene el código fuente desarrollado en el proyecto,
así como el código compilado.
Scripts Base de Datos Contiene los Scripts SQL con operaciones sobre la
base de datos:
- Generación de tablas
- Limpieza de datos al comienzo del curso académico
- Script para inserción de datos para las pruebas.
JavaDocSCAIT Contiene los ficheros JavaDoc generados a partir del
código fuente del proyecto
anexo Contiene subcarpetas que se detallaran mas tarde.
Dentro de la carpeta Anexo, podemos encontrar las siguientes subcarpetas:
SCAIT B. Contenido del CD del proyecto
Proyecto Fin de Carrera 115 Universidad de Sevilla
Contenido de la carpeta: Anexo
Nombre Descripción
Paquetes Contiene los paquetes necesarios para el
funcionamiento de la aplicación.
- JavaMail: APi para el envio de correos
electronicos
- Xerces: API SAX, para parsear
documentos XML
- Blowfish: APi para la encriptacion de
las claves en la base de datos
- pg74.216.jdbc3: Driver de la base de
datos Postgres
- log4j-1.2.9: Para la generacion de
logres
- FileServlet: API para el envio de SMS
a traves de Plug Inred de Vodafone
Plugin InRed - Vodafone Información aportada por Vodafone:
- API para el envío de SMS a traves del
servicio Plug inRed
- Documentación de la API
- Manual de usuario
SCAIT B. Contenido del CD del proyecto
Proyecto Fin de Carrera 116 Universidad de Sevilla
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 117 Universidad de Sevilla
C. Proveedores del servicio de envío de SMS
Sin duda, como se ha apuntado, la gran novedad de este proyecto es la puesta en marcha
del servicio de información de calificaciones mediante SMS a los alumnos. Sin
embargo, este servicio tiene un coste asociado: el coste del envío de SMS a través de las
redes móviles. Es inviable que el Área asuma este coste, ya que se habla de un gran
volumen de trafico. Existen dos posibilidades para descargar al Área de este
desembolso:
• Mensajes patrocinados por terceros. Buscar alguna entidad
patrocinadora de estos SMS. Para el alumno esta opción no tendría coste
alguno. Recibiría sus calificaciones provisionales junto con la fecha de la
revisión y junto a dicha información, publicidad de la empresa
patrocinadora.
Caracteristicas:
� Se trataría de usar un servicio de envío de mensajes corto a través
de la red móvil, alcanzándola bien con un Terminal conectado al
ordenador o mediante Internet gracias a una conexión con alguna
operadora.
� La tarificación recae sobre el usuario que realiza el envío de los
SMS.
� Se he de buscar patrocinador que asuma el gasto. Este es el
principal inconveniente de esta opción
• Usar el servicio PREMIUM MT que ofrecen algunas compañías del
sector. PREMIUM MT es el nombre comercial que tiene el servicio de
envío de SMS a cobro revertido. El coste de los SMS con las
calificaciones es asumido por el alumno, descontándoles el precio del
SMS en el mismo instante en el que lo reciben en su Terminal móvil.
Para hacer uso de este servicio el Área de Ingeniería de telemática
tendría que contratar el servicio PREMIUM MT con alguna empresa que
lo oferte.
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 118 Universidad de Sevilla
Caracteristicas del Servicio Premium MT:
� Comúnmente conocido con el nombre de “Alertas”. Los usuarios
finales han de suscribirse con el operador a estas alertas de
calificaciones.
� El coste de cada envio recaerá sobre el alumno en el momento de
la recepcion de cada mensaje.
� Las grandes operadoras (Movistar, Vodafone, Anema) exigen un
volumen de trafico continuado y elevado para ofrcer a un usuario
este servicio. Por tanto para que esta opcion sea viable, se ha de
contratar el servicio PremiumMT con terceras empresas como
movilisto, Mediafusion, MyAlert,.. que no imponen un volumen
elevado de trafico.
� La contratación y mantenimiento de este servicio recae sobre la
entidad que lo contrata, es decir, en este caso el Área de
Ingeniería de Telemática. Sin embargo, se pueden alcanzar
acuerdos con las compañías para que este coste sea incluido en la
tarificacion al usuario final.
En el proyecto, tras contactar con un gran numero de empresas, se han contemplado las
dos opciones. Se ha desarrollado un método de envío SMS a través de la conexión con
Vodafone (envío de SMS tarificados en origen), y un método de envío de alertas
(Servicio Premium MT) tal y como seria necesario en caso de contratar este servicio con
la empresa Mediafusion.
C.1. Listado de empresas del sector
En un primer momento se sondeo las condiciones económicas requeridas por cada una
de las tres operadores móviles de España. Dichas compañías, requieren a sus clientes
del servicio Premium que aseguren un volumen de tráfico importante para ofertarles
este servicio. Dado, que por las características del servicio SMS mediante cobro
revertido de información de calificaciones no permite asegurar mensualmente un
volumen de tráfico de mensajes, se optó por contactar con terceras empresa que ofrecen
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 119 Universidad de Sevilla
este servicio. Durante el desarrollo del proyecto se trato de contactar con las siguientes
empresas del sector.
Direcciones de contacto con empresas proveedoras del Servicio Premium
MOBILE365 S.L http://www.mobile365.com/
CELLUS MASP SPAIN, S.L http://www.cellus.es/tecnologia.htm
MOVILISTO, S.A http://www.movilisto.com/
PROSODIE ESPAÑA, S.A. http://www.prosodie.es/
ALVENTO SOLUCIONES, S.L http://www.alvento.com/
MYALERTCOM, S.A. http://www.myalert.com/
SMS ARENA, S.L http://smsarena.com/
NETSIZE ESPAÑA, S.L http://www.netsize.com/
ADVANCE TELEPHONE
SERVICES, S.A.
http://www.atssa.biz/
LATINIA INTERACTIVE
BUSINESS, S.A.
http://www.latinia.com/
MEFLUR, S.L http://www.meflur.com/
MEDIAFUSIÓN ESPAÑA, S.A http://www.mediafusion.es/
C.2. MediaFusion
C.2.1. Definición del producto de alertas Premium M T
Coste del servicio para el usuario:
Coste por SMS recibido (excepto el primer SMS recibido por el usuario con la
información del servicio que es gratuito)
0,20 € +IVA
Costes por alta del servicio
Usuarios Movistar y Amena 0,20 €+ IVA
Usuarios Vodafone 0,15 €+ IVA
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 120 Universidad de Sevilla
Costes de baja del servicio
Usuarios Movistar y Amena Gratuito para el usuario
Usuarios Vodafone 0,15 €+ IVA
Eleccion del Alias
• Los ALIAS tienen que ser sin espacio. Por ejemplo para alerta del tiempo en
BILBAO, podría elegirse TBILBAO pero no TIEMPO (espacio) BILBAO.
• ALTAS: para dar de alta los servicios hay tres opciones; “ALTA ALIAS”,
“ALERTA ALIAS”, “ALIAS”
Por ejemplo: para el servicio TIEMPO EN BILBAO; podríamos elegir:
ALTA TBILBAO
ALERTA TBILBAO
TBILBAO
• BAJAS: también tres opciones: “BAJA ALIAS”, “ALIAS FIN”, “ALIAS
BAJA”
Por ejemplo;
BAJA TBILBAO
TBILBAO FIN
TBILBAO BAJA
Información adicional del Servicio.
El número máximo de alertas diarias es de 10 SMS y 50 SMS mes; contando con todos
los posibles servicios a los que está suscrito el usuario.
Por último el usuario Movistar, recibirá un SMS al mes informándole cómo debe darse
de baja; esto es parte de su política de atención al cliente. El coste de este SMS es por
parte de Movistar.
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 121 Universidad de Sevilla
C.2.2. Pasarela de Alertas SMS-HTTP
C.2.2.1. Introducción
Mediafusión ofrece la posibilidad de enviar alertas a través de protocolo estándar
HTTP.
Las alertas con destino a terminales móviles (MT) serán entregados a la pasarela de
Mediafusión por las aplicaciones del cliente, asimismo la pasarela Mediafusión
entregará al cliente las notificaciones de altas y bajas de suscripciones que se produzcan,
todo ello vía TCP/IP y protocolo HTTP.
Para que las transmisiones entre Mediafusión y el cliente sean seguras (encriptadas), la
pasarela será accesible sobre SSL para aquellos clientes que así lo deseen.
C.2.2.2. Requisitos previos
Para poder acceder al envío y recepción de mensajes se deben cumplir los siguientes
requisitos:
• Conexión Internet
• Una aplicación Web accesible en Internet
C.2.2.3. Notificaciones de Altas/Bajas de suscripci ón
El cliente deberá indicar a Mediafusión la URL de acceso a su aplicación en el
momento de la contratación del servicio, así como posibles datos adicionales como
autentificación HTTP básica, etc.
La pasarela SMS de Mediafusión llamará a dicha aplicación con cada mensaje relativo
al alta y baja de suscripciones que se reciba.
Los parámetros que se enviarán serán los siguientes:
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 122 Universidad de Sevilla
Parámetro Significado
action Podrá ser una de estas palabras
• alta : cuando un usuario pida un alta de alertas
• baja : cuando un usuario pida un baja de alertas
origin Número de móvil del usuario. Formato internacional estándar.
Para España, por ejemplo +34666112233
destination Numero corto del destino del mensaje
Por ejemplo 5757
keyword Alias que quiere dar de alta/baja.
Las llamadas a la aplicación del cliente se harán en formato GET.
Por tanto, suponiendo que la URL de acceso a la aplicación del cliente fuera:
http://app.cliente.com/cgi-bin/suscripciones.cgi
La llamada que la pasarela SMS de Mediafusión haría para un alta de suscripción sería
(en formato URL):
http://app.cliente.com/cgi-bin/suscripciones.cgi?action=alta&origin=%2b3466611 2233&destination=5757&keyword=futbol
La misma petición en formato GET (se eliminan las cabeceras no relevantes):
GET /cgi-bin/suscripciones.cgi?action=alta&origin=%2b3466611 2233&destination=5757&keyword=futbol HTTP/1.0 Host: app.cliente.com
NOTA: La petición GET va toda en una misma línea.
Y la llamada que la pasarela SMS de Mediafusión haría para una baja de suscripción
sería (en formato URL):
http://app.cliente.com/cgi-bin/suscripciones.cgi?action=baja&origin=%2b3466611 2233&destination=5757&keyword=futbol
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 123 Universidad de Sevilla
La misma petición en formato GET (se eliminan las cabeceras no relevantes):
GET /cgi-bin/suscripciones.cgi?action=baja&origin=%2b3466611 2233&destination=5757&keyqord=futbol HTTP/1.0 Host: app.cliente.com
NOTA: La petición GET va toda en una misma línea.
C.2.2.4. Envío de Alertas
Dirección de la pasarela de alertas
Servidor: sms.mediafusion.es
Aplicación de envío: /send_alert
Puerto HTTP: 80
Puerto SSL: 443
Formato de las peticiones
Por cada petición HTTP se podrá enviar una sola alerta. La petición http podrá ser de
tipo GET o POST.
Los parámetros de la petición de envío de alerta son los siguientes:
Parámetro Obligatorio Significado
account Sí Código de cuenta recibido cuando se contrató el
servicio
password Sí Password recibido cuando se contrató el servicio
destination Sí Número de móvil de destino de la alerta. No deberá
superar los 20 caracteres. Deberá tener formato
internacional estándar, es decir “+” seguido del
prefijo del país y el número del móvil.
Ejemplo para España: +34666112233
shortid Sí Numero corto de la alerta a la que esta suscrito el
usuario
Por ejemplo 5757
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 124 Universidad de Sevilla
keyword Sí Alias de la alerta a la que esta suscrito el usuario.
encoding No Tipo de mensaje. Los valores posibles son:
txt – para mensajes normales tipo texto
bin – para mensajes binarios (8-bit)
Si no se especifica, se asume txt
Class No Clase de mensaje. Los valores posibles son: 0 1 2 3
Si no se especifica, se asume 1
Udh No “User Data Header” para mensajes binarios
Text Sí Texto del mensaje
Un ejemplo de una petición para enviar una alerta de texto, en formato URL, sería como
sigue:
http://sms.mediafusion.es/send_alert?account=demo&p assword=demo&destination=%2b34666112233&text=prueba+alerta+texto&shortid=5757& keyword=futbol
La petición completa en formato HTTP GET (se omiten las cabeceras no relevantes):
GET /send_alert?account=demo&password=demo&destination= %2b34666112233&text=prueba%20alerta%20texto&shortid=5757&keyword=futbol HTTP/1 .0
La misma petición en formato HTTP POST (se omiten las cabeceras no relevantes):
POST /send_alert HTTP/1.0 Host: sms.mediafusion.es Content-type: application/x-www-form-urlencoded Content-length: 63 account=demo&password=demo&destination=%2b346661122 33&text=prueba%20alerta%20texto&shortid=5757&keyword=futbol
NOTA: Todos los valores de los parámetros deberán ir codificados en formato
urlencode, como es habitual en el protocolo HTTP.
Mensajes binarios
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 125 Universidad de Sevilla
Para el caso de los mensajes binarios (encoding=bin), los parámetros text y udh
expresarán los bytes que deben enviarse, codificando cada byte con una pareja de
caracteres en hexadecimal.
Por ejemplo, para el envío de un ringtone tipo Nokia, los parámetros tomarían los
siguientes valores:
type=bin udh=06050415810000 text=024A3A6135BDC985D9858CC40400511CA2302342542302 702B02D02102B42D42B02B02302D02B02742942702702302D02102B42D42B02B02302D02B02742 94270270230274294270270000
La naturaleza exacta del contenido de los parámetros udh y text deberá ser conocido por
la aplicación del cliente. La correcta composición de estos parámetros se escapa al
ámbito del presente documento.
Códigos de retorno
Cada petición de envío que reciba la pasarela de alertas, será respondida con un código
de resultado.
Este código de resultado (result) se recibirá en el cuerpo de la respuesta HTTP y podrá
ir acompañado de información adicional (reason).
RESULT Significado
0 El mensaje ha sido aceptado por la
pasarela para su envío.
2 Valor de parámetro inválido. En “reason”
se encuentra el parámetro que ha
provocado el error. También se
especifican los errores relativos a las
suscripciones (el destino no esta suscrito a
ninguna alerta, se ha llegado al máximo
diario o mensual, etc.), en cualquier caso
se rechaza el mensaje.
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 126 Universidad de Sevilla
4 Fallo de autentificación (account o
password incorrectos).
Un ejemplo de respuesta HTTP para un envío con éxito sería (se omiten las cabeceras
no relevantes):
HTTP/1.0 200 OK Content-type: text/plain result=0
Si se envía algún parámetro con un valor inválido (por ejemplo type=xxx), la respuesta
HTTP sería (se omiten las cabeceras no relevantes):
HTTP/1.0 200 OK Content-type: text/plain result=2 reason=type
Si el usuario no se ha suscrito a esa alerta, la respuesta HTTP sería (se omiten las
cabeceras no relevantes):
HTTP/1.0 200 OK Content-type: text/plain result=2 reason= no suscription
C.2.2. Condiciones económicas para la contratación del
servicio
C.2.2.1. Características de la acción
La acción consistiría en un sistema de Alertas para la Universidad de Sevilla, en el cual
los usuarios pueden recibir en su móvil las notas de los exámenes.
Los usuarios que se suscriban a esta servicio ofrecido por la Universidad de Sevilla,
deben enviar un SMS con la palabra clave ALTA NOTAS al 5577 (0,20€/SMS). El
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 127 Universidad de Sevilla
contenido que recibirán los usuarios puede tener la periodicidad que estime la
Universidad de Sevilla.
Para darse de baja de este servicio, los usuarios suscritos tienen que enviar un SMS con
la palabra clave BAJA NOTAS al 5577 y en ese momento dejarán de recibir
información por parte de la Universidad de Sevilla.
La Universidad de Sevilla tendrá que proveer a Mediafusion el contenido de dichas
alertas a enviar a los usuarios suscritos.
C.2.3.2. Condiciones económicas
Desarrollo de la aplicación de Alertas
MT (una sola vez)
Configuración de la aplicación SMS
Desarrollo y diseño de la lógica y flujo de
la información
Creación de la base de datos
Habilitar palabra clave y número corto
compartido 5577
Conexión con las operadoras
Total-- 1850 € + IVA
Gestión y mantenimiento técnico
(mensual)
Actualización de contenidos
Informes (histórico de vida de los usuarios
y tráfico de los mensajes)
Administración de los usuarios
Soporte técnico
Total -- 450 € + IVA
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 128 Universidad de Sevilla
C.3. Vodafone. Plug InRed
C.3.1. Definición del producto Plug InRed
Es un Software que instalado en un ordenador, permite a cualquier cliente de contrato
de Vodafone Empresas acceder a toda una gama de servicios de mensajería y
localización para dotar de movilidad a sus procesos de negocio.
Este software será el encargado de comunicar las diferentes aplicaciones residentes en el
ordenador, ya sean las desarrolladas por Vodafone, como aquellas desarrolladas por
terceros o por el propio cliente, permitiendo así el acceso total a la movilidad de datos.
Por ejemplo, instalando el Plug InRed de Vodafone y una aplicación compatible, una
empresa de reparación podría comunicarse de forma ágil y novedosa con sus clientes a
través de los servicios SMS o MMS de Vodafone.
El cliente deberá:
• Instalar en su ordenador el Plug InRed de Vodafone.
• Activar la conexión en Vodafone, en ese momento se le asignará un número
móvil
• Instalar tantas aplicaciones compatibles con el Plug InRed de Vodafone como
desee.
El software de Plug InRed de Vodafone se dirige a medianas y pequeñas empresas o a
autónomos que necesiten en su PC aplicaciones de gran valor con acceso a la red móvil.
Vodafone pone a disposición de los desarrolladores de aplicaciones software para estos
sectores de la posibilidad de conectar sus aplicaciones a la red Vodafone de forma
sencilla.
Cualquier desarrollador puede integrar sus aplicaciones con el Plug InRed de Vodafone.
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 129 Universidad de Sevilla
C.3.2. API suministrada
En esta apartado se expondrán las clases principales necesarias para el envío SMS. Estas
clases son la clase Sms y la clase SMSManager.
C.3.2.1. Clase SMS
Representa un objeto SMS, que proporciona una serie de métodos para establecer el
contenido del SMS. Se remite al lector a la documentación de la API que se encuentre
en el CD del proyecto dentro de directorio anexos\Plugin InRed – Vodafone.
Métodos de la clase SMS
public java.lang.String getDestAddress() Obtiene la dirección de destino
public void setDestAddress(java.lang.String
destAddress)
Establece la dirección de destino
public java.lang.String getSourceAddress() Obtiene la direccion origen
public java.lang.String getMessageBody() Obtiene el cuerpo del mensaje
public void setMessageBody(java.lang.String
messageBody)
Establece el cuerpo del mensaje
public java.lang.String getPriorityFlag() Obtiene la prioridad del mensaje
public void setPriorityFlag(java.lang.String
priorityFlag)
Establece la prioridad del
mensaje
public java.lang.String getDataCodingScheme() Obtiene el tipo de mensaje del
que se trata: emergente o no
emergente
public void
setDataCodingScheme(java.lang.String
dataCodingScheme)
Establece el tipo de mensaje del
que se trata.
public java.lang.String getDate() Obtiene la fecha de recepción
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 130 Universidad de Sevilla
C.3.2.1. Clase SMSManager
Clase que proporciona los métodos necesarios para el envío y recepción de los SMS. Se
remite al lector a la documentación de la API que se encuentre en el CD del proyecto
dentro de directorio anexos\Plugin InRed – Vodafone.
Métodos de la clase SMSManager
public void submit(SMS sms)
throws VodafoneException,
SubmitException
Envia un SMS
public SMS[] deliver()
throws DeliverException,
Obtiene los mensajes recibidos
por el usuario.
C.3.3. Condiciones económicas
Para realizar la activación del software de Plug InRed es necesario disponer de un
usuario y una contraseña que se obtiene llamando al Servicio Gestión de Empresas
marcando el número gratuito 122 si se llama desde un teléfono móvil Vodafone o el 607
100 122 si se llama desde cualquier otro teléfono, (precio de la llamada según operadora
utilizada).
La Instalación de las aplicaciones Plug InRed de Vodafone son gratuitas. Vodafone
únicamente factura por el total del consumo de datos del conjunto de aplicaciones
instaladas sobre el Plug InRed según las siguientes tarifas:
Cuota alta conexión 30€
* Impuesto indirectos no incluidos.
Tarifas
A móviles Vodafone
Total SMS enviados al mes a móviles Vodafone
De Hasta Precio por SMS
enviado a num.
Precio por SMS
enviado a resto de destinos
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 131 Universidad de Sevilla
A móviles Vodafone
Total SMS enviados al mes a móviles Vodafone
frecuente Vodafone
- 100 0.12€ 0.15€
101 500 0.11€ 0.14€
501 1000 0.10€ 0.13€
1001 - 0.10€ 0.12€
Al resto de operadores Nacionales
Precio por SMS 0.15€
A destinos internacionales
Precio por SMS 0.60€
SCAIT C. Proveedores del servicio de envío de SMS
Proyecto Fin de Carrera 132 Universidad de Sevilla
SCAIT D. Manual de usuario de SCAIT
Proyecto Fin de Carrera 133 Universidad de Sevilla
D. Manual de usuario de SCAIT
D.1. Servicios ofrecidos a los alumnos
Con SCAIT se ofrece a la comunidad universitaria una serie de servicios relacionados
con la información de las calificaciones de sus exámenes. Dichos servicios son los
siguientes:
• Posibilidad de que un alumno al acceder a una página Web tenga disponibles
las calificaciones de cada uno de los exámenes que ha realizado.
• Posibilidad de suscribirse al servicio de recepción de calificaciones mediante
correo electrónico. Esto es, en el momento de la publicación de las
calificaciones de un examen, se enviará a cada alumno un correo electrónico
personalizado indicándole su calificación, así como la fecha hora y lugar de la
revisión en el caso de que las notas aun sean provisionales.
• Posibilidad de suscribirse al servicio de recepción de calificaciones mediante
SMS. Esto es, en el momento de la publicación de las calificaciones de un
examen, se enviará a cada alumno un SMS personalizado indicándole su
calificación, así como la fecha hora y lugar de la revisión en el caso de que las
notas aun sean provisionales.
D.2. Web de suscripción a los distintos servicios y
consulta de calificaciones
D.2.1. Acceso
Para acceder a esta Web es necesario pasar con éxito un proceso de autenticación. Se
deberá indicar un login y una clave. En principio para cada alumno inicialmente su
login y clave será su DNI., pudiéndose cambiar la clave una vez pasada con éxito la
primera vez la autenticación.
Para el caso de DNI Nacionales, para acceder a la aplicación se puede introducir como
DNI la cadena sin letra o con letra, según se prefiera. La clave en principio
corresponderá al valor del DNI obviando la letra.
SCAIT D. Manual de usuario de SCAIT
Proyecto Fin de Carrera 134 Universidad de Sevilla
D.2.1. Pagina principal
En la página principal se encuentran 4 bloques bien diferenciados:
• Botón para el cierre de la sesión. Para dar por concluida la sesión.
• Modificación de datos personales.
• Suscripción a los distintos servicios.
• Visualización de las notas ya publicadas de los exámenes realizados por los
alumnos.
14.2.1.1. Cierre de la sesión
Pulsando el botón correspondiente se cierra la sesión de dicho usuario. Para volver a
acceder a la página seria necesario pasar de nuevo con éxito el proceso de autenticación.
D.2.1.2. Modificación de datos personales
En la parte superior de la pantalla principal aparecen los datos personales del alumno:
Nombre completo, su DNI. Así, mismo aparecerán tres datos más configurables para el
alumno:
• Código de autenticidad: En este campo el alumno puede introducir una cadena
alfanumérica. Dicha cadena aparecerá juntos a los datos de calificaciones que el
alumno recibe mediante SMS y/o correo electrónico. De esta forma el alumno
puede estar completamente seguro de la autenticidad de dicho SMS y/o correo
electrónico.
• Móvil : Numero de teléfono móvil en el que alumno desea recibir los SMS con
sus calificaciones (siempre y cuando el servicio esté activo y el alumno se haya
suscrito a el).
• Dirección de correo electrónico: Dirección de correo electrónico en la que el
alumno desea recibir los correos con sus calificaciones (siempre y cuando el
alumno se haya suscrito a dicho servicio).
Pulsando el botón “Guardar cambios”, se guardarán los cambios de estos datos
configurables en base de datos. Para el caso del móvil, el sistema comprobará que se
trata de un numero de 9 cifras y que comienza por el numero 6. Para el caso del correo
electrónico, el sistema comprobará que la cadena introducida contiene el carácter @.
SCAIT D. Manual de usuario de SCAIT
Proyecto Fin de Carrera 135 Universidad de Sevilla
Pulsando sobre el botón “Cambiar Clave” se accede a la pantalla de cambio de clave,
donde para cambiar la clave se ha de introducir la clave antigua así como la nueva clave
y la confirmación de la nueva clave. Si el proceso se realiza correctamente, la clave es
cambiada en base de datos.
Figura D.1. Fragmento de la pagina principal donde se muestra el botón de Cerrar
Sesión y la parte de configuración de los datos personales.
D.2.1.3. Suscripción a los distintos servicios
Por cada una de las asignaturas en las que se encuentra matriculado un alumno, se
muestra una casilla de verificación. Si dicha casilla se activa, significa que el alumno
desea suscribirse a dicho servicio (servicio SMS o servicio correo electrónico). La
suscripción es independiente de una asignatura a otra. Así mismo, cabe la posibilidad de
que a lo largo del curso el alumno se suscriba o se borre de un servicio en repetidas
ocasiones.
Para hacer mas cómodo el proceso de suscripción se han habilitado dos botones (Todas
– Ninguna), que desmarcan o marcan un servicio para todas las asignaturas en las que
esté matriculado un alumno. Para que los cambios tengan efectos en la base de datos, se
ha de pulsar el botón “Aplicar Cambios”.
SCAIT D. Manual de usuario de SCAIT
Proyecto Fin de Carrera 136 Universidad de Sevilla
Figura D.2. Fragmento de la pagina principal donde suscribirse a los distintos servicios
ofertados.
D.2.1.4. Visualización de notas ya publicadas
En la parte inferior de la página principal aparecerá un listado de los exámenes
corregidos en los que ha participado el alumno y que han sido publicados. Dependiendo
de si las notas son provisionales o definitivas, aparecerá o no la fecha lugar y hora de la
revisión.
Figura D.3. Fragmento de la pagina principal donde se visualizan las calificaciones de
los exámenes ya publicados.
SCAIT D. Manual de usuario de SCAIT
Proyecto Fin de Carrera 137 Universidad de Sevilla
D.3. Servicios ofrecidos a los profesores
SCAIT proporciona a los profesores una interfaz de publicación de calificaciones a la
que se accederá mediante la autenticación con GSAIT. Existen tres formas posibles de
publicaciones de calificaciones:
• Publicación Web: Realizando este tipo de publicación las calificaciones de dicho
examen pasarán a estar visibles desde la pagina principal de la interfaz de
suscripción a los distintos servicios y visualización de calificaciones de los
alumnos.
• Publicación mediante envío de correo electrónico: Se enviará un correo
electrónico personalizado a cada alumno que haya participado en dicho examen.
• Publicación mediante envío de SMS: Se enviará un SMS personalizado a cada
alumno que haya participado en dicho examen.
Existen para las dos ultimas modalidades de publicaciones, un elemento de filtrado de
envío de las calificaciones. Se puede seleccionar a que alumnos irá dirigida dicha
publicación pudiendo elegir entre las siguientes posibilidades:
• Todos los alumnos
• Alumnos suspensos
• Alumnos aprobados
• Alumnos con notable
• Alumnos con sobresaliente
• Alumnos con matricula de honor.
• Rango: Para este último caso se ha de introducir el intervalo de notas. Se
realizará la publicación solo para los alumnos que hayan obtenido una nota
dentro del intervalo. El sistema comprobará la validez de dicho intervalo de
notas introducido por el profesor.
D.4. Web de publicación de exámenes
Una vez pasado con éxito el proceso de autenticación de GSAIT para un profesor, éste
podrá acceder a la Web de publicación de exámenes. Lo primero que se encontrará es
un listado de exámenes corregidos de las distintas asignaturas impartidas por él.
SCAIT D. Manual de usuario de SCAIT
Proyecto Fin de Carrera 138 Universidad de Sevilla
Por cada examen se mostrará información sobre la fecha de realización del examen, la
fecha y lugar de revisión en el caso de que el examen no haya sido revisado, así como
información sobre si dicho examen ha sido publicado o no con anterioridad en
cualquiera de las tres modalidades de publicación de calificaciones.
Como se ha comentado en el apartado anterior, existe para las publicaciones SMS y de
correo electrónico, un elemento de filtrado de envío de las calificaciones, con el que se
puede seleccionar a que alumnos irá dirigida dicha publicación.
El profesor seleccionará cada examen que desea publicar y en que modalidades desea
hacerlo. Una vez realizada esta selección, se pulsa el botón “Publicar”, que lanza la
operación contra el servidor.
Figura D.5. Pantalla de publicación de notas
Una vez publicados los exámenes elegidos, se muestra por pantalla un informe de las
operaciones realizadas.
SCAIT D. Manual de usuario de SCAIT
Proyecto Fin de Carrera 139 Universidad de Sevilla
Figura D.6. Informa con los exámenes publicados por el profesor una vez concluida la
operación.
SCAIT D. Manual de usuario de SCAIT
Proyecto Fin de Carrera 140 Universidad de Sevilla
SCAIT E. Manual de administración de SCAIT
Proyecto Fin de Carrera 141 Universidad de Sevilla
E. Manual de administración de SCAIT
E.1. Instalación de la aplicación
En este apartado se expondrán los distintos pasos a seguir para instalar y arrancar
SCAIT en una máquina donde se suponen ya instalados los distintos servidores que
SCAIT necesita para su funcionamiento.
En el contenido del CD del proyecto, dentro de la carpeta /código se encuentra el código
fuente de SCAIT junto con su código compilado.
Los pasos a seguir para instalar SCAIT son:
1. Copiar el contenido de la carpeta anterior por debajo del directorio base del
Tomcat, que es el siguiente según para la instalación realizada:
(usr/java/tomcat/webapps/scait/).
2. Añadir el contexto dentro del fichero Server.xml situado en el directorio /conf de
Tomcat. Para ello se ha de introducir dentro del citado archivo lo siguiente:
<Context path="/scait" reloadable="true" docBase="/usr/java/tomcat/webapps/scait" />
3. Añadir las siguientes líneas en el archivo /etc/httpd/conf.d/mod_jk.conf
JkMount /scait/* ajp13 JkMount /scait/servlet/* ajp13
4. Rearrancar el servidor.
Una vez realizados los pasos anteriores SCAIT ya se encontrará operativo.
E.2. Configuración inicial de SCAIT
A continuación se exponen los parámetros de configuración iniciales con los que se ha
puesto en marcha el servidor.
SCAIT E. Manual de administración de SCAIT
Proyecto Fin de Carrera 142 Universidad de Sevilla
Fichero de configuración – Valores
Parámetro Descripción
urlInicio Index.jsp
urlPrincipal Principal.jsp
driverBD org.postgresql.Driver
conexionBD jdbc:postgresql:
nombreBD bd_scait-gsait
usaurioBD Scait-gsait
claveBD *******
cuentaCorreo - No usada en la configuración inicial
claveCorreo - No usada en la configuración inicial
protocoloCorreo smtp
hostCorreo localhost
puertoCorreo 25
autenticacionCorreo false
claveEncriptacion 123456
activoSMS true
platarfomaEnvioSMS servicioSMS.vodafone.EnvioSMS
Si se desea modificar alguno de estos valores de configuración, para que tengan efectos
los cambios ha de reiniciarse el servidor, ya que dichos valores de configuración son
precargados en memoria en el servidor la primera vez que éste recibe una petición Web.
El aspecto inicial del fichero configuración.xml es el siguiente:
<?xml version="1.0" encoding="iso-8859-1"?> <configuracionSCAIT> <urlInicio>index.jsp</urlInicio> <urlPrincipal>principal.jsp</urlPrincipal> <driverBD>org.postgresql.Driver</driverBD> <conexionBD>jdbc:postgresql:</conexionBD> <nombreBD>bd_scait-gsait</nombreBD> <usuarioBD>scait-gsait</usuarioBD>
SCAIT E. Manual de administración de SCAIT
Proyecto Fin de Carrera 143 Universidad de Sevilla
<claveBD>*******</claveBD> <cuentaCorreo>No Necesario</cuentaCorreo> <claveCorreo>No Necesario</claveCorreo> <protocoloCorreo>smtp</protocoloCorreo> <hostCorreo>localhost</hostCorreo> <puertoCorreo>25</puertoCorreo> <autenticacionCorreo>false</autenticacionCorreo> <claveEncriptacion>123456</claveEncriptacion> <activoSMS>true</activoSMS> <plataformaEnvioSMS>servicioSMS.vodafone.EnvioSMS< /plataformaEnvioSMS> </configuracionSCAIT>
E.3. Mantenimiento de la aplicación
E.3.1. Seguimiento de trazas de las operaciones lan zadas en el
servidor
Para realizar un seguimiento de las operaciones que va ejecutando el servidor SCAIT, se
van escribiendo unos ficheros de trazas que van indicando las operaciones que se van
realizando y en caso de producirse errores, quedarán almacenadas las causas de dichos
errores.
El fichero de traza se denomina “scait.log” y se ha situado en el directorio raíz del
servidor. En el caso de la instalación realizada: /usr/java/tomcat/webapps/scait/scait.log.
El formato de las trazas es el que se muestra a continuación:
2005-06-27 23:45:08,238 | SCAIT | OperacionesDB | s electDatosExamen | Fin 2005-06-27 23:45:08,239 | SCAIT | OperacionesLogica s | obtenerNotasExamen | Fin 2005-06-27 23:48:14,342 | SCAIT | OperacionesLogica s | obtenerProfile | Inicio 2005-06-27 23:48:14,342 | SCAIT | OperacionesLogica s | obtenerProfile | Fin 2005-06-27 23:48:18,524 | SCAIT | SevicioMail | env ioMensaje: Could not connect to SMTP host: smtp.myrealbox.com, port: 25; nested exception is: java.net.ConnectException: Connection timed out 2005-06-27 23:48:18,524 | SCAIT | OperacionesLogica s | enviarNotasCorreo | Fin 2005-06-27 23:48:18,524 | SCAIT | OperacionesLogica s | publicarNotas | Fin 2005-06-27 23:48:18,525 | SCAIT | OperacionesLogica s | obtenerExamenesCorregidos | Inicio
SCAIT E. Manual de administración de SCAIT
Proyecto Fin de Carrera 144 Universidad de Sevilla
Si durante el funcionamiento de SCAIT se detecta algún error durante la ejecución,
visualizando el fichero de traza, se puede ver la causa exacta del error y por tanto el
mantenimiento será más sencillo, ya que el punto donde se produce el error estará
localizado.
E.3.2. Activación y desactivación del servicio de e nvío SMS
Existe la posibilidad de poner en marcha SCAIT sin incluir en el la posibilidad del
servicio SMS. De hecho, al inicio de la puesta en marcha de SCAIT lo mas probable es
que el servicio de recepción de notas mediante SMS no esté disponible, ya que para que
esto se produzca y sea viable, el área de Ingeniería Telemática ha de contratar el
servicio PREMIUN MT con alguna empresa o bien, contratar la conexión para el envío
SMS normal y encontrar a alguna empresa que subvencione los envíos.
Pro tanto, en el fichero de configuración, se ha reservado un parámetro denominado
activoSMS de tal forma que:
• Si su valor es true, el servicio estará activo. Los alumnos podrán suscribirse al
servicio y los profesores podrán publicar las calificaciones mediante dicha
modalidad.
• Si su valor es false, el servicio estará inactivo. Los alumnos no tendrán, al
acceder a la interfaz de suscripción a los distintos servicios, la posibilidad de
suscribirse al servicio (es mas, no aparecerá nada referente al servicio de
recepción de calificaciones por SMS). Así mismo, los profesores no tendrán
constancia ni posibilidad de poder publicar las calificaciones bajo esta
modalidad.
E.3.3. Modificaciones necesarias para cambiar de pr oveedor
SMS
En el apartado 4.5. Servicio SMS, se expuso el mecanismo establecido para tratar de
minimizar el impacto provocado en SCAIT por el cambio de proveedor de envío de
mensajes SMS. En este apartado se resumen los pasos a seguir para el cambio de
proveedor de envío SMS. Son los siguientes:
SCAIT E. Manual de administración de SCAIT
Proyecto Fin de Carrera 145 Universidad de Sevilla
• Crear un nuevo paquete dentro del paquete ServicioSMS, con el nombre del
nuevo proveedor.
• Dentro del nuevo paquete (servicioSMS.NombreProveedor) se ha de crear una
clase denominada EnvioSMS que extenderá a la clase abstracta
ClaseGenericaEnvioSMS que se encuentra en el paquete servicioSMS.
• Es obligatorio que la clase EnvioSMS extienda el método envio, que tiene la
siguiente declaración:
public void enviar(String pMensaje, String pMovil) { …
Donde pMensaje es el texto que contendrá el mensaje corto, mientras que pMovil es
el número al que se desea enviar el SMS. Dentro de este método envio se
almacenará la lógica de envió propietaria del nuevo proveedor del servicio.
• En el fichero de configuración existe un parámetro denominado
platarfomaEnvioSMS en el que se ha de indicar la ruta (en términos de
paquetes) de la nueva clase EnvioSMS que se desea invocar para la realización
del envío de mensajes cortos. Véase el ejemplo:
<!-- Indica la plataforma de envio de SMS qeu se u tilizará --> <plataformaEnvioSMS>servicioSMS.vodafone.EnvioSMS< /plataformaEnvioSMS>
E.3.4. Alumno de prueba
Para poder realizar labores de mantenimiento de la interfaz Web, se he creado un
alumno de prueba que estará matriculado en todas las asignaturas incluidas en SCAIT y
que asistirá a todos los exámenes correspondientes de dichas asignaturas.
Los datos del alumno de pruebas son los siguientes:
USUARIO DE PRUEBA
DNI 00000000 (ocho ceros)
Clave 00000000 (ocho ceros)
SCAIT E. Manual de administración de SCAIT
Proyecto Fin de Carrera 146 Universidad de Sevilla
La existencia de dicho usuario de prueba es posible, gracias a que siempre que exista
una inserción de una nueva asignatura y un nuevo examen, éstas se relacionarán con el
usuario a través de sentencias SQL. (De ello se encargará GSAIT).
E.3.5. Borrado de los datos anuales
Con el comienzo de un nuevo curso, es necesario borrar la información contenida en la
base de datos. Se ha de tener la precaución de que este borrado se produzca una vez que
se haya publicado la nota definitiva del examen de septiembre de la última asignatura
que ofrezca estos servicios. Por lo demás, el borrado de los datos referentes a los
alumnos, exámenes y calificaciones es tan simple como ejecutar las cinco sentencias
SQL que se muestran a continuación (en este orden):
DELETE FROM alumno_examen;
DELETE FROM alumno_asignatura;
DELETE FROM examen;
DELETE FROM alumno;
Dichas líneas han sido agrupadas en el script borradoDatosAnualesAlumnos.sql que se
adjunta en el CD del proyecto dentro del directorio “Scripts base de datos”.
Consideraciones
- El borrado no incluye el borrado de profesores y asignaturas impartidas por ellos. Esta
tarea la realizará GSAIT.
- El conjunto de asignaturas que ofrecen el servicio se mantienen en principio de un año
para otro. En el caso en que se quiera añadir o eliminar una nueva asignatura a estos
servicios, se han de ejecutar las sentencias SQL de inserción o borrado correspondientes
sobre la tabla Asignaturas.
Recommended