Servlets Servlets son módulos que extienden a servidores “java-enabled” orientados a request/response, como por ejemplo Servidores Web Un servlet puede ser el responsable de tomar datos de una “forma” HTML y aplicar un método para actualizar las bases de datos de la una compañía de acuerdo a ellos.

Trabajo Preliminar El paquete javax.servlet provee interfaces y clases que permiten escribir y compilar servlets No viene con el j2sdk, es necesario bajar el .jar respectivo y hacerlo visible para compilar los programas Por su parte, tambien los servidores deben poder saber recibir requerimientos para servlets y saber interpretarlos Cada servidor de servlets tiene sus propias reglas, En la mayoría de los casos hay que ponerlos en un directorio específico En tomcat, por ejemplo, si se ponen en raiz\webapps\examples\web-inf\classes pueden ser contactadas por http://host:port/examples/servlet/servletname Muchas veces es necesario tener un archivo (xml en tomcat) donde se pone el alias de los servlets y sus parámetros de inicialización

La Anatomía de un Servlet Un nuevo tipo (clase) de servlet es especificado extendiendo la clase HttpServlet Existen métodos predefinidos: init() es llamado por el servidor web cuando el servlet se “sube” la primera vez (el momento en que sucede esto puede variar, dependiendo del servidor) doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException se llama cuando el servlet es invocado con una petición Http GET, que es la normal cuando se contacta un serv. doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException se ejecuta cuando el servlet fue invocado con una petición Http POST

Anatomía de un servlet Una petición GET se genera siempre cuando una petición http es ingresada en el browser Por ejemplo, http://www.yahoo.com implica mandar al servidor web un string con el comando „GET index.html Httpx.x“ Cuando el servlet se llama por primera vez, se inicializa y 4-6 threads son levantados para atender a cleintes en paralelo cuando vayan apareciendo, Para ahorrar tiempo En la mayoría de los casos los servlets son contactados a través de forms en páginas html. En estos casos es posible especificar en los parámetros una petición POST

La interfaz ServletRequest HttpServletRequest es la clase de uno de los parámetros con que el servidor llama a los métodos del servlet, Esta clase implementa la interfaz ServletRequest provee acceso a: Información que viene del cliente, como por ejemplo nombre de los parámetros pasados y sus valores, el protocolo usado, el nombre del computador del cliente y del servidor que lo atiende, etc. El input stream, ServletInputStream. Los Servlets usan este input stream para recibir datos de los clientes que envían con protocolos de aplicaciones como los métodos POST y PUT de HTTP.

La interfaz ServletResponse HttpServletResponse es la clase con el que servidor llama a los métodos del servlet. Implementa la interfaz ServletResponse la cual da al servlet métodos para responder al cliente: Establecer el tipo MIME de la respuesta que se le mandará al cliente El output stream ServletOutputStream y un Writer con el cual van a mandar datos al clientes.

Primer ejemplo El servlet puede ser contactado directamente por la siguente expresión en el browser: http://grafica05.dcc.uchile.cl/examples/servlets/SimpleServlet Esto causará que el método doGet sea llamado El servlet responderá escribiendo en la pagina del browser que lo invocó una frase pequeña

SimpleServlet SimpleServlet extiende la clase HttpServlet la cual implementa la interfaz Servlet. Sobreescribe el método doGet de la clase HttpServlet. doGet es llamado por el método service (no se ve) cuando el servlet fue contactado por un GET request (default HTTP request method)  Dentro del método doGet, El request del cliente está representado por un objeto HttpServletRequest. La respuesta al cliente está representada por un objeto HttpServletResponse Como se le enviará texto al cliente, la respuesta se manda con un objeto Writer obtenido del objeto HttpServletResponse.

Un segundo ejemplo Vamos a implementar un web counter Va a contabilizar cuántas veces un servlet de esta clase ha sido creado (init) Cuántas veces han sido llamadas todas las instancias Cuantas veces ha sido llamada la instancia que se contacto ver Count.java

Usando parámetros de inicialización del archivo de configuración En todos los servidores hay un archivo de configuración escrito en XML Este se edita “a mano” o con una herramienta apropiada En este archivo se pueden especifcar parámetros para los servlets Permiten parametrizar servlets sin recompilarlos En Tomcat 4.1 este archivo se ubica en webapps\examples\WEB-INF\web.xml ver ShowParameters.java

Parámetros desde el cliente Es posible pasar parámetros en la línea de invocación URL http://host:port/servlet?param1=value1&param2=value2.. El servlet puede preguntar por los valores de los parámetros si conoce el nombre de ellos de la siguente manera: String value = req.getParameter(param1); String[] value = req.getParameterValues(param1) String value = req.getParameterValues(param1)[0] es equivalente a lo primero si es un parámetro de un solo valor o se recuperará el primero de los valores de un parámetro multivalorado Parámetros pueden ser solamente strings ver ServletParameter1.java invocarlo con http://host:port/ServletParameter1?name=nelson

Lo ideal es hacerlo con Forms Una Form es una página html que puede contener objetos gráficos para recolectar información la que manda al servidor como una URL: Podemos usar el mismo servlet !!!! mirar ServletParameter1.html Ejemplo 1: ShowParametersRequest.java invocado por ShowParametersPostForm.html Ejemplo 2: SubmitResume.java invocado por SubmitResume.html

Los encabezados del request y response Proveen información de alto nivel desde/hacia el cliente En el caso del request, permite averiguar características interesantes acerca del cliente En el caso del response, permite definir la forma como se le va a enviar la información al browser En general permiten hacer mucho más efectivo y eficiente el diálogo con el cliente En el caso del request, existen métodos getXXX o getHeader(xxx) para averiguar información En el caso del response, existen métodos setHeader(xxx) o setXXX para definir la forma de la respuesta. Muchas veces es necesario combinar ambos para dar una respuesta adecuada

Algunos get para el request getCookies(): para recibir las cookies que pueda haber mandado el cliente getAuthType(): se usa para clientes tratando de acceder una página para la cual se quiere tener una password getRemoteHost(): el host del cleinte getMethod(): el método con el cual se contacto al servidor (GET, POST, etc..) getProtocol(): versión del protocolo HTTP que usa el cliente getHeaderNames(): retorna todos los nombres de los headers que mandó un cleinte

Algunos xxx para el getHeader(xxx) Accept: qué tipos MIME puede recibir (entiende) el cleinte Accept-Charset: qué conjunto de caracteres está usando Accept-Encoding: que algoritmos de codificación acepta Accept-Language: lenguaje (en-us, sp, ge, ..) Authorization: para identificar a clientes con una página protegida Host: el computador del cleinte Referer: la URL de la página que generó el contacto Cookie: para obtener cookies Connection: dice si el cleinte puede manejar conexiones persistentes (por ejemplo para mandar archivos)

Algunos set para el response setContentType(xxx): indica el tipo MIME de la respuesta que se le va a mandar setContentLength(xxx): indica el tamaño (se usa para traspasar información en bytes) addCookie(): para mandar cookies con información al cliente sendRedirect(): para redirigir el requerimiento a otro URL setHeader(xxx,xxx) forma más general setIntHeader(xxx,xxx) cuando el segundo argumento es un entero (ahorra la conversión)

Algunos xxx para el setHeader(xxx,xxx) Content-Type: algun tipo MIME como “image/gif” Content-Length: largo de lo que se va a mandar (para bytes) Connection: poniendo un valor “close” va a prohibir el uso de conexiones persistentes (default: keep-alive) Content-Encoding: codificación Content-Language: lenguaje Cache: como se debe manejar el cache en el cliente (ej, no-cache, no-store, must-revalidate, max-age=xxxx, Refresh: indica cada cuanto debe autorefrescarse la pagina www-Authenticate: para manejar el acceso a páginas con passwords

Ejemplos de manejo de la información desde/hacia el cliente Ver ShowRequestHeaders Ver ProtectedPage Ver SnoopServlet?par1=val1&par2=val2 ver Ping

Session Tracking Session tracking es un mecanismo que pueden los servlets para mantener información acerca del estado de los requests de un usuario durante una sesión Una sesión es un diálogo de una instancia de un browser cliente con el server en un período de tiempo limitado (normalmente 30 minutos). Se pueden asociar objetos de información a la sesión, los cuales se conservan en el servlet La sesión no la maneja el programador sino el el servidor web, el programador la consulta Ver SessionServlet

Algunos métodos HttpSession sesion = request.getSession(true) crea un objeto sesión si no existía sesion.isNew()retorna verdadero si la sesión se creó recientemente sesion.putAttribute/Value(String nombre, Object valor) asocia a la sesión un par nombre-valor (value se usa hasta v2.2) Object o = sesion.getAttribute/Value(“nombre”)retorna el objeto asociado a ese nombre para la sesión sesion.removeAttribute/Value(“nombre”)elimina el objeto asociado a ese nombre para la sesión Enumeration[]valores = sesion.getAttributeNames() String[]valores = sesion.ValueNames() retorna un arreglo/enumeración de nombres de atributos/valores que hay en la sesión long l = sesion.getCreationTime()retorna el tiempo (en milisegundos desde el 1.1.70 0:0:0 ) en que fue creada Long l = sesion.lastAccessedTime() retorna el tiempo del último acceso (en milisegundos) sesion.setMaxInactiveInterval(int seconds)pone el máximo intervalo antes de que automáticamente se destruya la sesión

Usando Cookies Cookies son otra forma con la cual el servlet puede seguirle la pista a un cliente A través de una cookie el selvlet puede mandar información al cliente para que la guarde y la entregue cada vez que lo contacta. Los Servlets envían cookies a los clientes agregando campos al encabezado de respuesta Http que se envía. Los clientes automaticamente retornan cookies cuando contactan a un servidor mandándolo como campos adicionales en los encabezados HTTP request. Cookies los cookies tienen un nombre y un valor (ambos strings) Adicionalmente puede guardar un comentario Un server puede pasar más de una cookie a un cliente.

Usando Cookies Para mandar una cookie 1. Instanciar un objeto Cookie 2. Poner atributos (par nombre-valor) 3. Mandar la cookie Para recuperar la información de una cookie, 1. Recuperar todas las cookies del cliente 2. Encontrar la cookie que se necesita por su nombre 3. Recuperar su valor

Ejemplos de Cookies El primer ejemplo (Cookies.java) muestra los tiempos cuando el cliente contactó por primera vez al servlet (vía método doGet) y el tiempo cuando lo contactó oprimiendo un botón que llama al método doPost El segundo ejemplo muestra cómo se le puede poner tiempos de permanencia (o validez) a una cookie.

¿ Cookies o Sessions ? Con sessions la información la almacena y administra el servidor por lo que el servidor tiene un estado que tiene que administrar cuidadosamente Con Cookies es el cliente el que tiene la información, lo que implica que esta va y viene cada vez que se contacta al servidor El cliente puede prohibir el uso de cookies si quiere