EVOLUCIN DE LAS APLICACIONES

WEB
Desde que Internet y la Web fueron creados, una cantidad infinita de posibilidades
se han abierto, quizs, la ms importante y usual sea el acceso de datos e
informacin desde cualquier sitio. Las personas que se dedican al desarrollo de
aplicaciones podran considerar esto como un desafo, ya que los avances
tecnolgicos de estos ltimos aos exigen aplicaciones ms rpidas, ligeras y
robustas que permitan utilizar la Web. Sin lugar a dudas, Internet es una de las
ltimas tecnologas que ms rpidamente se est desarrollando para su
introduccin en los hogares. Las previsiones apuntan a su integracin como un
electrodomstico ms, con unas capacidades y servicios que evolucionaran
rpidamente. Por ese motivo, cada vez ms adquieren importancia en las
respuestas de los usuarios frente a la implantacin de estas nuevas tecnologas.
Gracias al Internet y las conexiones de alta velocidad que lo acompaan, se ha
podido mejorar de manera significativa la manera de trabajar de algunas personas
al poder hacerlo desde sus hogares, Internet ha permitido a estas personas mayor
flexibilidad en trminos de horarios y de localizacin.
La programacin web es un trmino adecuado para describir el proceso general que
engloba el diseo y la creacin de un sitio web.
Hace algunos aos, los sitios web no eran mucho ms que folletos digitales. Actualmente
los sitios son ms grandes y complejos.
Con la introduccin de comercio electrnico y las pginas dinmicas, los sitios ya han
dejado atrs los folletos y han pasado a ser autnticas aplicaciones de software.

En los aos 60. En plena guerra fra, Estados Unidos crea una red exclusivamente
militar, con el objetivo de que, en el hipottico caso de un ataque ruso, se pudiera
tener acceso a la informacin militar desde cualquier punto del pas.
Esta red se cre en 1969 y se llam ARPANET. En principio, la red contaba con 4
ordenadores distribuidos entre distintas universidades del pas. Dos aos despus,
ya contaba con unos 40 ordenadores conectados. Tanto fue el crecimiento de la

red que su sistema de comunicacin se qued obsoleto. Entonces dos

investigadores crearon el Protocolo TCP/IP, que se convirti en el estndar de
comunicaciones dentro de las redes informticas.
ARPANET sigui creciendo y abrindose al mundo, y cualquier persona con fines
acadmicos o de investigacin poda tener acceso a la red.
Las funciones militares se desligaron de ARPANET y fueron a parar a MILNET,
una nueva red creada por los Estados Unidos.
La National Science Fundation crea su propia red informtica llamada NSFNET,
que ms tarde absorbe a ARPANET, creando as una gran red con propsitos
cientficos y acadmicos.
El desarrollo de las redes fue abismal, y se crean nuevas redes de libre acceso
que ms tarde se unen a NSFNET, formando el embrin de lo que hoy conocemos
como INTERNET.
En 1985 la Internet ya era una tecnologa establecida, aunque conocida por unos
pocos.
El autor William Gibson hizo una revelacin: el trmino ciberespacio.
En ese tiempo la red era bsicamente textual, as que el autor se bas en los
videojuegos. Con el tiempo la palabra ciberespacio termin por ser sinnimo
de Internet.
En el Centro Europeo de Investigaciones Nucleares (CERN), Tim Berners Lee
diriga la bsqueda de un sistema de almacenamiento y recuperacin de datos.
Berners Lee retom la idea de Ted Nelson (un proyecto llamado Xanad) de usar
hipervnculos. Robert Caillau quien cooper con el proyecto, cuenta que en 1990
deciden ponerle un nombre al sistema y lo llamaron World Wide Web (WWW) o
telaraa mundial.
A partir de entonces Internet comenz a crecer ms rpido que otro medio de
comunicacin, convirtindose en lo que hoy todos conocemos.

Algunos de los servicios disponibles en Internet aparte de la WEB son el acceso

remoto a otras mquinas (SSH y telnet), transferencia de archivos(FTP), correo
electrnico(SMTP), conversaciones en lnea (IMSN MESSENGER, ICQ, YIM,
AOL, jabber), transmisin de archivos (P2P, P2M, descarga directa), etc.
La gran ventaja que presenta la WWW son los hiperenlaces gracias a los cuales la
navegacin y la bsqueda de informacin se convierten en un juego de nios.
Cuando se visualiza un documento WWW, el texto que aparece en la pantalla
contiene palabras en otro color y para resaltar las palabras clave.
La publicacin web o la programacin web
Son trminos adecuados para describir el proceso general que engloba el diseo y
la creacin de un sitio web.
En un principio la web era sencillamente una coleccin de pginas estticas,
documentos, etc. para su consulta o descarga. El paso inmediatamente posterior
en su evolucin fue la inclusin de un mtodo para elaborar pginas dinmicas
que permitieran que lo mostrado tuviese carcter dinmico (es decir, generado a
partir de los datos de la peticin). Este mtodo fue conocido como CGI (Common
Gateway Interface) y defina un mecanismo mediante el que se poda pasar
informacin entre el servidor y ciertos programas externos.

2.1 Arquitectura de las aplicaciones Web.

Una aplicacin Web es proporcionada por un servidor Web y utilizada por
usuarios que se Conectan desde cualquier punto va clientes Web (browsers o
navegadores). La arquitectura de un Sitio Web tiene tres componentes
principales:

Un servidor Web

Una conexin de red

Uno o ms clientes

El servidor Web distribuye pginas de informacin formateada a los clientes

que las solicitan. Los requerimientos son hechos a travs de una conexin de
red, y para ello se usa el protocolo HTTP. Una vez que se solicita esta peticin
mediante el protocolo HTTP y la recibe el servidor Web, ste localiza la pgina
Web en su sistema de archivos y la enva de vuelta al navegador que la solicit.

Las aplicaciones Web estn basadas en el modelo Cliente/Servidor que

gestionan servidores web, y que utilizan como interfaz pginas web.
Las pginas Web son el componente principal de una aplicacin o sitio Web.
Los browsers piden pginas (almacenadas o creadas dinmicamente) con
informacin a los servidores Web. En algunos ambientes de desarrollo de
aplicaciones Web, las pginas contienen cdigo HTML y scripts dinmicos,
que son ejecutados por el servidor antes de entregar la pgina.
Una vez que se entrega una pgina, la conexin entre el browser y el servidor
Web se rompe, es decir que la lgica del negocio en el servidor solamente se
activa por la ejecucin de los scripts de las pginas solicitadas por el browser
(en el servidor, no en el cliente). Cuando el browser ejecuta un script en el
cliente, ste no tiene acceso directo a los recursos del servidor. Hay otros
componentes que no son scripts, como los applets (una aplicacin especial
que se ejecuta dentro de un navegador) o los componentes ActiveX. Los
scripts del cliente son por lo general cdigo JavaScript o VBSscript,
mezclados con cdigo HTML.
La coleccin de pginas son en una buena parte dinmicas (ASP, PHP, etc.), y
estn agrupadas lgicamente para dar un servicio al usuario. El acceso a las
pginas est agrupado tambin en el tiempo (sesin). Los componentes de una
aplicacin Web son:
1. Lgica de negocio.

Parte ms importante de la aplicacin.

Define los procesos que involucran a la aplicacin.

Conjunto de operaciones requeridas para proveer el servicio.

2. Administracin de los datos.

Manipulacin de BD y archivos.

3. Interfaz

Los usuarios acceden a travs de navegadores, mviles, PDAs, etc.

Funcionalidad accesible a travs del navegador.

Limitada y dirigida por la aplicacin.

Las aplicaciones web se modelan mediante lo que se conoce como modelo de

capas, Una capa representa un elemento que procesa o trata informacin. Los
tipos son:

Modelo de dos capas: La informacin atraviesa dos capas entre la

interfaz y la administracin de los datos.

Modelo de n-capas: La informacin atraviesa varias capas, el ms

habitual es el modelo de tres capas.

Modelo de dos Capas.

Gran parte de la aplicacin corre en el lado del cliente (fat client).
Las capas son:

Cliente (fat client): La lgica de negocio est inmersa dentro de la

aplicacin que realiza el interfaz de usuario, en el lado del cliente.
Servidor: Administra los datos.

Las limitaciones de este modelo son.

Es difcilmente escalable

Nmero de conexiones reducida

Alta carga de la red.

La flexibilidad es restringida

La funcionalidad es limitada.

Modelo de tres Capas.

Esta diseada para superar las limitaciones de las arquitecturas ajustadas al
modelo de dos capas, introduce una capa intermedia (la capa de
proceso) Entre presentacin y los datos, los procesos pueden ser
manejados de forma separada a la interfaz de usuari o y a los datos, esta
capa intermedia centraliza la lgica de negocio, haciendo la administracin

ms sencil a, los datos se pueden integrar de mltiples fuentes, las

aplicaciones web actuales se ajustan a este modelo.
Las capas de este modelo son:
1. Capa de presentacin (parte en el cliente y parte en el servidor)

Recoge la informacin del usuario y la enva al servidor (cliente)

Manda informacin a la capa de proceso para su procesado

Recibe los resultados de la capa de proceso

Generan la presentacin

Visualizan la presentacin al usuario (cliente)

2. Capa de proceso (servidor web)

Recibe la entrada de datos de la capa de presentacin

Interacta con la capa de datos para realizar operaciones

Manda los resultados procesados a la capa de presentacin

3. Capa de datos (servidor de datos)

Almacena los datos

Recupera datos

Mantiene los datos

segura la integridad de los datos

Arquitectura J2EE
Java 2 Platform, Enterprise Edition (J2EE) suministra un estndar para el desarrollo de aplicaciones
empresariales multinivel.
La economa y tecnologa actuales han incrementado la necesidad de soluciones de gestin de
informacin ms rpidas, ms eficaces y de mayor escala. La especificacin J2EE satisface estos
desafos, ya que proporciona un modelo de programacin que mejora la productividad del desarrollo,
estandariza la plataforma para alojar aplicaciones de empresa y asegura la portabilidad de las
aplicaciones desarrolladas con un conjunto amplio de pruebas.
La arquitectura J2EE da soporte al desarrollo basado en componentes de las aplicaciones de empresa
multinivel. Un sistema de aplicacin J2EE suele incluir los niveles siguientes:
Nivel de cliente
En el nivel de cliente, los componentes Web como, por ejemplo, los servlets y JSP (JavaServer
Pages) o las aplicaciones Java autnomas proporcionan una interfaz dinmica para el nivel
medio.
Nivel medio
En el nivel de servidor, o nivel medio, los enterprise beans y los Servicios Web encapsulan la
lgica empresarial que es posible distribuir para la aplicacin. Estos componentes de nivel de
servidor se encuentran en un J2EE Application Server, que proporciona la plataforma para que
estos componentes realicen acciones y almacenen datos.
Nivel de datos de empresa

En el nivel de datos los datos de la empresa se almacenan y se conservan, habitualmente en

una base de datos relacional.
Las aplicaciones J2EE constan de componentes, contenedores y servicios. Los componentes
son de nivel de aplicacin. Los componentes Web como, por ejemplo, los servlets y JSP,
proporcionan respuestas dinmicas a las peticiones procedentes de una pgina Web. Los
componentes EJB contienen lgica empresarial del servidor para las aplicaciones de empresa.
Los contenedores de componentes Web y EJB alojan servicios que dan soporte a mdulos Web
y EJB.

2.5 Metodologas para el desarrollo de aplicaciones Web

Las metodologas ms usadas son:
1. RMM Relationship Management Methodology:
se define como un
proceso de anlisis, diseo y desarrol o de aplicaciones hipermedia. Esta
metodologa es apropiada para dominios con estructuras regulares es decir,
con clases de objetos bien definidas, y con claras relaciones entre esas
clases. Por ejemplo, catlogos o bases de datos tradicionales. El modelo
propone un lenguaje que permite describir los objetos del dominio, sus
interrelaciones y los mecanismos de navegacin hipermedia de la
aplicacin. Los objetos del dominio se definen con la ayuda de entidades,
atributos y relaciones asociativas, sus principales caractersticas son:

Aproximacin para el diseo de sitios web, bajo una aproximacin

centrada en la informacin.

Lenguaje de modelado de sitios web a nivel lgico (dominio de

informacin + estructuras de navegacin + elementos de presentacin)

Integrado en una metodologa de desarrollo

Facilitar la estructuracin de pginas web complejas que contienen
elementos de distintas entidades (vistas mltiples)

Permitir la reutilizacin de elementos en el diseo (vistas jerrquicas)

Diseo de enlaces ms potentes y verstiles

Mantener el contexto durante la navegacin

2. OOHDM Object Oriented Hypermedia Design Method: OOHDM

propone el desarrollo de aplicaciones hipermedia a travs de un proceso
compuesto por cuatro etapas: diseo conceptual, diseo navegacional, diseo
de interfaces abstractas e implementacin.

Diseo Conceptual.
En OOHDM, el desarrol o se inicia diseando la
capa conceptual, siendo el principal objetivo de esta etapa capturar

los conceptos involucrados en el dominio de la aplicacin y describirlos

en detalle, haciendo usode diagramas que permitan expresar con
claridad el comportamiento, la estructura y las relaciones entre dichos
conceptos. La Programacin Orientada a Objetos facilita el traslado
del diseo conceptual a la implementacin, proveyendo al programador
con herramientas que permiten reducir la distancia entre el problema del
mundo real y la programacin de la solucin en la computadora.

Diseo Navegacional. La capa navegacional se compone de objetos

construidos a partir de objetos conceptuales, y constituyen en general
los elementos cannicos de las aplicaciones hipermedia tradicionales:
nodos, enlaces, anclas y estructuras de acceso. Sin embargo, estas
clases pueden extender el comportamiento caracterstico para
funcionar como adaptadores de los objetos conceptuales y delegar
as operaciones especficas del dominio. Entonces, los
objetos navegacionales pueden actuar como observadores, para
construir vistas de objetos conceptuales, y como adaptadores, para
extender la actividad navegacional de un nodo y poder aprovechar
el comportamiento conceptual delobjeto adaptado.

Diseo de Interfaz Abstracta. Una vez que las estructuras

navegacionales son definidas, se deben especificar los aspectos de
interfaz. Esto significa definir la forma en la cual los objetos
navegacionales pueden aparecer, cmo los objetos de interfaz activarn
la navegacin y el resto de la funcionalidad de la aplicacin,
qu transformaciones de la interfaz son pertinentes y cundo es
necesario realizarlas. Una clara separacin entre diseo navegacional
y diseo de interfaz abstracta permite construir diferentes interfaces
para el mismo modelo navegacional, dejando un alto grado de
independencia de la tecnologa de interfaz de usuario. El aspecto de la
interfaz de usuario de aplicaciones interactivas (en particular
las aplicaciones web) es un punto crtico en el desarrollo que las
modernas metodologas tienden a descuidar. En OOHDM se utiliza el
diseo de interfaz abstracta para describir la interfaz del usuario de la
aplicacin de hipermedia. El modelo de interfaz ADVs (Vista de
Datos Abstracta) especifica la organizacin y comportamiento de la
interfaz, pero la apariencia fsica real o de los atributos, y la disposicin
de las propiedades de las ADVs en la pantal a real son hechas en
la fase de implementacin.

Implementacin. En esta fase, el diseador debe implementar el

diseo. Hasta ahora, todos los modelos fueron construidos en forma
independiente de la plataforma de implementacin; en esta fase es
tenido en cuenta el entorno particular en el cual se va a correr la
aplicacin. Al l egar a esta fase, el primer paso que debe realizar el

diseador es definir los tems de informacin que son parte del

dominio del problema. Debe identificar tambin, cmo son
organizados los tems de acuerdo con el perfil del usuario y su
tarea; decidir qu interfaz debera ver y cmo debera comportarse. A
fin de implementar todo en un entorno web, el diseador debe decidir
adems qu informacin debe ser almacenada.
3. UML-Based Web:Se trata de un mtodo que hace uso de tcnicas
procedentes de la orientacin a objetos para especificar aplicaciones
hipermedia. UWE plantea un enfoque iterativo y progresivo cuyas actividades
fundamentales son el anlisis de requisitos y el diseo conceptual, de la
navegacin y de la presentacin. Los elementos hipermedia se representan
por medio de elementos propios de los diagramas de clases UML. As
por ejemplo, los nodos son clases, los enlaces son asociaciones estereotipadas
y las ayudas a la navegacin (como ndices o mapas) son clases
estereotipadas. Para modelar aspectos dinmicos se hace uso de modelos de
tarea y diagramas de estado, mientras la navegacin y la presentacin se
representan por medio de UML y de estereotipos creados al efecto. Los
principales aspectos en los que se fundamenta UWE son los siguientes: Uso de
una notacin estndar, para todos los modelos (UML: Lenguaje
de modelado unificado). Definicin de mtodos: Definicin de los pasos para
la construccin de los diferentes modelos. Especificacin de Restricciones: Se
recomienda el uso de restricciones escritas (OCL: Lenguaje de restricciones
de objetos) para aumentar la exactitud de los modelos.
Este proceso de autora est dividido en cuatro pasos o actividades:

Anlisis de Requisitos: Fija los requisitos funcionales de la aplicacin

Web para reflejarlos en un modelo de casos de uso. Esto da lugar a los
diagramas de casos de uso.

Diseo Conceptual: Se construye el modelo conceptual del dominio

de la aplicacin considerando los requisitos reflejados en los casos de
uso. El resultado es el diagrama de clases de dominio.

Diseo Navegacional: Se obtienen el modelo de espacio de

navegacin y el de estructura de navegacin, que muestra como
navegar a travs del espacio de navegacin. El resultado son
diagramas de clases que representan estos modelos.

Diseo de Presentacin: Representa las vistas del interfaz del usuario

mediante modelos estndares de interaccin UML.

1.2 Protocolo http

El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un

sencillo protocolo cliente-servidor que articula los intercambios de informacin
entre los clientes Web y los servidores HTTP. Fue propuesto por Tim BernersLee, atendiendo a las necesidades de un sistema global dedistribucin de
informacin como el World Wide Web.

Desde el punto de vista de las comunicaciones, est soportado sobre los

servicios de conexin TCP/IP, y funciona de la misma forma que el resto de los
servicios comunes de los entornos UNIX: un proceso servidor escucha en un
puerto de comunicaciones TCP (por default, el 80), y espera las solicitudes de
conexin de los clientes Web. Una vez que se establece la conexin, el
protocolo TCP se encarga de mantener la comunicacin y garantizar un
intercambio de datos libre de errores.

HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente

establece una conexi con un servidor y enva un mensaje con los datos de la
solicitud. El servidor responde con un mensaje similar, que contiene el estado
de la operacin y su posible resultado. Todas las operaciones pueden adjuntar
un objeto o recurso sobre el que actan; cada objeto Web (documento HTML,
Archivo multimedia o aplicacin CGI) es conocido por su URL.

HTTP se utiliza para transmitir recursos, que incluyen adems de archivos, el

resultado de la ejecucin de un programa, una consulta a una base de datos, la
traduccin automtica de un documento, etc. Para un servidor HTTP, los
recursos son o bien archivos, o bien el resultado de la ejecucin de un
programa.

Los tipos MIME (Multipurpose Internet Mail Extensions) son un estndar para el
envo de informacin binaria a travs de caracteres alfanumricos. Este
estndar permite que, a travs del protocolo HTTP (que maneja informacin en
modo texto), podamos transferir archivos no-textuales, como pueden ser
imgenes, audio, vdeo, programas ejecutables etc. Los tipos MIME definen
grupos (antes del carcter /) y tipos (despus del carcter /). As el tipo
MIME text/html define a todos los archivos de texto que contienen cdigo
HTML, el tipo video/mpeg define a todos los archivos de vdeo almacenados
en formato mpeg, etc. Para indicar cualquier tipo se puede utilizar el carcter
*, tanto en el tipo como en el grupo. De este modo, el tipo MIME image/*

representa a todos los archivos de imagen, ya estn almacenadas en formato

gif, jpeg, bmp, etc.

Para profundizar ms en el funcionamiento de HTTP, veremos primero un caso

particular de una transaccin HTTP; en los siguientes apartados se analizarn
las diferentes partes de este proceso. Cada vez que un cliente realiza una
peticin a un servidor, se ejecutan los siguientes pasos:

Un usuario accede a una URL, seleccionando un enlace de un documento

HTML o introducindola directamente en el campo Location del cliente Web.

El cliente Web descodifica la URL, separando sus diferentes partes. As

identifica el protocolo de acceso, la direccin DNS o IP del servidor, el posible
puerto opcional (el valor por default es 80) y el objeto requerido del servidor.

Se abre una conexin TCP/IP con el servidor, llamando al puerto TCP

correspondiente. Se realiza la peticin. Para ello, se enva el comando
necesario (GET, POST, HEAD,), la direccin del objeto requerido (el contenido
de la URL que sigue a la direccin del servidor), la versin del protocolo HTTP
empleada y un conjunto variable de informacin, que incluye datos sobre las
capacidades del browser, datos opcionales para el servidor,

El servidor devuelve la respuesta al cliente. Consiste en un cdigo de estado

y el tipo de dato MIME de la informacin de retorno, seguido de la propia
informacin.

Se cierra la conexin TCP.

Este proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se

recoge un documento HTML en cuyo interior estn insertadas cuatro imgenes,
el proceso anterior se repite cinco veces, una para el documento HTML y cuatro
para las imgenes.

1.1.1 Peticiones HTTP

Una solicitud HTTP es un conjunto de lneas que el navegador enva al servidor.
Incluye:

Una lnea de solicitud: es una lnea que especifica el tipo de documento

solicitado, el mtodo que se aplicar y la versin del protocolo utilizada. La
lnea est formada por tres elementos que deben estar separados por un
espacio:

el mtodo

la direccin URL

la versin del protocolo

general, HTTP/1.0)

utilizada

por el

cliente

(por

lo

Los campos del encabezado de solicitud: es un conjunto de lneas

opcionales que permiten aportar informacin adicional sobre la solicitud y/o el
cliente (navegador, sistema operativo, etc.). Cada una de estas lneas est
formada por un nombre que describe el tipo de encabezado, seguido de dos
puntos (:) y el valor del encabezado.

El cuerpo de la solicitud: es un conjunto de lneas opcionales que deben

estar separadas de las lneas precedentes por una lnea en blanco y, por
ejemplo, permiten que se enven datos por un comando POST durante la
transmisin de datos al servidor utilizando un formulario.

Por lo tanto, una solicitud HTTP posee la siguiente sintaxis (<crlf> significa retorno
de carro y avance de lnea):
MTODO VERSIN URL<crlf>
ENCABEZADO: Valor<crlf>
. . . ENCABEZADO: Valor<crlf>
Lnea en blanco <crlf>
CUERPO DE LA SOLICITUD
A continuacin se encuentra un ejemplo de una solicitud HTTP:
GET http://es.kioskea.net HTTP/1.0 Accept : Text/html If-Modified-Since : Saturday,
15-January-2000 14:37:11 GMT User-Agent : Mozilla/4.0 (compatible; MSIE 5.0;
Windows 95)

Comandos
Comand
o

Descripcin

GET

Solicita el recurso ubicado en la URL especificada

HEAD

Solicita el encabezado del recurso ubicado en la URL

especificada

POST

Enva datos al programa ubicado en la URL especificada

PUT

Enva datos a la URL especificada

DELETE

Borra el recurso ubicado en la URL especificada

Encabezados
Nombre
del Descripcin
encabezado
Accept

Tipo de contenido aceptado por el navegador (por

ejemplo,texto/html). Consulte Tipos de MIME

Accept-Charset

Juego de caracteres que el navegador espera

Accept-Encoding

Codificacin de datos que el navegador acepta

Accept-Language Idioma que el navegador

predeterminada, ingls)
Authorization

espera

(de

Identificacin del navegador en el servidor

Content-Encoding Tipo de codificacin para el cuerpo de la solicitud

ContentLanguage

Tipo de idioma en el cuerpo de la solicitud

forma

Content-Length

Extensin del cuerpo de la solicitud

Content-Type

Tipo de contenido del cuerpo de la solicitud (por

ejemplo,texto/html). Consulte Tipos de MIME

Date

Fecha en que comienza la transferencia de datos

Forwarded

Utilizado por equipos intermediarios entre el navegador

y el servidor

From

Permite especificar la direccin de correo electrnico del

cliente

From

Permite especificar que debe enviarse el documento si

ha sido modificado desde una fecha en particular

Link

Vnculo entre dos direcciones URL

Orig-URL

Direccin URL donde se origin la solicitud

Referer

Direccin URL desde la cual se realiz la solicitud

User-Agent

Cadena con informacin sobre el cliente, por ejemplo, el

nombre y la versin del navegador y el sistema
operativo

Respuesta HTTP
Una respuesta HTTP es un conjunto de lneas que el servidor enva al navegador.
Est constituida por: Incluye:

Una lnea de estado: es una lnea que especifica la versin del protocolo
utilizada y el estado de la solicitud en proceso mediante un texto explicativo y
un cdigo. La lnea est compuesta por tres elementos que deben estar
separados por un espacio: La lnea est formada por tres elementos que deben
estar separados por un espacio:

la versin del protocolo utilizada

el cdigo de estado

el significado del cdigo

Los campos del encabezado de respuesta: es un conjunto de lneas

opcionales que permiten aportar informacin adicional sobre la respuesta y/o el
servidor. Cada una de estas lneas est compuesta por un nombre que califica
el tipo de encabezado, seguido por dos puntos (:) y por el valor del encabezado
Cada una de estas lneas est formada por un nombre que describe el tipo de
encabezado, seguido de dos puntos (:) y el valor del encabezado.

El cuerpo de la respuesta: contiene el documento solicitado.

Por lo tanto, una respuesta HTTP posee la siguiente sintaxis (<crlf> significa
retorno de carro y avance de lnea):
VERSIN-HTTP CDIGO EXPLICACIN <crlf>
ENCABEZADO: Valor<crlf>
. . . ENCABEZADO: Valor<crlf>
Lnea en blanco <crlf>
CUERPO DE LA RESPUESTA
A continuacin se encuentra un ejemplo de una respuesta HTTP:
HTTP/1.0 200 OK Date: Sat, 15 Jan 2000 14:37:12 GMT Server : Microsoft-IIS/2.0
Content-Type : text/HTML Content-Length : 1245 Last-Modified : Fri, 14 Jan 2000
08:25:13 GMT
Encabezados de respuesta
Nombre
encabezado

del Descripcin

Content-Encoding

Tipo de codificacin para el cuerpo de la respuesta

Content-Language Tipo de idioma en el cuerpo de la respuesta

Content-Length

Extensin del cuerpo de la respuesta

Content-Type

Tipo de contenido del cuerpo de la respuesta (por

ejemplo,texto/html). Consulte Tipos de MIME

Date

Fecha en que comienza la transferencia de datos

Expires

Fecha lmite de uso de los datos

Forwarded

Utilizado por equipos intermediarios entre el navegador

y el servidor

Location

Redireccionamiento a una nueva direccin URL

asociada con el documento

Server

Caractersticas del servidor que envi la respuesta

Los cdigos de respuesta

Son los cdigos que se ven cuando el navegador no puede mostrar la pgina
solicitada. El cdigo de respuesta est formado por tres dgitos: el primero indica
el estado y los dos siguientes explican la naturaleza exacta del error.
Cdig
o

Mensaje

Descripcin

10x

Mensaje
informacin

20x

xito

Estos cdigos indican

ejecucin de la transaccin

200

OK

La solicitud se llev a cabo de manera

correcta

201

CREATED

Sigue a un comando POST e indica el xito, la

parte restante del cuerpo indica la
direccin URL donde se ubicar el documento
creado recientemente.

202

ACCEPTED

La solicitud ha sido aceptada, pero el

procedimiento que sigue no se ha llevado a
cabo

203

PARTIAL

Cuando se recibe este cdigo en respuesta a

de Estos cdigos no se utilizan en la versin

1.0 del protocolo
la

correcta

INFORMATION

un comando de GET indica que la respuesta

no est completa.

204

NO RESPONSE

El servidor ha recibido la solicitud, pero no hay

informacin de respuesta

205

RESET
CONTENT

El servidor le indica al navegador que borre el

contenido en los campos de un formulario

206

PARTIAL
CONTENT

Es una respuesta a una solicitud que consiste

en el encabezado range. El servidor debe
indicar el encabezado content-Range

30x

Redireccin

Estos cdigos indican que el recurso ya no

se encuentra en la ubicacin especificada

301

MOVED

Los datos solicitados han sido transferidos a

una nueva direccin

302

FOUND

Los datos solicitados se encuentran en una

nueva direccin URL, pero, no obstante,
pueden haber sido trasladados

303

METHOD

Significa que el cliente debe intentarlo con una

nueva direccin; es preferible que intente con
otro mtodo en vez de GET

304

NOT MODIFIED

Si
el
cliente
llev
a
cabo
un
comando GET condicional (con la solicitud
relativa a si el documento ha sido modificado
desde la ltima vez) y el documento no ha
sido modificado, este cdigo se enva como
respuesta.

40x

Error debido al Estos cdigos indican que la solicitud es

cliente
incorrecta

400

BAD REQUEST

La sintaxis de la solicitud se encuentra

formulada de manera errnea o es imposible

de responder
401

UNAUTHORIZED

Los parmetros del mensaje aportan las

especificaciones
de
formularios
de
autorizacin que se admiten. El cliente debe
reformular la solicitud con los datos de
autorizacin correctos

402

PAYMENT
REQUIRED

El cliente debe reformular la solicitud con los

datos de pago correctos

403

FORBIDDEN

El acceso al recurso simplemente se deniega

404

NOT FOUND

Un clsico. El servidor no hall nada en la

direccin especificada. Se ha abandonado sin
dejar una direccin para redireccionar... :)

50x

Error debido al Estos cdigos indican que existe un error

servidor
interno en el servidor

500

INTERNAL
ERROR

El servidor encontr una condicin inesperada

que le impide seguir con la solicitud (una de
esas cosas que les suceden a los
servidores...)

501

NOT
IMPLEMENTED

El servidor no admite el servicio solicitado (no

puede saberlo todo...)

502

BAD GATEWAY

El servidor que acta como una puerta de

enlace o proxy ha recibido una respuesta no
vlida del servidor al que intenta acceder

503

SERVICE
UNAVAILABLE

El servidor no puede responder en ese

momento debido a que se encuentra
congestionado
(todas
las
lneas
de
comunicacin se encuentran congestionadas,
intntelo de nuevo ms adelante)

504

GATEWAY

La

respuesta

del

servidor

ha

llevado

TIMEOUT

demasiado tiempo en relacin al tiempo de

espera que la puerta de enlace poda admitir
(excedi el tiempo asignado...)

1.1.2 Servidor Web VS Servidor Aplicaciones

Servidor web
Un servidor web o servidor HTTP es un programa informtico que procesa una
aplicacin del lado del servidor realizando conexiones bidireccionales y/o
unidireccionales y sncronas o asncronas con el cliente generando o cediendo
una respuesta en cualquier lenguaje o Aplicacin del lado del cliente. El cdigo
recibido por el cliente suele ser compilado y ejecutado por un navegador web.
Para la transmisin de todos estos datos suele utilizarse algn protocolo.
Generalmente se utiliza el protocolo HTTP para estas comunicaciones,
perteneciente a la capa de aplicacin del modelo OSI. El trmino tambin se
emplea para referirse al ordenador que ejecuta el programa.
El Servidor web se ejecuta en un ordenador mantenindose a la espera de
peticiones por parte de un cliente (un navegador web) y que responde a estas
peticiones adecuadamente, mediante una pgina web que se exhibir en el
navegador o mostrando el respectivo mensaje si se detect algn error. A modo de
ejemplo, al teclear www.facebook.com en nuestro navegador, ste realiza una
peticin HTTP al servidor de dicha direccin. El servidor responde al cliente
enviando el cdigo HTML de la pgina; el cliente, una vez recibido el cdigo, lo
interpreta y lo exhibe en pantalla. Como vemos con este ejemplo, el cliente es el
encargado de interpretar el cdigo HTML, es decir, de mostrar las fuentes, los
colores y la disposicin de los textos y objetos de la pgina; el servidor tan slo se
limita a transferir el cdigo de la pgina sin llevar a cabo ninguna interpretacin de
la misma.
Adems de la transferencia de cdigo HTML, los Servidores web pueden entregar
aplicaciones web. stas son porciones de cdigo que se ejecutan cuando se
realizan ciertas peticiones o respuestas HTTP. Hay que distinguir entre:
Aplicaciones en el lado del cliente: el cliente web es el encargado de ejecutarlas
en la mquina del usuario. Son las aplicaciones tipo Java "applets" o Javascript: el
servidor proporciona el cdigo de las aplicaciones al cliente y ste, mediante el
navegador, las ejecuta. Es necesario, por tanto, que el cliente disponga de un
navegador con capacidad para ejecutar aplicaciones (tambin llamadas scripts).
Comnmente, los navegadores permiten ejecutar aplicaciones escritas en
lenguaje javascript y java, aunque pueden aadirse ms lenguajes mediante el
uso de plugins.

Aplicaciones en el lado del servidor: el servidor web ejecuta la aplicacin; sta,

una vez ejecutada, genera cierto cdigo HTML; el servidor toma este cdigo recin
creado y lo enva al cliente por medio del protocolo HTTP.
Las aplicaciones de servidor muchas veces suelen ser la mejor opcin para
realizar aplicaciones web. La razn es que, al ejecutarse sta en el servidor y no
en la mquina del cliente, ste no necesita ninguna capacidad aadida, como s
ocurre en el caso de querer ejecutar aplicaciones javascript o java. As pues,
cualquier cliente dotado de un navegador web bsico puede utilizar este tipo de
aplicaciones.
El hecho de que HTTP y HTML estn ntimamente ligados no debe dar lugar a
confundir ambos trminos. HTML es un lenguaje de marcas y HTTP es un
"protocolo".

Algunos servidores web importantes son:

Apache
Tomcat
Cherokee

Servidor de aplicaciones
En informtica, se denomina servidor de aplicaciones a un servidor en una red de
computadores que ejecuta ciertas aplicaciones.
Usualmente se trata de un dispositivo de software que proporciona servicios de
aplicacin a las computadoras cliente. Un servidor de aplicaciones generalmente
gestiona la mayor parte (o la totalidad) de las funciones de lgica de negocio y de
acceso a los datos de la aplicacin. Los principales beneficios de la aplicacin de
la tecnologa de servidores de aplicacin son la centralizacin y la disminucin de
la complejidad en el desarrollo de aplicaciones.
Servidores de aplicaciones Java EE
Como consecuencia del xito del lenguaje de programacin Java, el trmino
servidor de aplicaciones usualmente hace referencia a un servidor de aplicaciones
Java EE. Entre los servidores de aplicacin Java EE privativos ms conocidos se
encuentran WebLogic de Oracle (antes BEA Systems) y WebSphere de IBM.
EAServer de Sybase Inc. es tambin conocido por ofrecer soporte a otros
lenguajes diferentes a Java, como PowerBuilder. Entre los servidores de
aplicaciones libres se encuentran JOnAS del consorcio ObjectWeb, JBoss AS de

JBoss (divisin de Red Hat), Geronimo de Apache, TomEE de Apache, Resin Java
Application Server de Caucho Technology, Blazix de Desiderata Software, Enhydra
Server de Enhydra.org y GlassFish de Oracle.
Mucha gente confunde Tomcat como un servidor de aplicaciones; sin embargo, es
solamente un contenedor de servlets [1].
Java EE provee estndares que permiten a un servidor de aplicaciones servir
como "contenedor" de los componentes que conforman dichas aplicaciones. Estos
componentes, escritos en lenguaje Java, usualmente se conocen como Servlets,
Java Server Pages (JSPs) y Enterprise JavaBeans (EJBs) y permiten implementar
diferentes capas de la aplicacin, como la interfaz de usuario, la lgica de negocio,
la gestin de sesiones de usuario o el acceso a bases de datos remotas.
La portabilidad de Java tambin ha permitido que los servidores de aplicacin
Java EE se encuentren disponibles sobre una gran variedad de plataformas, como
Unix, Microsoft Windowsy GNU/Linux.