universidad de sevilla escuela superior...

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


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


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


SCAIT 1. Introducción


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:



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



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.



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



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.



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



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



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


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:



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



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



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



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



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



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.



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.



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.



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.



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.



• 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



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



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.



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




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

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>  <tag> <name>seleccionAlumno</name> <tagclass>tags.SeleccionAlumnoTag</tagclass> </tag>



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



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.



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.



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.



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



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”);



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.



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 .



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



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



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.



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



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



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.



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)



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



• 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



• 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



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


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



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



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:



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



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.



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.



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.



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



• 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



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



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



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


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:



• 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) ) ;



• Asignatura: Entidad que modela las asignaturas que estarán integradas dentro

de los servicios de SCAIT. Contiene los siguientes datos:


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


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


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.




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.


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




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.


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


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.




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


Nota Valor numérico de la calificación del examen.

Calificación Calificación del examen: suspenso, aprobado,

notable, sobresaliente o matricula de honor.


-- ********************* 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 ) ;



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


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



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.



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:



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.



• 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



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.



• 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



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.



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.



• 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() ); }



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



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.



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.



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.



• 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();



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



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.



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



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.



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.



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 5. Planificación


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



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



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 6. Pruebas realizadas


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.



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.



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



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



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 7. Líneas de continuación


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


SCAIT 8. Conclusiones


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


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


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


SCAIT ANEXOS


ANEXOS

SCAIT ANEXOS


SCAIT A. Servidores y paquetes instalados


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.



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



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 B. Contenido del CD del proyecto


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



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:



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 C. Proveedores del servicio de envío de SMS


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.



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



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



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.



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:



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



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



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



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.



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



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



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.



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



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



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 D. Manual de usuario de SCAIT


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.



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



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



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.



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.



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.



Figura D.6. Informa con los exámenes publicados por el profesor una vez concluida la

operación.

SCAIT E. Manual de administración de SCAIT


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.



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>



<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



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:

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

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



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.

universidad de sevilla escuela superior...

Documents