Infraestructura de control del alquiler de bicicletas mediante dispositivos móviles

Escola Tècnica Superior d’Enginyeria Informàtica Universitat Politècnica de València Infraestructura de control del alquiler de bicicletas mediante dispositivos móviles Proyecto Final de Carrera para Ingeniero Técnico en Informática de Sistemas (ITIS) Valencia 21 de Septiembre del 2012 Autor: Antonio Albiñana Martínez Directores: Joaquín Gracia Morán Juan Carlos Ruiz Garcia Valencia 12 de Septiembre de 2012 pagina en blanco intencionada Índice de contenidos Pr logoó..........................................................................................................5 Resumen........................................................................................................7 Introducci nó...................................................................................................9 Arquitectura de la infraestructura..............................................................11 Capa Presentaci nó............................................................................................11 Software utilizado.........................................................................................................................11 Seguridad...................................................................................................................................... 12 Capa L gica de aplicaci nó ó ..............................................................................13 M quina Virtualá.............................................................................................................................14 Servlets.......................................................................................................................................... 15 Software Utilizado.........................................................................................................................16 Apache Tomcat..........................................................................................................................16 Eclipse........................................................................................................................................ 18 Seguridad...................................................................................................................................... 19 Acceso y Autentificaci nó...........................................................................................................20 Control de Decisiones...............................................................................................................21 Capa Persistencia de datos.............................................................................22 Software..................................................................................................................................... 22 Seguridad...................................................................................................................................23 Bases de datos utilizadas.........................................................................25 Base de datos “usuarios”................................................................................25 Base de datos “Hist rico”ó...............................................................................25 Base de datos “puestos”.................................................................................26 Base de datos “bicicletas_puesto”..................................................................26 Base de datos “incidencias”............................................................................26 Funcionamiento de la infraestructura........................................................29 Detalle del procedimiento.................................................................................29 Transacciones............................................................................................................................... 33 Alquiler........................................................................................................................................ 33 Devoluci nó..................................................................................................................................34 Integridad del e-ticket.......................................................................................36 Datos en el cliente.......................................................................................................................37 Estructura de los servlets................................................................................38 Dependencias externas................................................................................................................39 Sesiones.............................................................................................................39 Clases Java especiales....................................................................................40 La clase Cadenas........................................................................................................................40 La clase LCookies........................................................................................................................42 La clase ConexionBD...................................................................................................................43 La clase GestionLogs...................................................................................................................46 Constantes................................................................................................................................. 46 M todo escribirLogsé..................................................................................................................47 La clase Ticket.............................................................................................................................48 Filtros............................................................................................................................................. 49 Configuraci n del FiltroAcceso.javaó..........................................................................................51 Referencias..................................................................................................53 Palabras clave............................................................................................55 Proyecto Final de Carrera Antonio Albiñana Martínez P RÓLOGO En los ltimos tiempos, el desarrollo tecnol gico ha propiciado nuevas formas deú ó comunicaci n. Lo que hace una d cada parec a ciencia-ficci n hoy ya estó é í ó á anticuado. Por encima de todas ellas se encuentran los dispositivos m viles, que hanó pasado en diez a os de ser un simple tel fono a ser un “mini-ordenador”, conñ é una interconexi n y potencia de c lculo impensable al inicio del siglo XXI. Sirvaó á como ejemplo que la c mara en los tel fonos m viles empieza a aparecerá é ó alrededor del a o 2002, y actualmente forma parte del dispositivo, y con unasñ prestaciones equiparables a c maras fotogr ficas compactas.á á La aparici n de sistemas operativos espec ficos, como Android, dise ado paraó í ñ este tipo de dispositivos, ha posibilitado que la generaci n de aplicaciones tantoó para el ocio como de negocio, haya crecido considerablemente en los ltimosú a os, siendo las expectativas de crecimiento a n mayor.ñ ú La naturalidad y facilidad de manejo que proporcionan dichos dispositivos en la actualidad ayuda a que la incorporaci n de estas nuevas tecnolog as a losó í h bitos de uso de los usuarios finales se realice de manera sencilla y coná normalidad, ya que sta se incluye en un dispositivo que el usuario conoce yé est acostumbrado a usar.á En este contexto, el uso de dichos dispositivos m viles inteligentes (tambi nó é denominados smartphones ) se est generalizando de tal manera, que permiteá ampliar la funcionalidad de los mismos, complementando, sustituyendo o realizando diferentes tareas. Este proyecto est enfocado en esa direcci n.á ó -5- Proyecto Final de Carrera Antonio Albiñana Martínez pagina en blanco intencionada -6- Proyecto Final de Carrera Antonio Albiñana Martínez R ESUMEN La idea general del proyecto consiste en la creaci n de una infraestructura paraó el control del alquiler de bicicletas. Esta infraestructura permitir , en un futuro,á utilizar dispositivos m viles para acceder a ella y alquilar una bicicleta. De estaó forma, y tal y como se ha desarrollado el presente PFC, no ser necesario laá instalaci n de ninguna aplicaci n extra, ya que se va a utilizar el navegador queó ó tienen los dispositivos m viles actuales incorporados por defecto.ó El funcionamiento de la infraestructura es el siguiente. El primer paso consiste en el alquiler de la bicicleta, alquiler que se realiza previa validaci n del usuario enó el sistema. Una vez cumplimentada la acci n del alquiler, la aplicaci n devolveró ó á un e-ticket con la informaci n necesaria para realizar las operaciones de controló necesarias, registr ndose adem s esta operaci n en el sistema.á á ó Al devolver la bicicleta, el e-ticket se borra del tel fono, registr ndose tambi né á é esta operaci n en el sistema. En este caso, la devoluci n de la bicicleta pone enó ó marcha el proceso de facturaci n.ó Para la realizaci n del presente PFC se utilizar n herramientas de c digo abierto,ó á ó tanto para el servidor, como para la l gica de aplicaci n y para la gesti n de lasó ó ó bases de datos. Estos programas, as como la infraestructura y la operatividadí entre ellos deber n instalarse y configurarse, mientras que el navegador, tal yá como se ha comentado, ya forma parte del dispositivo del usuario (smartphone). Todas las herramientas y tecnolog as utilizadas ser n explicadas en detalle m sí á á adelante, dentro de su contexto de uso. Brevemente, podemos decir que vamos a utilizar: Herramientas : ✔Apache Tomcat ✔Eclipse ✔PostgresSQL Tecnolog as :í ✔HTTPS ✔Servlets (Java) -7- Proyecto Final de Carrera Antonio Albiñana Martínez pagina en blanco intencionada -8- Proyecto Final de Carrera Antonio Albiñana Martínez I NTRODUCCIÓN El presente proyecto pretende crear, tal y como se ha mencionado, la infraestructura necesaria para el control del alquiler de bicicletas mediante dispositivos m vilesó inteligentes (smartphones). Dichos dispositivos suponen en la actualidad el 45% de mercado y se espera un crecimiento exponencial de los mismos. Un factor importante en este crecimiento es la fuerte apuesta que ha realizado “Google” en el desarrollo del sistema operativo “Android”, siendo sta laé parte fundamental de este impulso. Este esfuerzo le ha llevado a conseguir una cuota de mercado superior al 80% en los smartphones vendidos entre mayo y agosto del 2012. Una de las principales caracter sticas de los nuevos smartphonesí es la inclusi n deó nuevas tecnolog así. Un ejemplo es el NFC. Esta nueva tecnolog a est basada ení á tecnolog as RFID (Identificaci n por Radio Frecuencia), por lo que es necesario unaí ó etiqueta y un lector. El lector puede estar contenido en cualquier dispositivo como, por ejemplo, un tel fono m vil. é ó La tecnolog a NFC presenta dos modos de funcionamiento :í •Pasivo, en las que solo un dispositivo genera el campo electromagn tico,é y el otro se aprovecha de la modulaci n para poder trasferir los datos.ó En este caso, el dispositivo que inicia la comunicaci n es quien generaó dicho campo. •Activo, en el que ambos dispositivos generan campos electromagn ticos.é En este caso, ambos dispositivos necesitan energ a.í Cuando el lector se aproxima a una etiqueta RFID o a otro lector emite una se alñ de radio de corto alcance que excita el microchip de la etiqueta, con lo que podremos acceder a leer la peque a cantidad de datos que se encuentranñ almacenados en sta. En el caso de la comunicaci n con etiquetas o é ó tags, es el lector el encargado de establecer la comunicaci n.ó En el protocolo NFC siempre hay un dispositivo que inicia la comunicaci n, siendoó este dispositivo el encargado de monitorizarla. NFC permite tres modos de comunicaci n, que son:ó •Punto a punto. Utilizado para el intercambio de datos o establecimiento -9- Proyecto Final de Carrera Antonio Albiñana Martínez la manera en la que el contenedor de aplicaciones (el servidor web) relaciona la petici n actual con otras peticiones previas. Con servlets existen tresó maneras de implementar una sesi n: ó • Mediante SSL y por tanto HTTPS 2 . • Mediante Cookies. • Mediante reescritura de la URL, en el que el id de la sesi n seó codifica como par metro en la cadena URL.á Por ejemplo: Http://www...../tienda/index.thml;jssesionid=1234 Un servlet se llama a trav s del nombre de su contenedor dentro del sistemaé web, de manera que podemos decir que el contenedor es el nombre de la aplicaci n y el servlet el nombre de la acci n a reaó ó lizar. A continuaci nó podemos ver un ejemplo de invocaci n de un servlet:ó Http://www..../NombreContenedor/servletInvocado Por qu no se ha seleccionado JSP? B sicamente por dos razones:¿ é á • Un JSP se debe convertir en un servlet de manera interna antes de ejecutarse. • Hay m s c digo de aplicaci n que c digo HTML, lo que producir aá ó ó ó í un c digo ilegible tanto a nivel HTML como JAVA .ó S OFTWARE U TILIZADO A PACHE T OMCAT Como se han utilizado servlets para la gesti n de la l gica de control yó ó funcionamiento, se necesita un servidor capaz de poder trabajar con dicha tecnolog a. Se ha elegido í apache tomcat por ser gratuito y disponer de una amplia y detallada documentaci n as ó í como de una gran comunidad de usuarios. La versi n utilizada es la 6, que se puede obtener de la fundaci n apache aó ó partir del siguiente enlace: http://tomcat.apache.org/download-60.cgi 2 Este ha sido el modelo elegido para este proyecto ya que HTTPS incorpora mecanismos para distinguir los accesos que forman parte de una sesión. -16- Proyecto Final de Carrera Antonio Albiñana Martínez Una vez descargados los binarios, se descomprimen en un directorio y ya está disponible el servidor para su puesta en marcha y funcionamiento b sicos, aunqueá en este punto todav a no atiende peticiones HTTPS.í Para iniciar y detener el servidor utilizaremos los siguientes scripts3 [DIR_INSTALACION]/bin/startup.sh [DIR_INSTALACION]/bin/shutdown.sh Para poder habilitar HTTPS en el servidor, necesitamos un certificado. Existen dos maneras de conseguirlo. La m s sencilla es crear un certificadoá4 autofirmado. Esta es la soluci n que se ha tomado en este caso. El otro m todo de obtenci n deó é ó un certificado consiste, adem s, en crear y a adir una autoridad certificadora.á ñ As pues, para crear el certificado autofirmado se puede utilizar la herramientaí keytool. Esta utilidad se encarga de la gesti n de claves y certificados.ó Permite a los usuarios administrar sus propios pares de claves p blicas/privadas y los certificados asociados para su uso en la auto-ú autenticaci n (donde el usuario se autentica mismo). Sóe invoca mediante el siguiente comando: # $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA La ejecuci n de este comando genera una serie de preguntas, que trasó haberlas contestado, provoca la creaci n del fichero ó.keystrobe en el $home del usuario. El siguiente paso consiste en la modificaci n del fichero deó configuraci n denominado óserver.xml para habilitar SSL, indicar donde se encuentra el fichero .keystore e indicar el password 5 con el que se cre .ó <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" keystoreFile="${user.home}/.keystore" keystorePass="proyecto" clientAuth="false" sslProtocol="TLS" /> 3Un script es una secuencia de órdenes que puede ser ejecutado directamente por el intérprete de comandos. 4Un certificado es una declaración firmada digitalmente de una entidad (persona, empresa, etc). Cuando los datos están firmados digitalmente, se puede verificar que los mismos no han sido modificados (integridad) y que dichos datos vienen de quien dice haber creado y firmado (autenticidad). 5Apache Tomcat utiliza el password por defecto “changeit”. En nuestro caso se ha puesto “proyecto” -17- Proyecto Final de Carrera Antonio Albiñana Martínez Un aspecto a tener en cuenta es la disposici n de los directorios de trabajo. Enó nuestro caso, esta disposici n es distinta a la del servidor apache normal. En esteó caso, las p ginas web 'normales' est n en el directorioá á [DIR_INSTALACION]/ROOT mientras que los generadores de contenidos din micos se encuentran en elá directorio [DIR_INSTALACION]/Webapps El servidor, que en este caso se comporta tambi n como un contenedor deé aplicaciones (motor de servlets) se encarga autom ticamente de comprobará si se han a adido nuevas aplicaciones para darlas de alta en el propioñ servidor y habilitar su funcionamiento. El formato est ndar de fichero utilizado para esta acci n es '.war', el cual contieneá ó toda la informaci n necesaria.ó E CLIPSE Como se ha comentado previamente, para la l gica de control de laó infraestructura se han utilizado servlets. Para realizar la programaci n de losó mismos se ha utilizado una versi n de esta herramienta de programaci nó ó denominada Indigo, la cual ya tiene habilitados los mecanismos necesarios para poder generar el c digo que óutilizar “Apache Tomcat” cuando elá proyecto se exporte, facilitando de esta manera la generaci n de c digo.ó ó Eclipse es un proyecto open source de la fundaci n Eclipse para el desarrolloó de un entorno de desarrollo integrado (IDE). Esta herramienta es de c digoó abierto y est reconocida por la Free Softaware Foundation, aunque suá licencia no es GNU sino EPL (Eclipse Public License). La direcci n deó descarga es : http://www.eclipse.org/downloads/packages/release/indigo/sr2 La utilizaci n de un entorno de trabajo de programaci n facilita la generaci nó ó ó de c digo, ya que permite detectar errores en una etapa temprana deló desarrollo del proyecto. Este tipo de errores son dif ciles de encontrar ení tiempo de ejecuci n, ya que incluyen desde errores sint cticos, como puedenó á -18- Proyecto Final de Carrera Antonio Albiñana Martínez ser palabras mal escritas, hasta clases mal construidas y que son muy f cilesá de detectar en la etapa de desarrollo. Para generar una aplicaci n web desde eclipse deben seguirse los siguienteó pasos. • Se genera un nuevo proyecto de web din mico.á • Se crean los servlets y clases auxiliares necesarias. • Se exporta el proyecto como “war”. La Figura 3 muestra un ejemplo de exportaci n de un proyecto.ó Figura 3. Exportaci n de un proyecto. ó S EGURIDAD La seguridad en este capa viene caracterizada por dos aspectos complementarios entre s . El primero de ellos es el acceso y el autenticado deí los usuarios. En este caso, el sistema debe permitir solo el acceso a aquellos usuarios v lidos en el sistema. Para ello, se ha utilizado un mecanismoá proporcionado por “Apache Tomcat” denominado filtros, los cuales se ponen en funcionamiento antes de acceder al recurso solicitado. -191 2 3 Proyecto Final de Carrera Antonio Albiñana Martínez El segundo aspecto tiene que ver, en primer lugar, con la manera de realizar la comprobaciones internas del control de flujo y en segundo lugar, con la forma de acotar la toma de decisiones a casos concretos, evitando la generalizaci n.ó A CCESO Y A UTENTIFICACIÓN Los filtros son los principales encargados de implementar esta parte de la seguridad. Un filtro es un mecanismo que permite transformar el contenido de las peticiones, respuestas y cabeceras de los mensajes HTTP. Pueden trabajar tanto sobre contenido din mico como est tico. En el presente proyecto solo se utiliza elá á contenido est tico, ya que el prop sito es evitar que se pueda acceder al alquilerá ó de una bicicleta sin estar autenticado. La Figura 4 muestra el esquema de funcionamiento del filtro: Figura 4. Esquema de funcionamiento del filtro. De esta manera, cuando un usuario intenta alquilar una bicicleta, y antes de acceder a ning n recurso, se comprueba si el usuario est autenticado medianteú á la comprobaci n de la existencia de una sesi n y si ya se ha autenticadoó ó previamente. El aspecto m s importante de este tipo de control es, como ya se ha comentado,á que se realiza antes de acceder al servlet que se encarga de gestionar el alquiler. Así se evitan errores durante la gesti n y tratamiento en el alquileró referentes al usuario, los cuales pueden producir alg n error que permitiera elú alquiler a un usuario no v liádo en el sistema. -20- ¿Usuario Autenticado? Servlet alquiler Servlet Autenticar petición filtro redirigir continua Proyecto Final de Carrera Antonio Albiñana Martínez Respecto al acceso posterior a los servlets encargados del alquiler o la devoluci n, se han inhabilitado los accesos cr ticos con par metros a trav s de laó í á é URL (m todo GET), limitando su uso solo a aquellos procesos que es inevitableé su uso, principalmente redirecciones por falta de par metros. As pues, se haá í utilizado el m todo POST para el env o de los datos necesarios para el alquiler.é í Este m todo pasa los par metros a trav s de la entrada est ndar, adem s de noé á é á á ser guardados en el navegador o en los logs de los servidores, evitando de esta manera que un usuario malintencionado pudiera alquilar una bicicleta poniendo como direcci n del navegador “https://...../alquilar?puesto=xx?en=xx.” o similares.ó En este sentido, tambi n los par metros entre servlets relacionados con elé á alquiler/devoluci n (n mero de bicicleta, n mero de puesto) se pasan a trav s deó ú ú é la sesi n, evitando as que un usuario no autenticado pueda acceder a esos datosó í durante el proceso de alquiler/devoluci n.ó C ONTROL DE D ECISIONES En este apartado la seguridad est encaminada a impedir, en la medida de loá posible, los errores derivados de la informaci n que debe ser validada antes deó ser enviada al servidor a trav s de la aplicaci n web. é ó Est n agrupadas aqu tambi n las decisiones de control de flujo del programa, esá í é decir los if , while y dem s estructuras que utilizan comparaciones, inclusiones,á etc. en la toma de decisiones. Por ejemplo, se ha controlado la introducci n de datos num ricos (del puesto)ó é mediante un desplegable para evitar que se introduzcan por error datos no v lidos.á De la misma manera, se comprueba que el n mero de puesto seaú realmente un n mero antes de proceder a realizar ninguna acci n.ú ó Tambi n se han limitado los caracteres v lidos de usuario y password, de maneraé á que son inv lidos caracteres como “%” o “!=”, puesto que pueden ser utilizadosá para realizar ataques de inyecci n SQL. ó Para las sentencias de control se ha utilizado la t cnica denominadaé “especificaci n positiva de valores admisibles”. Con dicha t cnica determinamos sió é sabemos las condiciones v lidas para que se cumpla una determinada condici n.á ó Si esas condiciones se cumplen, entonces esas son las que permiten el acceso. De esta manera solo las opciones v lidas contin an, mientras que el resto (las noá ú v lidas + todas las dem s) no pueden realizar ninguna acci n. A continuaci ná á ó ó podemos ver un ejemplo: -21- Proyecto Final de Carrera Antonio Albiñana Martínez If ( hay error ) Error → else Ok →+ no contempladas If ( está bien ) Ok→ else Error + →no contempladas Especificaci n negativaóEspecificaci n positivaó C APA P ERSISTENCIA DE DATOS Esta capa representa el sistema mediante el cual se guarda la informaci n.ó Normalmente consta de un conjunto de bases de datos con la l gica asociada.ó Como en los casos anteriores, se ha optado por un gestor de base de datos de c digo abierto, que en nuestro caso es el denominado PostgreSQL.ó S OFTWARE PostgresSQL es el motor de base de datos de c digo abierto m s potente deló á mercado. Es distribuido bajo licencia BSD 6 y con su c digo fuente disponibleó libremente. Este software se encuentra disponible en los repositorios de Ubuntu y, por lo tanto, se puede instalar desde el gestor gr fico deá aplicaciones (Synaptic en el caso de Ubuntu) o desde consola mediante la orden: apt-get install postgresql-9.1 Despu s de instalar tanto el motor como el gestor gr fico é á pgAdmin, se crear n las bases de datos necesarias para el funcionamiento de la aplicaci n,á ó como son la de Usuarios, Hist rico, Puestos, bicicletas_Puestos, etc. que seó describen en detalle m s adelante. La Figura 5 muestra el aspecto gr fico deá á las bases de datos. 6La licencia BSD es la licencia de software otorgada principalmente para los sistemas BSD (Berkeley Software Distribution). Es una licencia de software libre permisiva, estando muy cercana al dominio público. La licencia BSD permite el uso del código fuente en software no libre. -22- Proyecto Final de Carrera Antonio Albiñana Martínez Figura 5. Aspecto del gestor gr fico de las bases de datos.á S EGURIDAD La seguridad en esta capa recae en mecanismos propios de la gesti n deó base de datos, como son el password de acceso, que en nuestro caso es “proyecto”. El resto de opciones de seguridad, as como las copias deí seguridad peri dicas de las bases de datos, la redundancia, etc. no formanó parte de este proyecto. La siguiente porci n de c digo muestra la conexi n a la base de datos.ó ó ó static public final String BD_URL="jdbc:postgresql://localhost/proyecto"; static public final String BD_USR="proyecto"; static public final String BD_PWD="proyecto"; ... Class.forName("org.postgresql.Driver"); db = DriverManager.getConnection(url,usr,pwd); -23- Proyecto Final de Carrera Antonio Albiñana Martínez pagina en blanco intencionada -24- Proyecto Final de Carrera Antonio Albiñana Martínez B ASES DE DATOS UTILIZADAS Para la gesti n y control de los datos necesarios se han creado distintas basesó de datos, la funcionalidad y descripci n de la mismas se detallan a continuaci n.ó ó Para cada base de datos se describe el prop sito de la misma, detallando aó continuaci n los campos que la componen con una explicaci n de los mismos.ó ó B ASE DE DATOS “ USUARIOS ” Es la encargada de contener los usuarios v lidos del sistema as como laá í informaci n de los mismos.ó Campos que la componen: • nombre_usu: Contiene el nombre nico de usuario v lido del sistema.ú á • clave: La clave de acceso al sistema. • telefono: Tel fono de contacto.é • direccion: Direcci n donde enviar la correspondencia.ó • email: Direcci n de correo electr nico.ó ó B ASE DE DATOS “H IST RICOÓ ” Contiene un relaci n de la actividad del alquiler de bicicletas. Cada vez que seó alquile una bicicleta aparecer n dos entradas, una para la recogida y otraá cuando sta se deje.é Campos que la componen: • idt: Identifica la transacci n, es decir recogida y devoluci n tendr n eló ó á mismo idt. Este dato es el “idSesion” del momento del alquiler. • usuario : Nombre del usuario. •fecha_coge: Hora y fecha de la acci n de alquilar.ó •fecha_deja: Hora y fecha de la acci n de devolver.ó •donde_coge: N mero de puesto de la acci n de alquilar.ú ó -25- Proyecto Final de Carrera Antonio Albiñana Martínez String datos=" … recopilacion de datos de la incidencia … consulta.escribirIncidenciaBD(datos+ datosTicketCookie+datosTicket, txtIncidencia); (...) Despu s de estas acciones, si el usuario no tuviera ninguna bicicleta alquilada seé presentar una pantalla en la que podr poner el puesto en el que se encuentra (siá á no lo introdujo en la pantalla de inicio), y seleccionar una de las bicicletas disponibles, o bien la pantalla de confirmaci n de devoluci n de la bicicleta.ó ó En ambos casos, si no existieran bicicletas o no existieran plazas libres para dejar la bicicleta, se presentar un listado de los puestos cercanos con el estado deá ocupaci n o el de plazas libres. La Figura 8 muestra un ejemplo de las pantallasó que se presentar n en ambos casos.á Figura 8: Bicicletas disponibles/sitios libres Una vez cumplimentada la acci n del alquiler, la aplicaci n devolver un ó ó á e-ticket con la informaci n necesaria para su control, registr ndose esta operaci n tambi n en eló á ó é sistema. La informaci n contenida en el óe-ticket es la siguiente: •Usuario: identificador del usuario ( nico en el sistema).ú -32- Proyecto Final de Carrera Antonio Albiñana Martínez •Fecha y Hora: Fecha y hora de la creaci n del óe-ticket. •Identificador de bicicleta: N mero de bicicleta alquilada.ú •Identificador de puesto de alquiler: N mero del puesto donde se recogiú ó la bicicleta. •Identificador de control: Es el “idTicket” y se corresponde con el “idSesion” abierta por el usuario al validarse en el sistema. Este dato no es visible para el usuario. T RANSACCIONES Denominaremos transacciones de servlets a aquella secuencia l gica, m s o menosó á forzada por la ejecuci n de los propios óservlets, que se ejecutan conjuntamente para poder lograr un nico o mismo fin.ú La existencia de estas transacciones deriva de la conveniencia de hacer modulares los servlets, y de evitar servlets con p ginas muy recargadas que presentan losá siguientes problemas: •m s dif ciles de programar y de depurar,á í •m s dif ciles de comprobar la existencia y correcci n de los datosá í ó introducidos o las acciones solicitadas por el usuario, •genera p ginas m s recargadas, que posiblemente ya no quepan en unaá á nica pantalla, por lo que al usuario le es m s dif cil de entender/darseú á í cuenta de todos los pasos o datos que se le piden para conseguir su fin, A continuaci n se van a detallar las principales transacciones existentes en eló proyecto, que son el alquiler de la bicicleta y su devoluci n. Ambas transaccionesó parten de la introducci n de los datos del usuario y del puesto en el que ste seó é encuentra. A LQUILER El alquiler se realiza enlazando tres servlets. El primero es el encargado de presentar las bicicletas disponibles en el puesto seleccionado. El segundo servlet presenta un resumen de la opci n seleccionada (podemos volver a seleccionaró otra bicicleta simplemente volviendo atr s en el navegador). Y el tercero termina laá -33- Proyecto Final de Carrera Antonio Albiñana Martínez transacci n con la presentaci n del resumen de la operaci n. La Figura 9 muestraó ó ó los efectos de esta operaci n.ó Elegir bicileta confirmar confirmaci n ó Figura 9:: Transaccion de Alquiler. D EVOLUCIÓN Recordemos que en el e-ticket guardado en el usuario se guarda tambi n uné resumen (generado por una funci n hash) del identificador de sesi n, de maneraó ó que no se puede saber realmente cu l es dicho identificador salvo que se realiceá de nuevo ese resumen con el dato original (que est en la base de datos) y seá compare. As pues, una vez comprobado el identificador de sesi n í ó al devolver la bicicleta, el e-ticket se borra del tel fono, registr ndose esta operaci n tambi n en el sistema.é á ó é En este caso, la devoluci n pone en marcha el proceso de facturaci n, calculandoó ó el precio del alquiler en funci n del tiempo de pr stamo de la bicicleta.ó é Por otro lado, tambi n se tiene que actualizar la base de datos del puestoé receptor de la bicicleta, para reflejar la disponibilidad de sta, y la base global deé usuarios para reflejar la nueva situaci n del usuario. La Figura 10 muestra dichaó transacci n de devoluci n de una bicicleta alquilada.ó ó -34- Proyecto Final de Carrera Antonio Albiñana Martínez Figura 10: Transacci n de devoluci n ó ó Recordamos que este tipo de e-ticket es temporal, ya que su validez tiene un periodo de tiempo limitado (puede caducar al d a siguiente, solo servir por laí ma ana, etc.). El mismo sistema podr a utilizarse para otro tipo de situacionesñ í similares, como pudieran ser la gesti n deó colas, la reserva de recursos, etc. Es decir, en todas aquellas aplicaciones en las que sea necesario un control del tiempo de entrada de un usuario en el sistema y la salida del sistema de dicho usuario. Tambi n es posible realizar, mediante accesos al registro de incidencias (tambi né é llamado hist rico), estad sticas de uso del sistema, tanto desde el punto de vista deló í usuario como desde el punto de vista de la gesti n de los recursos disponibles.ó As pues, cuando un usuario se identifica en el puesto, el sistema puede detectarí mediante dos procedimientos distintos si ste ya tiene una bicicleta en alquiler:é –Si existe una sesi n asociada a dicho usuario y comprobando que existe enó dicha sesi n un óe-ticket. –Si no existe sesi n se comprueba si hay una cookie con un óe-ticket. Este hecho podr a indicar que existi un fallo en el servidor mientras una bicicletaí ó est alquilada. Para asegurarlo, se comprueba en la base de datos si existeá una bicicleta en alquiler para ese cliente que no tiene devoluci n.ó Una vez realizada dicha comprobaci n, las acciones a realizar pueden ser dos:ó Recoger una bicicleta (dar de alta el alquiler): -35- Proyecto Final de Carrera Antonio Albiñana Martínez ✔Crear una sesi n y guardar en ella el óe-ticket. ✔Guardar una cookie del e-ticket para evitar la p rdida del mismoé por problemas en el servidor. ✔Grabar en la base de datos la acci n.ó Dejar una bicicleta (dar de baja el alquiler): ✔Grabar en la base de datos la acci n.ó ✔Borrar la cookie con la informaci n del óe-ticket. ✔Cerrar la sesi n.ó Si un usuario tuviera en alquiler una bicicleta, se produjera un fallo en el servidor y se perdiera la sesi n creada, ste dispone de la informaci n de la misma grabadaó é ó mediante cookies. Las acciones a realizar en este caso ser an:í ✔Recuperar el e-ticket desde la cookie. ✔Comprobar que dicho usuario tiene una bicicleta en alquiler en la base de datos (posee una entrada de recogida pero no una entrada de devoluci n).ó ✔Comprobar que el hash del identificador de la base de datos se corresponde con el guardado en el e-ticket recuperado. ✔Cerrar la sesi n.ó I NTEGRIDAD DEL E - TICKET Dada la particularidad de la aplicaci n, un aspecto fundamental es la integridad deó los datos guardados. Se han definido dos caminos para proporcionar la integridad del e-ticket, ambos en el mbito del usuario: uno para asegurar que el usuario posee uná e-ticket en caso de ca da del servidor y otro para los datos en s mismos a trav sí í é del idTicket contenido en el mismo, ya que este dato es una funci n hash deló original que se comprobar con la informaci n guardada en la base de datos.á ó Dado que el identificador de la sesi n es un óidentificador nico para cadaú transacci n, ó éste dato se incluye, como se ha mencionado, en el e-ticket como identificador del mismo. Esta acci n óasegura todav a m s la unicidad del parí á “usuario-idTicket”, ya que en el caso de la improbable repetici n del identificador deó sesi n, el usuario asegurar la unicidad de la acci n. La Figura 11 presenta laó á ó cookie del e-ticket guardada. -36- Proyecto Final de Carrera Antonio Albiñana Martínez Figura 11: cookie con la informaci n del e-ticket ó Mencionar que para el manejo de un e-ticket se ha creado la clase clsTicket. Esta clase se detalla posteriormente en el aparatado clases Java especiales, aunque podemos mencionar que mientras los datos de obtenci n de datos de dicha claseó son p blicos, como ú getUsuario(), getidTicket(), etc... los m todos deé grabaci n son privados, de manera que solo se pueden rellenar esos datos en laó inicializaci n de la clase, evitando as una manipulaci n de los mismos.ó í ó D ATOS EN EL CLIENTE Para evitar la p rdida de datos debidos a problemas con el servidor webé (principalmente por la p rdida de la sesi n ya iniciada), se guardan los datos comoé ó cookie en el cliente. De esta manera, al acceder de nuevo al sistema puede detectarse la existencia del e-ticket mediante la informaci n guardada en el cliente,ó y reconstruirlo con la informaci n que debe estar guardada previamente en eló servidor. A diferencia del e-ticket de sesi n (al que solo puede acceder el usuario validado),ó el e-ticket guardado como cookie no contiene el dato “idTicket” sino su resumen mediante una funci n de hash.ó Este e-ticket solo se consultar , como se ha comentado anteriormente, cuando laá sesi n se haya perdido, generalmente debido a problemas en el servidor, y m só á raramente por caducidad de la misma. Esto proporciona la seguridad de que es -37- Proyecto Final de Carrera Antonio Albiñana Martínez improbable que se pueda manipular el e-ticket entregado, ya que los datos correctos son los guardados previamente en la base de datos, y solo se puede acceder a ellos mediante el “idTicket”, dato que el cliente desconoce. En el caso de tener que recuperar los datos del e-ticket del cliente, el procedimiento ser a:í ✔Generar un e-ticket a trav s de las écookies del cliente. ✔Comprobar que existe una entrada de alquiler de ese usuario que no tiene asociada una acci n de devoluci n.ó ó ✔Contrastar el c digo óhash guardado en el e-ticket del cliente con el calculado del e-ticket guardado el base de datos que coincide con la situaci n anterior.ó ✔Comprobar que todos datos son iguales. Si no lo fueran, y bas ndoseá en que la informaci n correcta es la que existe en la base de datos, seó generar un informe del error para poder realizar un seguimiento delá incidente. E STRUCTURA DE LOS SERVLETS Todos los servlets que se han programado utilizan un patr n general a la hora deó generar la p gina HTML que se le mostrar al usuario. Se han identificado tresá á partes que contienen todas las p ginas HTML y, por ende, los áservlets deben mostrarlas y respetar sus mbitos, no solap ndose o desorden ndolos. As , todaá á á í p gina HTML tiene la siguiente estructura:á Cabecera HTML: lo nico que var a de una p gina a otra es la particularizaci n delú í á ó t tulo.í Parte central: es particular de cada servlet y lo que los diferencia, tanto por lo que muestran, por lo que ejecutan o por los datos y acciones que solicitan. Cierre de HTML: com n para todos los úservlets (b sicamente compuesto por lasá etiquetas </BODY></HTML>) Para aplicar sistem ticamente esta estructura, se ha implementado una clase Javaá denominada Cadenas, que se estudiar en su propio apartado.á -38- Proyecto Final de Carrera Antonio Albiñana Martínez D EPENDENCIAS EXTERNAS En los servlets presentados se importan las siguientes clases: import javax.servlet.ServletException: para tratar las excepciones de los servlets import javax.servlet.http.HttpServlet: para gestionar el protocolo de la comunicaci nó import javax.servlet.http.HttpServletRequest: para recoger la informaci n enviada por el contenedoró import javax.servlet.http.HttpServletResponse: objeto donde se escribe la respuesta para devolv rselas al clienteé import javax.servlet.http.HttpSession: para poder utilizar las sesiones S ESIONES Las sesiones se utilizan con dos objetivos: •Primero, para el funcionamiento del control de usuarios registrados. De esta manera solo los usuarios v lidos tendr n una sesi n. á á ó •Segundo, para el control del e-ticket. Dado que el e-ticket es temporal, steé estar activo mientras dure la sesi n. De esta manera se utilizar elá ó á 'idSesion' como identificador nico del úe-ticket en curso. Como veremos posteriormente, ste se guarda tambi n con una cookie en el cliente. é é Con este fin se ha utilizado el objeto session proporcionado por el servlet. Para ello hay que importar httpSession (el de antes). De esta manera, se puede controlar tanto si el usuario actual est identificado (o no) como el alquiler de laá -39- Proyecto Final de Carrera Antonio Albiñana Martínez bicicleta. La sesi n se crea y accede con :ó sesion = request.getSession(true) y al crearse graba una cookie, que en este caso tiene este aspecto: Figura 12: Cookie asociada a la sesi nó C LASES J AVA ESPECIALES L A CLASE C ADENAS Para ayudar a construir las p ginas tal como se ha indicado en “Estructura de losá servlets”, se crea una clase Java, denominada Cadenas, que proporciona m todosé est ticos que permiten conseguir esta estructura modularmente. Para cada parte seá invoca a su respectivo m todo, que genera autom ticamente el mismo c digo paraé á ó todos los servlets, con las personalizaciones ya indicadas (t tulo en la cabeceraí). Evidentemente, la parte central no tiene un m todo universal para su contenido, peroé s que lo tiene para marcar su inicio y su finalizaci n, al objeto de estandarizar laí ó estructura y formato. Tambi n seé ha utilizado para incluir procedimientos est ticos de utilidad para escribirá -40- Proyecto Final de Carrera Antonio Albiñana Martínez fechas, horas, etc. A continuaci n se describen brevemente los m todos est ticos de la clase ó é á Cadenas que sirven para generar la estructura b sica HTML de los áservlets: Cadenas.htmlIni(String nombrePagina, int indiceSeleccion, HttpSession sesion) M todo padre que invoca a otros, y que genera la parte superior de laé p gina HTML, concretamente, la cabecera HTML y la inserci n delá ó logotipo. Cadenas.htmlLogo(String nombrePagina): Genera la cabecera (<head></head>) del documento HTML, declara el <div id='principal'>, y tambi n a ade el primer é ñ <div class='titulo'> que inserta un logotipo de la p gina HTML.á Recibe como par metro una cadena, ánombrePagina, que sirve para mostrar informaci n sobre qu p gina es cada una en el t tulo, para que, poró é á í ejemplo, se muestre esa informaci n en el t tulo de la ventana deló í navegador Web. Cadenas.htmlIniDivCentral(): Simplemente declara el tipo <div> para la parte program tica del áservlet. Cadenas.htmlFinDivCentral(): Similarmente al anterior, termina el <div> central, el de la parte program ticaá del servlet. Cadenas.htmlFin(): El que se invoca al final, para terminar la p gina HTML.á De esta manera la composici n de una p gina sin informaci n din mica generadaó á ó á por el servlet se realiza de una manera sencilla y limpia: protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); pagOK = Cadenas.htmlIni("Inicio", “”, “”,””); -41- Proyecto Final de Carrera Antonio Albiñana Martínez } catch (IOException e) { e.printStackTrace(); } finally { try { if (null != fichero) fichero.close(); } catch (Exception e2) { e2.printStackTrace(); } } Finalmente, un ejemplo de entrada del registro de sucesos: 20120919_0232 OcupacionPuestosCercanos.doPost [01314DE9EB48A9793BEF7A60063C3882] toni Buscando Puestos cercanos al puesto (33) L A CLASE T ICKET Aprovechando la capacidad de los servlets, esta clase es la encargada de gestionar la informaci n referente a un ticketó. Recordamos que el e-ticket tiene los siguientes datos ; •Usuario, Fecha y Hora, Identificador de bicicleta, Identificador de puesto de alquiler, Identificador de control. Mencionar que mientras la informaci n de obtenci n de datos son p blicos, comoó ó ú getUsuario(), getidTicket(), etc... los m todos de grabaci n son privados,é ó de manera que solo se puede rellenar esos datos en la inicializaci n de la clase,ó evitando as una manipulaci n del mismo una vez se ha creado,í ó clsTicket T=new clsTicket(idSesion,cuando,puesto,numBici,usuario) Tambi n se han reescrito los siguiente m todos heredados para facilitar el manejoé é del e-ticket. A continuaci n se detallan estos m todos.ó é public boolean equals(Object Obj) Compara si dos e-ticket son iguales. Recordemos que el e-ticket guarda como idTicket el hash del original (que est en la base de datos), para evitará -48- Proyecto Final de Carrera Antonio Albiñana Martínez un orden de comparaci n determinado. El m todo equals realiza las tresó é comparaciones posibles. Para dos tickets T2 y T1 –Si T2.isTicket==T1.idTicket –Si T2.idTicket.hash()==T1.idTicket –Si T1.idTicket.hash()==T2.idTicket Si se cumple una de estas tres condiciones sus idTicket ser n iguales.á public boolean equals(Object Obj){ clsTicket T2=(clsTicket) Obj; boolean dev=( T2.getnumBici().equals(this.numBici) && T2.getPuesto().equals(this.puesto) && T2.getCuando().equals(this.cuando) && ( T2.getidTicket().equals(this.idTicket) || T2.mismoHash(this.idTicket) || this.mismoHash(T2.getidTicket()) ) ); return dev; } public boolean mismoHash(String HashIdTicket){ try{ return ( this.idTicket.hashCode()== Integer.parseInt(HashIdTicket) ) ; ... public String toString() Imprime la informaci n del óe-ticket. F ILTROS Los filtros son unos servlets especiales que pueden insertarse transparentemente en medio de una cadena de petici n-respuesta en el contenedor de ó tomcat. Tienen la propiedad de que permiten reaprovechar servlets anteriores sin precisar modificaci n,ó a adiendo c digo suplementario que dota a la nñ ó ueva cadena de ejecuci n deó -49- Proyecto Final de Carrera Antonio Albiñana Martínez caracter sticas adicionales deseables. Varios filtros pueden concatenarse en la cadenaí de llamadas, por lo que su dise o puede ser modular: cada filtro a ade una nuevañ ñ capa de funcionalidad propia e independiente de la de los dem s. Pueden aparecerá tanto a la entrada de un servlet existente, entre el proceso de petici n del cliente yó su efectiva ejecuci n, como a la salida del mismo, y previo al env o de respuesta aló í cliente. En este proyecto se ha identificado la conveniencia de utilizar filtros, en concreto se ha implementado FiltroAcceso.java : •FiltroAcceso: Intercepta las peticiones del usuario para la realizaci n deló Alquiler/Devoluci nó. Desde la vista del sistema se comprueba si el usuario est autentificado en el sistema, dáej ndolo continuar siá efectivamente lo est . Por el contrario, el filtro redirige la petici n a laá ó p gina de autentificaci n (inicio de sesi n, á ó ó servlet IniciarSesion) si no estaba todav a autentificado.í Para la implementaci n del filtro denominado ó FiltroAcceso se pueden seguir dos caminos diferentes, pero convergentes en el mismo resultado: uno manual, y otro utilizando las caracter sticas propias de í Eclipse, el cual, evidentemente, es el que se recomienda para un uso futuro y es el que se explica a continuaci n.ó Situ ndose en el paquete correspondiente (alquilerá), se procede a crear un filtro mediante el asistente, utilizando para ello el bot n derecho del rat n, seleccionandoó ó la opci n “Create”, desmarcando la opci n “utilizar uno existente”, definiendo eló ó nombre y pulsando “next”. A continuaci n, se realizan las siguientes acciones:ó •En “filter Mappings” se a aden las clases donde se aplicar dicho filtroñ á (clic en “next“). •Finalmente, como se desea extender la interfaz “Filter” se cierra el asistente (clic en “Finish”). Una vez generada la nueva clase “NombreDelFiltroIntroducido”, destacamos estos dos m todos:é •init(): Aqu se inicializar n las variables, caso de ser necesarias.í á •doFilter(): Acciones que realizar el filtro, permitiendo su terminaci ná ó normal o su redirecci n en caso de que determinemos que no seó -50- Proyecto Final de Carrera Antonio Albiñana Martínez cumplen determinadas condiciones. Un ejemplo de redirecci n a la p gina inicial tras intentar una operaci n no permitidaó á ó ser a:í response.sendRedirect("InicioSesion"); De forma paralela, por cada filtro y servlet alcanzado, el fichero “web.xml” muestra este aspecto: <filter-mapping> <filter-name>FiltroDePrueba</filter-name> <servlet-name>Buscar</servlet-name> </filter-mapping> C ONFIGURACIÓN DEL F ILTRO A CCESO . JAVA Como debe invocarse con car cter previo, la configuraci n de este filtro consisteá ó en indicar que debe filtrar anticipadamente a los siguientes servlets: •/SeleccionarBici.java, /ConfirmarBiciSeleccionada.java y /AlquilarBici,java en el caso de Alquiler •/ConfirmasDevolverBici.java y /DevolverBici.java en el caso de devoluci n.ó A continuaci n se muestra la parte del fichero óweb.xml encargado de dicha configuraci n:ó <filter> <display-name>FiltroAcceso</display-name> <filter-name>FiltroAcceso</filter-name> <filter-class>FiltroAcceso</filter-class> </filter> <filter-mapping> <filter-name>FiltroAcceso</filter-name> <url-pattern>/SeleccionarBici</url-pattern> <url-pattern>/ConfirmarBiciSeleccionada</url-pattern> <url-pattern>/AlquilerBici</url-pattern> </filter-mapping> -51- Proyecto Final de Carrera Antonio Albiñana Martínez pagina en blanco intencionada -52- Proyecto Final de Carrera Antonio Albiñana Martínez R EFERENCIAS [ Fundaci n Apache ]ó http://tomcat.apache.org/tomcat-6.0-doc/index.html [ eclipse.org ] www.eclipse.org/documentation/ http://www.eclipse.org/forums/ [ postgresSQL ] http://wiki.postgresql.org/wiki/Main_Page [ otros ] http://memex.dsic.upv.es/pbs/Documentacion/ www.forosdelweb.com -53- Proyecto Final de Carrera Antonio Albiñana Martínez pagina en blanco intencionada -54- Proyecto Final de Carrera Antonio Albiñana Martínez P ALABRAS CLAVE apache tomcat, cookie, dispositivo móvil, eclipse, java, nfc, postgresql, servltes, sesión, servidor web -55-