Transcript Servidores Web


Internet

World Wide Web

Servidor Web

Servidor de Aplicaciones
◦ Protocolo TCP/IP
◦ Aplicaciones: DNS, FTP, SMTP, etc.
◦
◦
◦
◦
HTTP
URLs
Unicode
HTML
◦ Arquitectura cliente/servidor
◦ Páginas estáticas/dinámicas
◦ Servicios


Web = vasta colección de documentos en
Internet enlazados a través de
hiperenlaces
Internet: millones de ordenadores conectados
Conjunto de redes heterogéneas conectadas
entre sí mediante el protocolo TCP/IP

Los hiperenlaces permiten a los usuarios acceder a documentos
situados en otros servidores Web, sin preocuparse de su
ubicación





(60-80) Origen militar
◦ Protocolos de comunicación (TCP/IP)
◦ Seguridad ante ataques (múltiples servidores)
(80 – 90) Implantación académica
◦ Protocolos de intercambio de información (FTP, SMTP, ...)
(90-95) World Wide Web
◦ HTTP, HTML, etc.
◦ Enorme biblioteca con material hipermedia
(95 – 00) Acceso comercial
◦ Posibilidad de negocio  Dinero!!
◦ Boom comercial
(00-) Crisis de las punto com
◦ Historias de fracasos  Lecciones aprendidas
◦ Nuevas posibilidades: Computación ubicua, Web semántica,
etc.
Router ISP local
Modem
ISP regional
servidores
Telefonía móvil
Acceso
particular
Acceso corporativo
wireless

Se encarga de llevar a cabo la conmutación de paquetes
◦ Transmission Control Protocol (TCP)
◦ Internet Protocol (IP)

Protocolo = conjunto de reglas para formatear,
ordenar y comprimir mensajes, comprobar
errores, etc.
◦ Pueden implementarse en hardware o software

La familia de protocolos TCP/IP se divide en 4 capas:
◦ Capa de red: de más bajo nivel
 Representa el medio físico encargado de enviar en última instancia
los 0 y 1 que componen cada mensaje
 Diversas tecnologías: Ethernet, ATM…
◦ Capa de Internet (IP)
 Esquema de direcciones, encaminamiento de los mensajes…
◦ Capa de transporte (TCP)
 Envía acuses de recibo, reagrupa el mensaje en destino, vuelve a
mandar los paquetes perdidos o defectuosos…
 No garantiza tiempos de transmisión
◦ Capa de aplicación: programas que hacen uso de los servicios
proporcionados por las capas inferiores
 HTTP (HyperText Transfer Protocol), FTP (File Transfer Protocol),
SMTP (Simple Mail Transfer Protocol)…
Capa de
Aplicación
HTTP
Telnet
FTP
SMTP
Capa de
Transporte
TCP
Capa de
Internet
IP
Capa
de red
Ethernet
Token
Ring
Frame
Relay
…
ATM
1.
El protocolo TCP
trocea los datos
en paquetes
router
2. Los paquetes
viajan de router
a router según
protocolo IP
router
3. El protocolo TCP
ensambla los
paquetes para
obtener el
mensaje original
router
router
Emisor
router
router
Receptor

Cada ordenador conectado a Internet (=Host) debe
tener una dirección para poder recibir los paquetes TCP
◦ Puede ser:
 Estática
 Fija, siempre la misma
 Dinámica
 Por ejemplo, cada vez que nos conectamos a Internet con un módem
telefónico, nuestro proveedor de Internet (ISP, Internet Service
Provider) nos asigna una dirección temporal

Las direcciones IP son números de 32 bits separados en
cuatro partes (por ejemplo, 156.35.94.5)
◦ Cada uno va de 0 a 255; esto nos da un total de 232
direcciones (algo más de cuatro mil millones)

Diversas protocolos de aplicación
◦
◦
◦
◦
◦
◦
SMTP (correo electrónico)
FTP (intercambio ficheros)
IRC (Chat)
HTTP (hipertexto)
DNS (nombres dominio)
…

DNS (sistema de nombres de domino) permite
asociar nombres lógicos a direcciones IP
◦ DNS es una base de datos distribuida
◦ Ejemplo: www.euitio.uniovi.es – 156.35.94.5

Internet permite a cualquier ordenador del
mundo compartir datos con otro ordenador
remoto
◦ Un programa cliente en un ordenador accede a un
programa servidor en otro ordenador remoto

La Web = sistema de hipertexto que funciona
sobre Internet como uno de sus servicios
◦ En este caso, el programa cliente es nuestro navegador,
y el servidor el programa que hace de servidor Web que
está ejecutándose en el ordenador remoto y que se
encarga de entregar el documento solicitado a nuestro
navegador

En 1989, Tim Berners-Lee, en el laboratorio
europeo de partículas (CERN), en Suiza, crea
un lenguaje de etiquetas para representar y
enlazar documentos
◦ HTML —HyperText Markup Language
 Lenguaje de Marcado de Hipertexto
Tim Berners-Lee
Berners-Lee creó las versiones iniciales de:
HTML, HTTP, un servidor Web y un navegador
Los cuatro componentes esenciales de la Web
Petición
Red
Servidor
Respuesta
Cliente
www.uniovi.es
index.html
Internet
enlace
El usuario teclea http://www.uniovi.es/
en su navegador
www.euitio.uniovi.es

El usuario solicita un documento tecleando su dirección
en el navegador: http://www.uniovi.es
◦

El cliente busca en el DNS cuál es la IP de www.uniovi.es:
156.35.14.3
◦
◦

Es lo que se denomina un URL (localizador uniforme de
recursos)
Cada ordenador en Internet está identificado por una
dirección única denominada IP
El DNS traduce de nombres lógicos a direcciones físicas
Navegador y servidor web comienzan un diálogo a través
del protocolo HTTP (protocolo de transferencia de
hipertexto)


GET /HTTP/1.0
El servidor, si todo es correcto, devuelve el documento
solicitado más información adicional
◦
◦
◦
El navegador mira el tipo de documento devuelto (MIME)
Si es “text/html” es un documento HTML, lo visualiza el propio
navegador
Si es otro tipo de documento se ejecutará el programa que
tenga asociado, o nos preguntará si queremos guardar el
documento en nuestro ordenador
 Nota: estos tipos MIME los podemos configurar en nuestro
navegador
Éste envía una petición al servidor Web
Tecleamos una dirección en
el navegador (por ejemplo,
www.euitio.uniovi.es)
HTTP
Y el navegador se
encarga de interpretar
el código HTML y
mostrar el resultado
Quien devuelve la página
solicitada (en este caso, la
index.html del directorio raíz)

Un servidor Web es un ordenador en
Internet que sirve páginas Web y contenido
estático en general a petición
◦ Para ello, debe tener un programa ejecutándose
que haga de servidor Web: Apache, IIS, etcétera

El usuario accede al Web a través de un
navegador (browser)
◦ Se encarga de solicitar las páginas Web al
servidor y de mostrarlas

HTTP (HyperText Transform Protocol) es el
protocolo usado para transferir páginas Web
◦ Es el modo en que un navegador se comunica con un
servidor Web (Apache, Internet Information Server…)

Es un protocolo sin estado
◦ La sesión termina en cuanto se devuelve el objeto
solicitado
 Incluso, si una página contiene otros objetos (imágenes,
frames, etc.) cada uno de ellos inicia una nueva petición
HTTP
Petición
GET / HTTP/1.0 >
>
Respuesta
<
HTTP/1.0 200 OK <
Date: Wed, 18 Sep 1996 20:18:59 GMT <
Server: Apache/1.0.0 <
Content-type: text/html <
Content-length: 1579 <
Last-modified: Mon, 22 Jul 1996 22:23:34 GMT <
<
HTML document

Tipos de peticiones
◦ GET, HEAD, POST, PUT, DELETE, …

Define códigos de respuestas
◦
◦
◦
◦
◦
◦
200
400
401
403
404
...
–
–
–
–
–
OK
Bad Request
Unauthorized
Forbidden
Not Found
Representación de Caracteres
ASCII: 7 bits  (0 – 127)
(A)merican (S)tandard (C)ode for (I)nformation (I)nterchange
Extensiones de ASCII
ISO-8859-1 (iso-latin-1)
(8 bits) ASCII (0-127) + otros caracteres típicos de Europa occidental
Familia ISO-8859-X = Otros alfabetos europeos
ISO-8859-15 (iso-latin-9) Igual que iso-8859-1 + símbolo de €









ISO-10646 (31 bits) Define un repertorio universal de caracteres (UCS)
En continua revisión: ISO-10646-2:2001 contiene más de 70.000
caracteres
UNICODE = Consorcio de empresas que define restricciones sobre la
implementación de ISO-10646
Varias codificaciones (UTF = Unicode Transformation Format)
- UTF-8: Los primeros 127 códigos se presentan igual (compatible con
ASCII)
El resto se codifican en longitud variable
Relativamente Eficiente
- UTF-16: Usa 16bits para los caracteres más comunes, el resto con pares
de 16 bits
- UTF-32: Codificación directa en 32 bits (desperdicio de espacio)
NOTA: Conviene distinguir:
Carácter: Entidad abstracta (Letra A)
Glifo (Glyph): Representación del carácter A A A A A A
Fuente (Font): Conjunto de glyphs, ejemplo: Times Roman, Arial, etc.

URI: Uniform Resource Identifier
 URL: Uniform Resource Locator
 Además de una identificador único, indica protocolo de acceso

http://www.euitio.uniovi.es
 URN: Uniform Resource Name
 Identificador único


urn:isbn:0451450523
IRI: Internationalized Resource Identifier
◦ Admite caracteres Unicode
protocolo://dirección[:puerto]/directorio/fichero

Ejemplos:
◦
◦
◦
◦
◦
◦
◦
http://www.princast.es/
http://195.55.30.17/
http://www.cfacebal.com/
http://www.cfacebal.com/index.html
http://web.uniovi.es/Vicerrectorados/Extension/
http://localhost:8080/
http://petra.euitio.uniovi.es/


Un protocolo define el modo en que se comunican dos
ordenadores para llevar a cabo alguna tarea
Protocolo del Web:
◦ HTTP (HyperText Transfer Protocol)
◦ Especifica cómo tiene lugar el diálogo entre el navegador y el
servidor para conseguir el fichero especificado
◦ No se ocupa del transporte en sí: TCP

Cada vez que tecleamos una dirección o pulsamos un
enlace el navegador se comunica vía HTTP con el servidor
Web indicado
file
ftp
Permite acceder a un fichero en el
sistema de ficheros local
File Transfer Protocol
http
Páginas Web

Suele ser un nombre simbólico: nombre de
dominio
◦ www.uniovi.es especifica una máquina llamada “www” en
el dominio “uniovi.es”
◦ El nombre de máquina puede ser cualquiera
 “www” no es más que un convenio para especificar
aquellas máquinas que son servidores Web
 como “ftp” suele designar a los servidores de FTP
 incluso aunque muchas veces se trate de la misma
máquina

También podría ser directamente la dirección
IP
◦ http://156.35.14.3/

Los nombres de dominio no distinguen entre
mayúsculas y minúsculas
◦ http://www.uniovi.es/
◦ http://WWW.UNIOVI.ES/
◦ http://wWw.UniOvi.es/


Hay que indicar la ruta hasta el fichero deseado
Como mínimo, debe ir la barra (“/”)
◦ http://www.uniovi.es/

Si no la ponemos, la pone el navegador por nosotros
◦ ...pero en los enlaces en HTML sí debe aparecer

También se puede indicar un subdirectorio:
◦ http://www.uniovi.es/Vicerrectorados/Postgrado_TitulosPropios/
doctorado/
◦ Siempre se usa la barra “/”, no “\” (incluso aunque el
servidor Web sea una máquina Windows: está definido por
el estándar URI, no depende del SO)

La ruta sí puede diferenciar entre mayúsculas y
minúsculas (si el servidor Web es, por ejemplo, una
máquina Unix)



Depende del SO del servidor Web
Las páginas Web generalmente tienen como
extensión .html o .htm
Las extensiones son importantes para que el
navegador sepa cómo tratar un fichero
◦
◦
◦
◦
un .html, lo interpreta y lo muestra
un .jpg, trata de mostrar la imagen
un .doc, abre el Word si lo tenemos instalado
etcétera

Si no se especifica, el servidor busca un
fichero con un nombre determinado en el
directorio especificado
◦ Normalmente, el index.html o el index.htm
◦ Se puede configurar el el programa que
utilicemos como servidor Web (Apache, IIS...)

Por omisión, una petición HTTP se dirige al
puerto 80
◦ Por eso casi nunca la especificamos


Pero se podría configurar el servidor Web
para que “escuchase” peticiones en otro
puerto
En ese caso, hay que indicarlo
explícitamente:
◦ http://www.midominio.com:8080/

Un programa que atiende las peticiones
HTTP llegadas a un puerto determinado
de la máquina
◦ También se denomina así, por extensión, a la
máquina que cuenta con uno de tales
programas

Ejemplos de servidores Web:
◦ Apache
 Apache HTTP Server Project
 http://httpd.apache.org/
◦ Internet Information Server (IIS)

Al principio, el Web estaba poblado únicamente por
páginas estáticas
◦ El servidor Web simplemente localizaba el documento
solicitado en el URL y se lo entregaba al cliente

Este enfoque puede ser perfectamente válido para
muchos sitios
◦ Siempre y cuando no requieran actualizaciones
continuas …

Pero no permitiría, por ejemplo, crear un sitio de
comercio electrónico donde se pueda comprar, o el
de un banco
◦ Es necesario acceder a datos en el servidor y crear una
página a petición
pagina.html
<html><head></head>
<body>
<h1>17/10/2005</h1>
</body>
</html>
En el navegador
se vería
17/10/2005
<html><head></head>
<body>
<h1>17/10/2005</h1>
</body>
</html>
pagina.php
Motor
PHP
En el navegador
se vería
18/10/2005
<html><head></head>
<body>
<h1>18/10/2005</h1>
</body>
</html>
<html><head></head>
<body>
<?php
printf(“<h1>%s</h1>”,
date(“d/m/Y”));
?>
</body>
</html>

El servidor Web detecta una petición de una página
dinámica y se la pasa al programa necesario
◦ Podría ser una extensión del servidor
◦ O bien un programa completamente independiente


Éste programa es quien sabe cómo interpretar el código
de la página para devolver el HTML apropiado
Diversas tecnologías
◦ CGIs, ASP, JSP, Servlets, etc.
CGI fue la primera tecnología que
permitió crear páginas dinámicas,
que realizaban algún tipo de
procesamiento en el lado del
servidor.


Es un estándar que permite el intercambio de
información entre servidores Web y programas
externos
Así, mientras que un documento HTML es
estático (un fichero de texto que no cambia), un
programa CGI permite mostrar información
dinámica, al ejecutarse
◦ Por ejemplo, puede hacer una consulta a una base de
datos ubicada en el servidor y mostrar los resultados en
HTML
/cgi-bin/buscar.cgi?texto=“web standards”
Los datos del
formulario son
enviados vía HTTP
HTTP
El usuario, por
ejemplo, rellena un
formulario y pulsa el
botón de enviar
El servidor
Web invoca
al programa
CGI
pasándole los
parámetros
recibidos
Y éste devuelve
el resultado al
servidor por
medio de la
salida estándar

Hay dos formas posibles en que el
servidor Web puede pasarle los datos al
programa CGI:
◦ Mediante las variables de entorno
◦ Mediante la entrada estándar (stdin)

La tabla siguiente muestra alguna de las
variables de entorno:
◦ (Puede verse una lista completa en
http://hoohoo.ncsa.uiuc.edu/cgi/env.html)
Variable
Descripción
SERVER_NAME
El nombre del servidor o su dirección
IP
QUERY_STRING
La información que sigue al “?” en el
URL que referencia a este programa
Para consultas que llevan asociada
CONTENT_LENGTH información (por ejemplo, las
hechas mediante POST), el tamaño
en bytes de dicha respuesta
PATH_INFO
…
…

La forma de acceder al contenido de dichas
variables desde el programa CGI varía
dependiendo del lenguaje en que haya sido
escrito
◦ Por ejemplo, a continuación se muestra cómo acceder
al valor de la variable SERVER_NAME en C y en Perl:
C
getenv("SERVER_NAME")
Perl
$ENV{'SERVER_NAME'}

El siguiente programa CGI en Perl muestra el
valor de todas las variables de entorno:
#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $key (keys %ENV) {
print "$key --> $ENV{$key}<br>";
}


HTTP es un protocolo sin estado
Esto significa que para el servidor Web cada
petición de una página es única
◦ No tendría forma de saber, por ejemplo, que ese usuario
acaba de añadir un producto a su carrito, o si ya se
validó o no, en qué punto del proceso de compra se
encuentra, etcétera

Son necesarias alternativas software, por tanto,
que permitan simular el estado

Algunas de las alternativas son:
◦ Usar el objeto Session (o similar) provisto por los entornos de
◦
◦
◦
◦
programación como ASP o J2EE (Servlets, JSP...)
Almacenar toda la información de la sesión, a mano, en una
cookie (por ejemplo, mediante JavaScript)
Una combinación de cookie (para guardar un ID de usuario) y
bases de datos
“URL rewriting”
Etcétera


Las cookies son pequeñas porciones datos
que son almacenados localmente por el
navegador en forma de pequeños ficheros de
texto
Cada vez que el cliente envía información al
servidor, incluye en la petición HTTP las
cookies que previamente haya guardado
provenientes de ese servidor

Según la especificación, un agente de usuario (es
decir, un navegador), debe permitir al menos:
◦ Un total de 300 cookies
◦ Hasta 4 KB (4.096 bytes) por cookie
◦ Al menos 20 cookies de un servidor dado

El navegador se encarga automáticamente de
eliminar aquéllas que hace más tiempo que no se
utilizan cuando necesita guardar nuevas cookies

Cada cookie presenta la siguiente sintaxis
general:
nombre=valor; [expires=fecha; path=directorio;
domain=nombreDeDominio; secure]

Lo único obligatorio es que tenga un nombre
y un valor asociado; el resto de atributos son
opcionales
◦ Aunque también se utiliza bastante el atributo
expires


Un par nombre = valor
◦ Por ejemplo: IDUsuario = 49;
expires
◦ Hasta cuándo será válida la cookie
 Debe ir en este formato: Wdy, DD-Mon-YYYY HH:MM:SS GMT
 Si no se dice nada, la cookie será eliminada al terminar la
sesión
 Es decir, al cerrar la ventana actual del navegador

path
◦ El conjunto de directorios del servidor para los que es
válida esta cookie (por omisión, será el raíz “/”, es decir,
todos)

domain
◦ El servidor o nombre de dominio para el que es
válida la cookie
◦ Una cookie sólo puede ser leída y modificada desde
el servidor y directorio especificados en la cookie
cuando ésta fue creada

secure
◦ Es booleano; si está definido (si aparece el atributo)
deberá haber una conexión segura (https) para que
la cookie sea enviada

Consiste en incluir la información del estado
en el propio URL
◦

/…/comprar.asp?paso=3&producto1=01992CX&prod
ucto2=ZZ112230&producto3=HJ19X25…
No es de recibo en aplicaciones “serias”
◦ Un cliente puede iniciar dos o más sesiones
simultáneas, páginas tediosas de programar, sólo
se puede usar el método GET, etc.

Menor uso de los recursos del servidor
◦ Los servidores “sin estado” no necesitan reservar y
mantener recursos para guardar el estado de la sesión

Fácil escalabilidad y uso de clusters
◦ Al no tener estado, cualquier servidor puede atender a
cualquier cliente
 No hace falta que un cliente siempre sea atendido por el
mismo servidor, ni ningún tipo de distribución del estado
entre servidores

La sesión del cliente podría sobrevivir a una caída
del servidor
◦ Un reintento por parte del cliente con el mismo URL
suele funcionar

Privacidad
◦ Otros servidores podrían leer información almacenada
en las cookies del cliente
 No son válidas para guardar números de tarjeta,
contraseñas y cosas por el estilo

Los datos pueden ser alterados
◦ Un usuario podría modificar el fichero de una cookie
◦ Lo mismo ocurre con otros mecanismos de cliente: URL,
formularios, etc.

Aumenta el tráfico por la red
◦ El estado se transmite con cada petición al servidor

Implementación compleja
◦ Mantener “a mano” el estado en el cliente puede ser
realmente complicado si queremos hacerlo de
manera robusta

Tamaño de datos limitado
◦ Tanto el tamaño máximo permitido por las cookies
como la longitud máxima de un URL pueden darnos
problemas para almacenar sesiones complejas


Es un programa que provee la infraestructura necesaria
para las aplicaciones Web empresariales
¿Qué quiere decir esto?
◦ Que los programadores van a poder dedicarse casi en
exclusiva a implementar la lógica del dominio, ya que servicios
de uso común, como transacciones, seguridad, persistencia,
etc. ya son proporcionados por el servidor Web
◦ Se ha convertido en una pieza de software clave para cualquier
empresa dedicada al comercio electrónico
◦ Es una capa intermedia (middleware) que se sitúa entre el
servidor Web y las aplicaciones y bases de datos subyacentes
Aplicación
cliente
Aplicación
cliente
Aplicación
cliente
Servidor de aplicaciones
(Transacciones, mensajería, servicios Web…)
CORBA
J2EE
SGBD
.NET

Comienzan a surgir cuando queda claro las
aplicaciones cliente/servidor no iban a ser
escalables a un gran número de usuarios
◦ Debido a las características de los clientes “pesados”


Se hacía necesario mover las reglas de negocio a
algún lugar intermedio entre los clientes y la
base de datos
Empezaron a surgir productos para hacer esa
tarea
◦ Cada compañía los llamaba de una forma distinta
 Servidores de transacciones, servidores de
aplicaciones…

Los llamasen como los llamasen, estaban
diseñados para gestionar de forma
centralizada el modo en que los clientes
debían conectarse a la base de datos o a los
servicios con los que tenían que interoperar

Creación y gestión de los componentes del
servidor
◦ Por aquel entonces, basados en CORBA o COM






Clustering
Equilibrado de carga
Transacciones
Seguridad
Acceso a datos
…
El servidor ha de conservar información entre peticiones del usuario a lo largo de la
duración de una sesión

Como sabemos, HTTP es un protocolo sin sesión
◦ No permite mantener una conexión abierta entre el
cliente y el servidor más allá de lo que dura la
transferencia del documento en cuestión

En cualquier aplicación de comercio electrónico,
es necesario poder identificar al usuario a través
de su navegación por el sitio Web
◦ Autenticación, adición de productos al carrito de la
compra, etc.

La implementación “a mano” se complicaría enormemente
en el caso de contar con varios servidores (equilibrado de
carga)
◦ La petición de un usuario registrado en la máquina A puede
ser redirigida al servidor B

Lo lógico es que sea el servidor de aplicaciones quien se
encargue de gestionar la sesión
◦ Además, debería ser más eficiente que si lo programamos
nosotros mismos
Los servidores de aplicaciones proporcionan mecanismos de equilibrado de carga
(aspecto clave para la escalabilidad)

Por equilibrado de carga (load balancing) se
entiende la capacidad de repartir el procesamiento
entre distintos servidores
◦ Las peticiones de los clientes se redirigen a la máquina
que más desocupada se encuentre en ese momento
◦ Mejora de rendimiento de la aplicación


No es tan sencillo como añadir una nueva máquina
y ya está
Además de la escalabilidad, se consigue una mayor
tolerancia a fallos

Los servidores de aplicaciones proveen facilidades para
administrar conexiones a bases de datos relacionales
◦ Oracle, SQL Server, DB2…

Los componentes (las clases que implementan la lógica del
negocio) acceden a ellas de forma estándar
◦ Independiente de la base de datos subyacente

También suelen permitir acceder a otros tipos de fuentes de
datos:
◦ Tales como distintos ERP (SAP, Vaan...), repositorios XML, etc.
◦ Los servidores de aplicaciones son también importantes, por tanto,
como mecanismo de integración de sistemas heredados

Abrir una conexión a una base de datos suele ser
un proceso costoso
◦ No es viable abrir una nueva conexión por cada consulta
a la base de datos
 Penalizaría enormemente el rendimiento de la aplicación

Los servidores de aplicaciones suelen contar con
una serie de conexiones permanentemente
abiertas que distribuye de forma transparente a
los distintos procesos
◦ Se debería poder configurar el número de conexiones
abiertas, e incluso la política de asignación
Transacción: secuencia de pasos que, o se ejecutan todos, o si no el sistema
queda en el estado original

Son un elemento básico de cualquier
aplicación comercial
◦ Evitan que haya información inconsistente


Sería complejísimo implementarlas “a
mano”
Con un servidor de aplicaciones que tenga
esta característica, bastaría con indicarle
dónde empieza y termina la transacción
◦ Encargándose él de deshacer los pasos
intermedios en caso de un error del sistema

Actualmente, las dos plataformas más
comunes son JEE y, más recientemente, ha
surgido .NET
◦ De hecho, hasta hace poco hablar de servidores de
aplicaciones era prácticamente hablar de J2EE
 (aunque no debemos hacer tal asociación)
Máquina
Cliente
Servidor J2EE
Contenedor Web
Navegador
Servlets
Contenedor
Aplicación
Cliente
Aplicación
Cliente
Páginas
JSP
Contenedor EJBs
EJB
EJB
Base
Datos