INTRODUCCIN El seguimiento de sesin es un mecanismo que los servlets utilizan para mantener el estado sobre la serie de peticiones desde

un mismo usuario (esto es, peticiones originadas desde el mismo navegador) durante un periodo de tiempo. Las sesiones son compartidas por los servlets a los que accede el cliente. Esto es conveniente para aplicaciones compuestas por varios servlets. Para utilizar el seguimiento de sesin debemos: Obtener una sesin (un objeto HttpSession) para un usuario. Almacenar u obtener datos desde el objeto HttpSession. Invalidar la sesin (opcional).

NDICE Obtener una sesin . Almacenar y obtener datos desde la sesin Invalidar la sesin . Manejar todos los navegadores Conclusiones Bibliografa 2 2 3 4 6 6

DESARROLLO Obtener una Sesin El mtodo getSession del objeto HttpServletRequest devuelve una sesin de usuario. Cuando llamamos al mtodo con su argumento create como true, la implementacin crear una sesin si es necesario. Para mantener la sesin apropiadamente, debemos llamar a getSession antes de escribir cualquier respuesta. Si respondemos utilizando un PrintWriter, entonces debemos llamar a getSession antes de acceder al PrintWriter, no slo antes de enviar cualquier respuesta.

Almacenar y Obtener Datos desde la Sesin El Interface HttpSession proporciona mtodos que almacenan y recuperan: Propiedades de Sesin estndar, como un identificador de sesin. Datos de la aplicacin, que son almacenados como parejas nombre-valor, donde el nombre es un string y los valores son objetos del lenguaje de programacin Java. Como varios servlets pueden acceder a la sesin de usuario, deberemos adoptar una convencin de nombrado para organizar los nombres con los datos de la aplicacin. Esto evitar que los servlets sobrescriban accidentalmente otros valores de la sesin. Una de esas convenciones es servletname.name donde servletname es el nombre completo del servlet, incluyendo sus paquetes. Por ejemplo, es.uah.comunica.estado es una cookie con el servletname es.uah.comunica y el name estado.

Como un objeto puede ser asociado con una sesin, el ejemplo anterior autentica al usuario, para ello comprueba si ha iniciado sesin anteriormente viendo si el objeto asociado a la sesin es nulo o no. En caso de serlo crear la sesin con un nuevo objeto Usuario cuyos datos los recuperar con la instruccin getParameter del objeto HttpServletResonse. Una sesin puede ser designada como nueva. Una sesin nueva hace que el mtodo isNew de la clase HttpSession devuelva true, indicando que, por ejemplo, el cliente, todava no sabe nada de la sesin. Una nueva sesin no tiene datos asociados. Invalidar la Sesin Una sesin de usuario puede ser invalidada manual o automticamente, dependiendo de dnde se est ejecutando el servlet. (Por ejemplo, el Java Web Server, invalida una sesin cuando no hay peticiones de pgina por un periodo de tiempo, unos 30 minutos por defecto). Invalidar una sesin significa eliminar el objeto HttpSession y todos sus valores del sistema. Para invalidar manualmente una sesin, se utiliza el mtodo invalidate de la clase HttpSession. Algunas aplicaciones tienen un punto natural en el que invalidar la sesin.

Manejar todos los Navegadores Por defecto, el seguimiento de sesin utiliza cookies para asociar un identificador de sesin con un usuario. Para soportar tambin a los usuarios que acceden al servlet con un navegador que no soporta cookies, o si este est programado para no aceptarlas, se debe utilizar reescritura de URL en su lugar. Cuando se utiliza la reescritura de URL se llama a los mtodos que, cuando es necesario, incluyen el ID de sesin en un enlace. Debemos llamar a esos mtodos por cada enlace en la respuesta del servlet. El mtodo que asocia un ID de sesin con una URL es HttpServletResponse.encodeUrl. Si se redirecciona al usuario a otra pgina, el mtodo para asociar el ID de sesin con la URL redireccionada se llama HttpServletResponse.encodeRedirectUrl. Los mtodos encodeUrl y encodeRedirectUrl deciden si las URL necesitan ser reescritas, y devolver la URL cambiada o sin cambiar. (Las reglas para las URLs y las URLs redireccionadas son diferentes, pero en general si el servidor detecta que el navegador soporta cookies, entonces la URL no se reescribir). Por ejemplo, el siguiente servlet devuelve un catlogo con dos enlaces para cada libro. Un enlace ofrece detalles sobre el libro y el otro ofrece al usuario aadir el libro a su hoja de pedidos. Ambas URLs son reescritas:

Si el usuario pulsa sobre un enlace con una URL re-escrita, el servlet reconoce y extrae el ID de sesin. Luego el mtodo getSession utiliza el ID de sesin para obtener el objeto HttpSession del usuario. Por otro lado, si el navegador del usuario no soporta cookies y el usuario pulsa sobre una URL no re-escrita, se pierde la sesin de usuario. El servlet contactado a travs de ese enlace crea una nueva sesin, pero la nueva sesin no tiene datos asociados con la sesin anterior. Una vez que un servlet pierde los datos de una sesin, los datos se pierden para todos los servlets que comparten la sesin. Debemos utilizar la re-escritura de URLs consistentemente para que nuestro servlet soporte clientes que no soportan o aceptan cookies.

Conclusin El seguimiento de sesiones en la actualidad es muy importante para una pgina web, ya que nos ayudara a llevar un mejor control de los usuarios y el contenido al que ellos pueden o no acceder dentro de las pginas web

Bibliografa Eric Jendrock et al. The Java EE 6 Tutorial (2013). http://docs.oracle.com/javaee/6/tutorial/doc/ Building Web Apps in Java: Beginning & Intermediate Servlet & JSP Tutorials. http://courses.coreservlets.com/Course-Materials/csajsp2.html Documentacin oficial: o Java EE Specifications http://www.oracle.com/technetwork/java/javaee/tech/index.html o o API specification for version 6 of Java EE http://docs.oracle.com/javaee/6/api/