Clase 11

Taller de Sistemas de
Información 2
Clase 11
Desarrollo web
¿Que hace el web server?
 Toma un “pedido” del cliente, y le devuelve
algo a cambio
 En palabras mas tecnicas, permite que un
cliente envie un “request” solicitando un
“resource”
 El web server toma el request, busca el
recurso, y le devuelve algo al cliente
INCO - Facultad de Ingeniería – Montevideo, Uruguay 2

 El caso mas comun, es que ese recurso sea
una pagina HTML, aunque puede ser una
imagen, un sonido, un video, etc, etc…
 Puede suceder que el recurso no se
encuentre alli, en cuyo caso aparece el
familiar “404 Not found”

 Cuando nombremos “server”, nos estamos
refiriendo tanto a la maquina fisica, como al
software que ejecuta en esta

Cliente y servidorrequest
Servidor
Cliente
response

¿Que hace el web client?
 El web client permite que un usuario “solicite”
algo en el servidor, y muestra el resultado de
esa solicitud a dicho usuario
 En general, cuando hablamos de clientes,
nos referimos tanto al browser como al
humano que esta atrás del mismo (si lo hay)

 El browser es la pieza de software que sabe
como comunicarse con el web server
 Ejemplos clasicos son Internet Explorer,
Firefox, Opera, etc.

 La solicitud del cliente, se denomina
“request”, y contiene entre otras cosas, el
nombre y la direccion de lo que el cliente
esta buscando
 La respuesta a la solicitud, se denomina
“response” y en general contiene el
documento solicitado por el cliente, o los
codigos de error apropiados si no pudimos
encontrar lo que buscabamos

 Request…
request
1 2 3
Recursos que
Servidor
Cliente buscamos

 Response…
response
Recursos que
Cliente Servidor buscamos
Usuario
3 2 1
Rendereamos Seleccionamos
“index.html”
“index.html”

HTML
 Cuando un servidor contesta una solicitud,
en general esta contiene codigo HTML
 Hyper Text Markup Language
 El HTML instruye al browser para que

construya la interfaz al usuario
 Todo browser entiende HTML, aunque puede
pasar que alguno obsoleto, no entienda las
nuevas versiones de HTML (4)

HTML – Curso super acelerado
 La meta de HTML es definir un documento
de texto, y agregarle “tags” que le indiquen al
navegador, como debe presentar la
informacion en el documento
 Existen cientos de tags, y mas aun atributos
para dichas tags
 Algunas de las mas usadas son:

  comentario
 <a> anchor, en general para poner
hyperlinks
 <align> alineacion de contenido
 <body> define los limites del cuerpo del

documento html
 <br> salto de linea
 <center> centrado de contenido

 <form> formulario, que suele proveer campos
de entrada de informacion
 <h1> cabezal de primer nivel
 <head> define los limites del header del
documento
 <html> define los limites del documento html
 <input type> define un campo de entrada
 <p> un nuevo parrafo
 <title> titulo de la pagina html

<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>Hello World Demonstration Document</title>
</head>
<body>
<h1>Hello, World!</h1>
<p>This is a minimal "hello world" HTML document.
It demonstrates the basic structure of an HTML file
and anchors.</p>
<p>For more information, see the HTML Station at:
<a href= "http://www.december.com/html/">
http://www.december.com/html/</a>
</p>
</body>
</html>

HTTP
 La mayoria de las conversaciones
establecidas entre cliente y servidor, se
hacen a traves del protocolo HTTP
 Hyper Text Transfer Protocol
 Este permite conversaciones simples de la

forma request/response
o HttpRequest y HttpResponse
 Todo web server, habla HTTP

HTTP
 HTTP corre sobre TCP/IP
 TCP/IP se encarga de proveer conectividad
entre el cliente y el servidor
 HTTP agrega caracteristicas especiales de la
web al protocolo
 La secuencia de funcionamiento de HTTP es
simple, el cliente envia un request, y el
servidor contesta con un response

HTTP Request
 Esta compuesto por una serie de elementos
que permiten al servidor hacer su trabajo
 HTTP method
o Representa la accion a realizar
 La pagina que estamos accediendo
o URL
 Form parameters
o Como los argumentos a un metodo

HTTP Response
 Esta compuesto por una serie de elementos
que permiten al cliente hacer su trabajo
 Status code
o Indica si el procesamiento fue exitoso o no
 Content type
o Define que tipo de recurso estamos pidiendo,
texto, imagen, video, html
 Contenido
o El HTML, la imagen, el pdf

HTTP Response
 En general este contiene dentro de la
seccion de contenido, el codigo HTML que el
navegador debera mostrar
 El web server agrega informacion extra
(headers) que ayudan al navegador a
procesar mejor este contenido

HTTP Response
 Para el que le interese, HTTP es un estandar
de la IETF, RFC 2616

HTTP Method
 Uno de los elementos mas importantes del
request, es el HTTP METHOD
 No son como los metodos Java, pero su
significado es similar
 El metodo le indica al web server el tipo de
request que se esta enviando, y como
deberan procesarse los datos enviados con
el mismo

HTTP Method
 Existen multiples metodos HTTP
o Los dos mas populares y conocidos son HTTP GET y
HTTP POST
 GET es el mas sencillo de los metodos. Su
significado es el de traer del servidor, un
determinado recurso
 POST es una version poderosa de GET. No solo
sirve para recuperar informacion del server, sino
que tambien permite enviar datos al mismo

HTTP Method
 Es posible tambien enviar datos al web
server utilizando GET, sin embargo no es
recomendable por diversos factores
o La cantidad de caracteres enviados en un
GET esta limitada (muy) y depende del web
server
o Los datos enviados por GET son anexados a
la URL, con la forma “?par1=val1&par2=val2”

HTTP GET – Ejemplo
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,

application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
.NET CLR 2.0.50727; InfoPath.2)
Host: www.google.com
Connection: Keep-Alive
Cookie:
PREF=ID=ada13ca003925e80:TB=2:TM=1164367862:LM=1164386991:DV=
AA:GM=1:S=UVItq66o_56krIzv

HTTP POST – Ejemplo
POST /mail/channel/bind?
at=22ab3380b484ab95-1126ba7a637&VER=2&SID=BABEF5C7B0D72416&RI
D=45783&zx=4bc0qik320l8&it=1382581 HTTP/1.1
Host: mail.google.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11)
Gecko/20070312 Firefox/1.5.0.11
Keep-Alive: 300
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 52
Cookie:
GX=DQAAAHgAAAABhFLl5OqJU4RlNxizv4wDi_25wO9MoRsulgEi6Z0ggQ83r
oKcygiL6X1fJIJqX2KuNx0NzM19V8jU-
Nd7VhxENw_hbLsYtm6Zb1AxZAuHdP5vzs-
GVzJc6l4jJhmBdJHsg1Iilc71hBLklparXNFV_t1LNJuQqHg4yhg4LABKUA

HTTP Response
 La respuesta del servidor esta compuesta
por dos partes, un header y un body
 El header tiene informacion de control que
indica si la solicitud fue exitosa, que tipo
de recurso estamos devolviendo, etc.
 El body contiene los datos propiamente
dichos que se devuelven

HTTP Response – Ejemplo
HTTP/1.1 200 OK
Date: Tue, 08 May 2007 13:47:13 GMT
Server: NOYB
Last-Modified: Wed, 18 Apr 2007 21:06:48 GMT
ETag: "5b436-ec6-76e4ea00"
Accept-Ranges: bytes
Content-Length: 3782
Keep-Alive: timeout=5, max=200
Connection: Keep-Alive
Content-Type: text/html; charset=ISO-8859-1
<html></div></td><ul><center>
<table width="465" border="0" cellspacing="0" cellpadding="0">
<tr> <td><img border="0" src="imagenes/crok2e.jpg" width="465" height="380"
usemap="#menu"></td></tr></table></center></ul></div></html>

URL
 Uniform Resource Locator
 Todo recurso en la web, tiene una
direccion unica, en forma de una URL
o http://localhost:81/cervezas/buscar/seleccion.html
 Esta URL esta compuesta por diversos
elementos:

URL
 Protocolo: http://
 Server: localhost
 Port: 81
 Path: cervezas/buscar
 Resource: selección.html
 Query string: No aparece, pero representa

parametros enviados por el GET
o ?param1=value1&param2=value2
Web Servers
 Los servidores web, estan especialmente
pensados para sevir contenido estatico
 Una pagina estatica simplemente esta
dentro de un directorio
 El servidor la localiza y la devuelve “as-is”
 Todos los clientes ven la misma pagina
 ¡Sin embargo, a veces esto no basta!

Web Servers – Contenido
dinamico
 El web server esta dedicado a servir contenido
estatico.
 Sin embargo a veces puede ser necesario tener
paginas generadas “just in time”, que muestren
informacion obtenida de alguna fuente dinamica
de datos

Web Servers – Persistencia
 Un web server no esta pensado para persistir
los datos en el servidor, lo cual puede implicar
escribir datos en archivos o en un DBMS

Web Servers – Helper
Applications
 En general, para solucionar los dos
problemas anteriores, se utilizan “helper
applications” que extiendan la
funcionalidad del web server
 El termino no-Java para para una “web
server helper application”, es un programa
CGI
o Common Gateway Interface

Applications
Web server machine
Web Server
Application
Cliente
Web server machine
Web Server Helper

Application Application
params
Cliente

Applications
Web server machine
Web Server Helper

Application Application
html
Cliente
Web server machine
Web Server
Application
html
Cliente

CGI & Servlets
 Ambas tecnologias juegan el rol de una “web
server helper application”
 Esto es, una aplicación que exitende la
funcionalidad estatica de un servidor web, de
forma de brindar servicios dinamicos
 ¿Pero cual es mejor?

CGI & Servlets
 CGI fue el primer encare que existio para la
extension de la funcionaldiad dinamica de
una aplicación web
 Los servlets presentan algunas ventajas
frente a CGI
o Los servlets se escriben en Java, y por tanto,
tienen acceso a todo el set de funcionlidades del
API java

CGI & Servlets
 Otro tema es la performance. Con CGI, el
web server debe crear un nuevo proceso
(pesado) ante dada pedido
o Actualemnte esto ha sido mejorado: FastCGI
 Proveen una serie de servicios que definen
el ciclo de vida de los componentes
involucrados en una aplicación web.

Servlets & JSP
 Son los dos tipos de componentes web de la
plataforma Java EE
o Servlets = Java + HTML embebido
o JSP = HTML + Java embebido
 Son dos enfoques radicalmente diferentes,
orientados a tipos diferentes de
desarrolladores.

Ejecucion de un Servlet
 Un Servlet es un programa Java
 Pero a diferencia de un programa Java
tradicional, un Servlet no tiene un metodo
main()
o main() suele ser el punto de entrada para ejecutar
programas Java, .NET, C, C++
 Los servlets estan bajo el control de otro
programa Java, denominado Container

 Apache Tomcat es un ejemplo de container
 Cuando nuestro web server recibe un
request, este se encarga de entregar el
mismo al container, y no al servlet
directamente.
 Decimos que el servlet se encuentra
desplegado en el container

Web server machine
Request
GET Web Server Web Container
Request Application Request
Application GET GET
(Codigo Java) Servlet
(Codigo Java)
Cliente
Web server machine
Reponse
Web Server Web Container
Application Response Application Response
(Codigo Java) Servlet
(Codigo Java)
Cliente

¿Y si no hubiera container?
 Si no tuvieramos el container, necesitariamos
igual alguna forma de realizar todo lo anterior
 Entre otras cosas:
o Abrir un puerto para escuchar conexiones HTTP
o Recibir los paquetes HTTP, parseandolos para
determinar el tipo de pedido
o Instanciar las clases Java apropiadas para
atender esos pedidos (Servlets)
o etc, etc, etc…

¿Y si no hubiera container?
 El container ya nos brinda unas serie de
servicios “out-of-the-box” para el desarrollo
de aplicaciones, como ser:
o Soporte de comunicaciones
o Administración del ciclo de vida de los
componentes
o Soporte de concurrencia
o Seguridad declarativa
o Soporte para paginas JSP

¿Como funciona el container?
Web server machine
Request
GET Web Container
Application
Servlet
Cliente
Web server machine

request
Web Container
Application
Servlet
response
Cliente

Web server machine
request
Web Container
Application
response Thread Servlet
Cliente
Web server machine
request
Web Container
Application
response Thread Servlet
Service()
Cliente

Web server machine
response
Web Container
Application
Thread Servlet
Response Service()
Cliente doGet()
Web server machine

request
Response Web Container

Application
Thread Servlet
response
Cliente

¿Que es un Servlet?

 Es una clase Java, que extiende una
determinada clase base del paquete
javax.servlet.http
 Implementa una serie de metodos
especiales, de la forma doXXX(), donde XXX
corresponde al nombre de un metodo de
HTTP

 Decimos entonces, que un servlet actua
como interceptor de los request HTTP
enviados a un servidor, para un determinado
metodo (HTTP)

¿Como encontramos el
servlet?
 ¿Como hace el contenedor para derivar un
determinado request y response, a un servlet
especifico?
 En general a traves de la URL con que
generamos el pedido HTTP
 La idea basica, es que la URL del request
debera mapearse de alguna forma con el
servlet al cual queremos invocar

Los tres nombres de un
Servlet
 Por un lado, tenemos el nombre del archivo
del servlet.
o Por ejemplo, algo del estilo
c:\appweb\miapp\WEB-
INF\classes\miservlet.class
 Es un nombre otorgado por un desarrollador,
el cual contiene el nombre de la clase, el
package en donde se encuentra, y el
directorio donde esta este package

Servlet
 Por otro lado, tenemos un nombre interno de
deployment
 Este nombre es creado por parte del
deployer, para no utilizar el nombre fisico real
del servlet

Servlet
 Por ultimo, tenemos la URL del servlet, la
cual es conocida por parte del cliente
 Esta URL es falsa, no corresponde a un
recurso fisico real
 Su objetivo es mapear esta URL con el
nombre de deployment del servlet, el cual se
mapea a su vez con el nombre real de la
clase del servle

Mappings de un Servlet
 Incrementan la flexibilidad de nuestra
aplicación, ya que nos permite alterar las
URLs con que los clientes ven los servlets,
sin necesidad de recompilar una clase
 Aumentan la seguridad de la aplicación, ya
que la implementacion y el nombre de la
clase real, se encuentran ocultos al cliente.

Deployment descriptor
 Toda esta informacion sobre los mappings (y
mucha mas), debe ser informada de alguna
forma al container, para que este pueda
ejecutar el servlet
 Para esto se utiliza un archivo XML, conocido
como deployment descriptor
 Como minimo para cada servlet, vamos a
encontrar dos mappings

<servlet>
<servlet-name>HelloWorldServlet</servlet-name>
<servlet-class>test.HelloWorld</servlet-class>
<init-param>
<param-name>cant</param-name>
<param-value>5</param-value>
</init-param>
</servlet>
<servlet>
<servlet-name>LoginServlet</servlet-name>
<servlet-class>test.LoginServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>HelloWorldServlet</servlet-name>
<url-pattern>/helloServlet/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>LoginServlet</servlet-name>
<url-pattern>/loginServlet/*</url-pattern>
</servlet-mapping>

Web Application
 Una Web Application es una extensión
dinámica de un servidor Web o un servidor
de aplicaciones
 Java soporta el desarrollo de aplicaciones
web, a través de las siguientes tecnologías:
o Servlets
o JSP

Web Application

Web Application - Estructura
 Una aplicación Web consiste en
componentes Web, recursos estáticos como
imágenes y clases y librerías utilizadas por
los componentes Web
 Los recursos de una Web Appication son
almacenados en una jerarquía de directorios


 Cada Web application debe tener un
directorio WEB-INF
 Su contenido no esta accesible directamente
a los clientes
 Este directorio está compuesto por:
o Carpeta classes: Servlets y clases de la
aplicación organizadas de acuerdo a sus
packages
o Carpeta lib: Archivos jar/zip
o Archivo web.xml (Deployment descriptor):
Información de configuración

Deployment descriptor (web.xml)
 El descriptor de una aplicación web, posee

todos los meta-datos de configuración de
mis componentes web.
 Este descriptor es un archivo xml
denominado “web.xml” que debe ser
ubicado dentro del directorio WEB-INF de
la aplicación.

web.xml…¿que contiene?
 El descriptor web.xml puede contener:
o Datos generales de la aplicación web.
o Parámetros de contexto.
o Filters (Servlets).
o Filter mappings.
o Listeners (Servlets).
o Servlets declarations.
o Servlets mappings.
o Tag libraries.
o Security constraints.

Web Application - Deployment
 En J2EE, una aplicación web puede ser
instalada de 2 maneras diferentes:
o Como un carpeta con archivos y
subcarpetas que respetan una estructura
estándar.
o Como un JavaARchive File con
extensión .WAR que dentro posee una
estructura idéntica a la mencionada en el
punto anterior

Web Application – WAR
 Los archivos WAR son una forma de

empaquetar los recursos que componen una
Web application
 Son similares a un archivo jar
 La extensión war hace que reciban

tratamiento especial por parte del web
container
 Cuando se inicia el container se extrae el
contenido del archivo

Clase 11

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clase 11

Cargado por

Copyright:

Formatos disponibles

Taller de Sistemas de

INCO - Facultad de Ingeniería – Montevideo, Uruguay 2

INCO - Facultad de Ingeniería – Montevideo, Uruguay 3

INCO - Facultad de Ingeniería – Montevideo, Uruguay 4

INCO - Facultad de Ingeniería – Montevideo, Uruguay 5

INCO - Facultad de Ingeniería – Montevideo, Uruguay 6

INCO - Facultad de Ingeniería – Montevideo, Uruguay 7

INCO - Facultad de Ingeniería – Montevideo, Uruguay 8

INCO - Facultad de Ingeniería – Montevideo, Uruguay 9

INCO - Facultad de Ingeniería – Montevideo, Uruguay 10

 El HTML instruye al browser para que

INCO - Facultad de Ingeniería – Montevideo, Uruguay 11

INCO - Facultad de Ingeniería – Montevideo, Uruguay 12

 <body> define los limites del cuerpo del

INCO - Facultad de Ingeniería – Montevideo, Uruguay 13

INCO - Facultad de Ingeniería – Montevideo, Uruguay 14

INCO - Facultad de Ingeniería – Montevideo, Uruguay 16

 Este permite conversaciones simples de la

INCO - Facultad de Ingeniería – Montevideo, Uruguay 17

INCO - Facultad de Ingeniería – Montevideo, Uruguay 18

INCO - Facultad de Ingeniería – Montevideo, Uruguay 19

INCO - Facultad de Ingeniería – Montevideo, Uruguay 20

INCO - Facultad de Ingeniería – Montevideo, Uruguay 21

INCO - Facultad de Ingeniería – Montevideo, Uruguay 22

INCO - Facultad de Ingeniería – Montevideo, Uruguay 23

INCO - Facultad de Ingeniería – Montevideo, Uruguay 24

INCO - Facultad de Ingeniería – Montevideo, Uruguay 25

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,

Accept-Encoding: gzip, deflate

INCO - Facultad de Ingeniería – Montevideo, Uruguay 26

INCO - Facultad de Ingeniería – Montevideo, Uruguay 27

INCO - Facultad de Ingeniería – Montevideo, Uruguay 28

INCO - Facultad de Ingeniería – Montevideo, Uruguay 29

INCO - Facultad de Ingeniería – Montevideo, Uruguay 30

 Query string: No aparece, pero representa

 Todos los clientes ven la misma pagina

 ¡Sin embargo, a veces esto no basta!

INCO - Facultad de Ingeniería – Montevideo, Uruguay 32

INCO - Facultad de Ingeniería – Montevideo, Uruguay 33

INCO - Facultad de Ingeniería – Montevideo, Uruguay 34

INCO - Facultad de Ingeniería – Montevideo, Uruguay 35

Web server machine

Web Server Helper

INCO - Facultad de Ingeniería – Montevideo, Uruguay 36

Web Server Helper

Web server machine

INCO - Facultad de Ingeniería – Montevideo, Uruguay 37

INCO - Facultad de Ingeniería – Montevideo, Uruguay 38

INCO - Facultad de Ingeniería – Montevideo, Uruguay 39

INCO - Facultad de Ingeniería – Montevideo, Uruguay 40

INCO - Facultad de Ingeniería – Montevideo, Uruguay 41

INCO - Facultad de Ingeniería – Montevideo, Uruguay 42

INCO - Facultad de Ingeniería – Montevideo, Uruguay 43

Web server machine

INCO - Facultad de Ingeniería – Montevideo, Uruguay 44

INCO - Facultad de Ingeniería – Montevideo, Uruguay 45

INCO - Facultad de Ingeniería – Montevideo, Uruguay 46

Web server machine

INCO - Facultad de Ingeniería – Montevideo, Uruguay 47

Web server machine

INCO - Facultad de Ingeniería – Montevideo, Uruguay 48

Web server machine

Response Web Container