Historia de Internet y de las aplicaciones Web, así como algunos de los principios de la virtualización

1. APLICACIONES WEB
2.1 Historia de Internet
En los años 60’s, la Agencia de Proyectos de Investigación Avanzados (ARPA por
sus siglas en inglés) del Departamento de Defensa de los Estados Unidos, inició la creación
de una red para comunicar entre sí una docena de Universidades (auspiciadas por ARPA) e
Instituciones de Investigación. De esta iniciativa nació la red ARPANET, abuela de la red
global que ahora llamamos Internet (Deitel, Deitel y Goldberg, 2004).
La red operaba con una técnica llamada conmutación de paquetes (packet
switching), en la cual los datos se enviaban digitalmente en pequeños trozos llamados
paquetes. Estos paquetes contenían la dirección fuente (punto de origen), la dirección de su
destino, e información para control de errores y secuenciación. Esta información permitía
que los paquetes llegaran a su destino y fueran re-ensamblados en su orden original, pues
éstos podían llegar en un orden diferente, además de que se mezclaban en el camino con los
paquetes de otros remitentes. Esta técnica permitía bajar los costos de transmisión, evitando
la contratación de costosas líneas privadas dedicadas entre cada par de puntos. La red se
diseñó para operar sin un control centralizado, de modo que si una porción llegara a fallar,
el resto de la red aseguraría la entrega de los paquetes por una ruta alterna.
En 1977 ARPANET adoptó el protocolo TCP (Transmission Control Protocol),
definido conceptualmente en 1974 por Vin Cerf y Bob Kahn (Laudon, & Travel, 2006).
TCP establece las conexiones entre computadoras, y asegura que los paquetes enviados por
una computadora, sean recibidos en la misma secuencia por la otra, sin que se pierda
ninguno.
A medida que Internet evolucionaba, muchas empresas crearon redes tanto dentro
de sus unidades organizacionales como entre compañías. Y para enfrentar el reto de
interconectar redes diferentes tanto en hardware como en software, ARPA desarrolló el
protocolo IP (Internet Protocol), dando nacimiento a una verdadera red de redes.
El protocolo IP provee el esquema de direccionamiento de Internet y es el
responsable de la distribución real de los paquetes o datagramas. Una dirección de Internet,
conocida como dirección IP, es un número de 32 bits que aparece como una serie de 4
números separados por puntos. Cada uno de los cuatro números puede variar entre 0 y 255.
La versión actual de IP se llama Versión 4, o IPv4. Una nueva versión del protocolo IP,
llamada IPv6 está siendo adoptada. IPv6 provee direcciones de 128 bits. La combinación de
este grupo de protocolos se nombró TCP/IP, el cual ha llegado a ser el protocolo principal
del Internet.

2. Figura 2.1. Protocolo TCP/IP (Rodriguez, Gatrell, Karas & Peschke, 2001)
Como la mayoría del software de redes, TCP/IP está modelado en capas. Esto puede
observarse en la figura 2.1. Es por esto que se utiliza el término “stack” (pila) de protocolo,
que se refiere a la pila de capas del protocolo. Separar el software de comunicación en
capas, permite dividir el trabajo, facilitar la implantación y probar el código, así como el
desarrollo de capas alternativas. También se puede utilizar para posicionar el protocolo
contra otros como el SNA (Systems Network Architecture) y el modelo OSI (Open System
Interconnection)
La figura 2.2 muestra del lado izquierdo las capas y del derecho las partes del
protocolo. Cada capa representa un paquete de funciones del protocolo.
Figura 2.2 Modelo detallado del protocolo TCP/IP (Rodriguez, Gatrell, Karas &
Peschke, 2001)
En la figura 2.2 aparecen con mayor énfasis las relaciones entre las capas del
modelo y la pila de funciones del protocolo TCP/IP. El nivel de interfase de red y hardware
se corresponde con los estándares de transmisión Ethernet, TokenRing, etc., el de Inter-
Redes con las funciones IP, ICMP, ARP y RARP, el de Transporte con TCP y UDP y el de
Aplicaciones con herramientas como SMTP (se usa para correo electrónico), Telnet y FTP
(Rodriguez, Gatrell, Karas & Peschke, 2001).
A pesar de que en un principio Internet estaba limitado a Universidades y Centros
de investigación, la red se extendió a la milicia y eventualmente el Gobierno decidió abrir

3. el acceso para uso comercial. Esta situación causó cierto recelo entre las comunidades que
utilizaban la red, pues se creía que la capacidad se iba a saturar al agregar más usuarios,
pero cuando las empresas comprendieron que podían realizar sus operaciones y ofrecer más
y mejores servicios a sus clientes, invirtieron vastas cantidades de dinero en mejorar y
crecer la red, dando lugar a una fiera competencia entre “carriers” (proveedores de acceso a
la red) y proveedores de hardware y software. El resultado es que al contrario de lo que
pensaban las comunidades iniciales, el ancho de banda (la capacidad para transportar
información) para uso de Internet se ha incrementado tan estrepitosamente como los costos
han caído (Deitel, , Deitel y Goldberg., 2004).
2.2 Arquitectura cliente-servidor
En los inicios de la computación (40’s), todos los programas y cada pieza de
información se almacenaban de forma centralizada en una misma computadora –llamada
mainframe-, la cual contaba con gran capacidad (memoria, procesador y disco). Todos los
demás usuarios accedían a la computadora central a través de terminales “tontas”
(solamente contaban con monitor y teclado; no tenían procesador, memoria ni disco) (Ortiz,
2001).
En los 80’s, la llegada de computadoras personales baratas produjeron el popular
modelo cliente-servidor o de dos capas. Bajo este modelo, hay una aplicación ejecutándose
en el cliente (PC o “personal computer”), la cual interactúa con el servidor (típicamente un
sistema de administración de base de datos). La aplicación cliente, también conocida como
“cliente grueso”, contenía parcial o totalmente la lógica de presentación (interfase del
usuario), la navegación por la aplicación, las reglas del negocio y el acceso a la base de
datos. Cada vez que las reglas del negocio cambiaban, la aplicación cliente tenía que
modificarse, probarse y redistribuirse a todos los usuarios, incluso si la interfase del usuario
permanecía intacta (Ortiz, 2000).
Figura 2.3. Modelo cliente-servidor
La figura 2.3 muestra la forma en que funciona el modelo de dos capas: la estación cliente
contiene la aplicación, que al identificar que requiere más información, envía una consulta
al servidor de la base de datos, quien la procesa y devuelve el resultado (típicamente unos
cuantos registros) por la red, de regreso al cliente. Aunque TCP es un protocolo orientado a
conexión punto a punto, donde no hay relaciones maestro-esclavo, las aplicaciones sí
utilizan un modelo cliente-servidor para sus comunicaciones.

4. El cliente es el solicitante de un servicio, mientras el servidor es una aplicación que
ofrece ese servicio a usuarios de Internet. Los usuarios invocan la parte cliente de la
aplicación, que construye una solicitud de un servicio en particular y lo envía a la parte
servidor de la aplicación, usando TCP/IP como vehículo de transporte. Las computadoras
cliente típicamente solicitan imprimir, recuperar información y acceder a bases de datos.
El servidor es un programa que recibe una solicitud, llama al servicio requerido y
envía los resultados de regreso en una respuesta. Un servidor usualmente puede trabajar con
múltiples solicitudes y múltiples clientes al mismo tiempo (Rodriguez, Gatrell, Karas &
Peschke, 2001). Los servidores pueden realizar funciones comunes que necesitan las
computadoras cliente conectadas al servidor, tal como el almacenamiento y compartición
de archivos, programas e impresoras (Laudon & Traver, 2006).
.
Figura 2.4. Modelo cliente/servidor de las aplicaciones (Rodriguez, Gatrell,
Karas & Peschke, 2001)
En la figura 2.4 se puede apreciar que las aplicaciones que utilizan el modelo
cliente/servidor se comunican usando el protocolo TCP/IP a través de la red.
La arquitectura cliente servidor tiene muchas ventajas sobre la arquitectura
mainframe. Por ejemplo, se balancea la carga de procesamiento sobre muchas
computadoras pequeñas poderosas en lugar de concentrarse en sólo una gran computadora
que realice procesamiento para todos (Laudon & Traver, 2006). Esta arquitectura se utiliza
tanto en redes locales (LAN o “local area network”), de área amplia (WAN o “wide area
network”) y el Web. El Web es un sistema de distribución de información basado en
hipertexto o hipermedios enlazados y accesibles a través de Internet (World Wide Web,
s.f.)
Con la explosión del uso público de Internet, nacieron las aplicaciones Web. La
primera etapa de este fenómeno utiliza el modelo cliente-servidor, en donde millones de
servidores Web ubicados por todo el mundo pueden ser fácilmente accedidos por millones
de computadoras cliente ubicadas también por todo el mundo. Los servidores entregan a los
usuarios típicamente contenido estático.

5. Cuando uno utiliza su conexión de Internet para ser parte de la Web, la computadora
se convierte en un cliente Web de una red mundial del tipo cliente – servidor. Un software
de navegación (browser) como Internet Explorer (Microsoft ™), FireFox (Mozilla ™),
Opera (Opera ™), Netscape (Netscape ™), Chrome (Google ™) o Safari (Apple ™) es lo
que permite a la computadora convertirse en un cliente Web. El cliente Web recupera
documentos almacenados en uno o varios servidores Web, quienes procesan las peticiones
de los clientes. Usando la red como medio de transporte, los clientes solicitan archivos de
un servidor distante, utilizando el protocolo HTTP (Protocolo de Transferencia de
Hipertexto o “Hypertext Transfer Protocol”) para formatear la solicitud. El servidor
recupera el archivo que contiene la información (o página Web), la formatea usando el
estándar HTTP y la devuelve al solicitante. Cuando la información solicitada llega a la
computadora cliente, el navegador la despliega de acuerdo a las instrucciones definidas en
el código HTML (lenguaje de marcación de hipertexto o “hypertext markup language”).
Una página Web que contenga muchos gráficos y objetos multimedia (audio y video) se
puede desplegar con lentitud en el cliente, debido a que cada elemento requiere una
solicitud y una respuesta por separado. El modelo cliente-servidor básico es un modelo de
dos capas porque solamente se involucra un cliente y un servidor (Schneider, 2002).
2.3 Arquitectura de tres capas
Con el objetivo de minimizar el impacto sobre las aplicaciones cliente al alterar la
lógica del negocio, la lógica de presentación debía ser separada de las reglas del negocio.
Esta separación es el principio fundamental en la arquitectura de tres capas (Ortiz, 2001),
en la cual cada una tiene responsabilidades específicas.
Capa 1: contiene la lógica de presentación, incluyendo control simple y validación
de entrada del usuario. Esta aplicación es conocida como cliente delgado.
Capa 2: a la capa intermedia también se le conoce como servidor de aplicaciones, el
cual provee la lógica de los procesos del negocio (funcionalidad de la aplicación) y el
acceso a los datos.
Capa 3: consiste de servidores de bases de datos que proveen los datos del negocio.
La arquitectura de tres capas tiene como ventajas que es más fácil modificar o
reemplazar cualquier capa sin afectar a las otras, que se balancea mejor la carga de trabajo
y que se pueden forzar las políticas de seguridad dentro de las capas del servidor sin afectar
a los clientes.
Figura 2.5. Modelo de tres capas

6. La figura 2.5 muestra la forma en que fluye la información cuando un cliente
solicita una consulta. El cliente abre la solicitud, el servidor la recibe y cuando identifica
que requiere apoyo de la base de datos, construye una consulta ó “query”, la cual envía al
servidor de base de datos, que la procesa y devuelve el resultado al servidor, quien
finalmente la devuelve al cliente.
Aunque la arquitectura cliente-servidor de dos capas trabaja bien para entregar
páginas Web, un sitio Web que soporta comercio electrónico (actividades comerciales
conducidas por la transmisión de datos electrónicos a través de Internet y el Web) necesita
más funcionalidad que eso.
Una arquitectura de tres capas extiende la arquitectura cliente-servidor para permitir
procesamiento adicional antes de que el servidor Web responda a la solicitud del cliente.
También existen modelos de cuatro, cinco o más capas, a los cuales se llama arquitecturas
n-capa (multi capa). La tercer capa incluye aplicaciones de software que suministran
información al servidor Web, para que éste pueda responder al cliente. Los modelos de más
capas incluyen además las bases de datos y los programas de administración de éstas, que
trabajan para generar información que el servidor pueda transformar en páginas Web y
devolverlas al solicitante.
Un buen ejemplo es un sitio Web tipo catálogo que soporte funciones de búsqueda,
que registre las compras del cliente en su “carrito de compras”, busque el porcentaje de
impuestos a aplicar, almacene las preferencias del consumidor, busque en las bases de datos
los inventarios de productos y mantenga los catálogos actualizados. Cuando un usuario
solicita una búsqueda al catálogo, el navegador estructura la solicitud en formato HTTP y la
envía al servidor a través de Internet. El servidor Web identifica que se requiere
información de la base de datos y envía una solicitud al software de administración de la
base de datos para que procese la búsqueda y la devuelva al servidor Web, el cual formatea
la respuesta en HTML y la devuelve al cliente (Schneider, 2002).
2.4 Servidores Web.
Todos los sitios de comercio electrónico requieren un servidor Web básico para
responder a peticiones de clientes. Como puede observarse en la figura 2.6, que muestra la
participación en el mercado de servidores Web, el software con casi 70% del mercado es
Apache, el cual es libre y trabaja bajo el sistema operativo Unix, o su variante en PC Linux
y Windows. El segundo servidor de Web en importancia es Microsoft Internet Information
Service (IIS), el cual tiene aproximadamente el 20% del mercado y está basado en el
sistema operativo Windows (Laudon & Traver, 2006).

7. Figura 2.6. Participación de mercado servidores Web (netcraft.com, 2009)
Apache es uno de los Servidores Web más utilizados, posiblemente por su
versatilidad, pues su instalación es sencilla para sitios pequeños y por otro lado es posible
expandirlo hasta el nivel de los mejores productos comerciales en caso de ser necesario. Si
se utiliza solamente para “servir” archivos en formato HTML para un sitio WEB pequeño,
su funcionalidad es excelente.
Las funcionalidades básicas proporcionadas por los servidores Web son:
procesamiento de peticiones HTTP, servicios de seguridad, transferencia de archivos,
búsquedas basadas en palabras clave, registro de datos (visitas, tiempo, duración), envío y
recepción de correo electrónico y herramientas de administración de sitios. (Servidor Web,
s.f.)

8. Figura 2.7. Servidor WEB.
En la Figura 2.7 se puede observar la interacción entre diferentes navegadores y el
servidor Web. El navegador ("Firefox", "Explorer", etc.) inicia la interacción solicitando
información al servidor de páginas WEB. Esta solicitud se realiza mediante HTTP, y ya que
llega al Servidor, se pueden tomar diversas acciones, tales como consultar bases de datos o
transferir archivos.
2.5 Servidores de Aplicaciones
Los servidores de Aplicaciones son programas que proveen funcionalidades de
negocio específicas requeridas por el sitio web. Los servidores de aplicación se ubican en la
capa 2 de los modelos multi-capa. Son quienes proveen la lógica de los procesos del
negocio y el acceso a los datos.
Cuando nacieron los primeros servidores Web (Apache por ejemplo), éstos
solamente enviaban las páginas al cliente, pero cualquier otra información que requiriera
procesamiento, la realizaba un interpretador que ejecutaba un programa en algún lenguaje
como Perl, como se puede apreciar en la figura 2.8. Sin embargo, la participación del
intérprete demandaba mucha carga sobre el servidor.

9. Figura 2.8. Servidor de aplicaciones
Cuando el servidor de aplicaciones recibe la petición http, es capaz de identificar si
solamente necesita entregar contenido estático en HTML o se requiere algún tipo de
procesamiento. En caso de requerirlo, el servidor invoca a una aplicación (programa) en
Perl, que a su vez puede llamar a la base de datos. Esto implica que se iniciaron dos nuevos
procesos para responder a cada solicitud. Para llevar a cabo el proceso de forma más
eficiente surgieron otros lenguajes como PHP y Python. Apache al igual que los demás
servidores, fueron integrando diversos módulos a su instalación base, que le permitieron
con el tiempo funciones como la conexión a una base de datos.
Figura 2.9. Servidor de aplicaciones con “Threading”
Para reducir la carga sobre el servidor WEB, nacieron productos con la capacidad de
compartir el proceso general en varios sub-procesos llamados “Threads” (hilos de
procesamiento), lo cual hizo más eficiente el manejo de las conexiones de los clientes. Uno
de los primeros ejemplos de esta característica lo mostró el servidor AOL Server, de
America Online. Otra característica interesante del AOL Server es que evita generar un
nuevo proceso por cada aplicación de servidor, gracias a un intérprete interno del lenguaje
TCL (ver figura 2.9). Finalmente y con el mismo propósito, maneja grupos de conexiones
latentes (o “pools”) hacia las bases de datos.
AOL Server cuenta con una tecnología llamada ADP (AOL Dynamic Pages), que al
igual que ASP (Active Server Pages) de Microsoft y JSP (Java Server Pages) de Sun,
mezcla elementos de HTML con elementos de programación para generar contenido
dinámico.
Actualmente, se puede decir que todos los servidores WEB se pueden usar también
como servidor de aplicaciones, pues tienen funcionalidades que les permite ejecutar
aplicaciones.
Por otro lado, existen servidores de aplicación que pueden trabajar en conjunto con
el ambiente de programación Java, en forma de “servlets”: los “Java Application Servers”,
que aunque tienen algunas diferencias, también son llamados de forma genérica, Servidores
de Aplicación. (Servidores de páginas, 2005). Pero ¿Qué es Java y qué son los “servlets”?
A continuación se hará una descripción de ellos.

10. 2.5.1 Servidores de aplicaciones Java
Java es un lenguaje de programación que al mismo tiempo es un ambiente de
desarrollo y un ambiente de ejecución de aplicaciones. Desde el año 1995, se podía
descubrir que Java no funcionaría solamente para el lado del cliente, sino que sería además
un excelente lenguaje del lado del servidor. Un lenguaje muy bien diseñado, que se sentía
como C++, pero sin sus dolores de cabeza. Para ese entonces, Java corría en un lugar donde
ningún lenguaje lo había hecho antes: dentro del navegador. Aunque esto lo hacía algo
lento y consumidor de memoria, ocupaba un nicho especial. A los objetos Java corriendo
sobre el navegador se les llama “applets”. Java era además fácil de usar y portable. Con el
tiempo los desarrolladores comenzaron a poner atención a la velocidad, lo cual finalmente
vino con las subsecuentes versiones de JDK (“Java Developer Kit” o “herramientas para
desarrolladores de Java”). Aunque era un conjunto de herramientas más completo, la
simplicidad siguió ahí. (Travis, 2002).
Posteriormente nació la tecnología .NET que actualmente rivaliza con Java, o más
bien con su “plataforma de software” anteriormente llamada J2EE (Java 2 Platform
Enterprise Edition) y que ahora evolucionó a JEE (Java Platform Enterprise Edition). Sin
embargo, JEE como grupo de especificaciones del denominado “Java Application Server”
tiene como ventaja la libertad de elección entre vendedores, pues sus componentes pueden
inter-operar entre productos desarrollados por IBM, HP, SUN, BEA (que como ya se
mencionó fue adquirido por Oracle), etc., mientras que en .NET todo gira alrededor de un
mismo vendedor: Microsoft. Cabe mencionar que a futuro la verdadera independencia de
sistemas la tienden a ofrecer las tecnologías “Web services” (como XMLRPC y SOAP) que
están basadas en XML y ofrecerán dentro de poco un puente entre J2EE y .NET (Osmosis
latina, 2005).
A los objetos Java ejecutándose en el lado del servidor se les llama “servlets”: así,
se tienen “applets” en el navegador (cliente) y “servlets” en el servidor. Los “servlets”
apoyan la idea de ejecutar el trabajo en el servidor (back end) y dejar el cliente como
interfaz (front end). Entre los productos que pueden funcionar como “servlets” se
encuentran: Apache Tomcat (http://jakarta.apache.org/tomcat/), Allaire/Macromedia JRun
(Adquirido por Adobe ™) (http://www.macromedia.com/software/jrun/), New Atlanta
ServletExec (http://www.servletexec.com/), Gefion Software LiteWebServer
(http://www.gefionsoftware.com/LiteWebServer/), GlassFish (http://glassfish.java.net y
Caucho's Resin (http://www.caucho.com/).
El uso de “servlets” se ha vuelto un estándar para el desarrollo de aplicaciones Web
que antes se programaban utilizando Perl (CGI), Shell o C++, debido a que la mayoría de
los fabricantes lo soportan. Esto ha vuelto a las aplicaciones fácilmente portables. Por otro
lado, usando CGI el servidor arranca un proceso nuevo por cada petición CGI, lo que lo
hace ineficiente. Esto no sucede utilizando “servlets”.

11. Figura 2.10. Funcionamiento de un Servlet.
En la figura 2.10 se muestra la petición del “browser” (navegador) al servidor Web
que a su vez aloja un servidor de aplicaciones Java, el cual utiliza la función service(), que
es el motor de un servlet, el cual atiende peticiones recibiendo dos parámetros (objetos del
tipo Servlet Request y ServletResponse). El primero encapsula la petición del cliente y el
segundo encapsula la respuesta.
Los “Java Application Servers” son servidores diseñados para soportar el grupo de
especificaciones JEE (Java Platform Enterprise Edition) del Java de Sun, el cual difiere de
la versión estándar en que añade librerías que proveen funcionalidad para entregar software
de Java multi-capa, distribuido y tolerante a fallas, basada en componentes modulares
ejecutándose sobre un servidor de aplicaciones (Java EE, s.f.). Estos servidores de
aplicación se llaman a menudo Middleware, por encontrarse en la parte media de la
arquitectura del sistema. Su flexibilidad consiste en la posibilidad de acceder a información
de sistemas empresariales (EIS o Enterprise Information Systems) como SAP o PeopleSoft,
a bases de datos o aplicaciones heredadas escritas en lenguajes antiguos como COBOL.
Como se puede observar en la figura 2.11, los dos elementos primordiales en estos
servidores son el “Servlet Engine (Web-Container)” y el “Enterprise Bean Engine” (Bean-
Container). El primero ofrece un ambiente para JSP y Servlets, mientras que el segundo
ofrece un ambiente donde residen los EJB (Enterprise Java Beans), que es mediante los
cuales se ejecuta la lógica del negocio sobre la información residente en los sistemas
empresariales (EIS). En el “Bean Container” (al igual que un “Web-Container”) se
contemplan funcionalidades como: “Pooling” hacia bases de datos (usando JDBC), control
de transacciones (JTA-JTS), conectividad a ERP’s (conectores) y aplicaciones legadas
(CORBA).

12. Figura 2.11. Java Application Server.
Esta arquitectura permite la separación de funciones y el uso de protocolos como
RMI/CORBA que facilitan la existencia de varios servidores en diferentes regiones
geográficas, cada uno utilizando alguno de los componentes de la arquitectura.
Entre los “Java Application Servers” denominados “Fully J2EE/JEE Compliant” o
que cumplen con todas las especificaciones J2EE/JEE de Sun, se encuentran: WebLogic
(Antes BEA Systems, hoy Oracle), comercial; WebSphere (IBM), código abierto; Oracle
Application Server (Oracle –se reemplazó por WebLogic) y Sun Application Server (Hoy
denominado GlassFish) (Servidores de páginas, 2005; Campbell, 2008).
2.5.2 Apache Tomcat
En los 90’s, Sun Microsystem desarrolló un servidor WEB, que posteriormente
(1999) cedió a la fundación Apache con todo y su código fuente (Servidores de páginas,
2005). Este producto se llama Tomcat. Tomcat es un servidor de aplicaciones que trabaja
con Java como contenedor de “servlets”. Es un “Servlet Engine”, o “Web Container” que
aunque desde el principio ha sido llamado “Apache Tomcat” no requiere estrictamente del
servidor WEB Apache para su funcionamiento, sino de un JDK (Java Development Kit o
Paquete de Desarrollo de Java).
Figura 2.12. Servlet Engine

13. Las trayectorias en color rojo de la figura 2.12 ilustran que el “Servlet Engine”
puede funcionar como servidor WEB al responder a solicitudes HTTP. Sin embargo,
muchas instalaciones de “Servlets Engines” utilizan adicionalmente un servidor WEB, que
normalmente es más eficiente con la entrega de contenido HTML estático y tiene mejores
características de seguridad, como el uso de encriptación. Por ejemplo, las instalaciones de
Tomcat, típicamente van acompañadas de un servidor Apache.
Las trayectorias en color verde de la figura muestran la forma en que se combina el
“Servlet Engine” (Web-Container) con un servidor WEB. Ambos servidores se comunican
mediante el protocolo AJP12 (Apache Jserv PRotocol) o AJP13.
El “Servlet Engine” ofrece un “ambiente” donde habitan los JSP (que se traducen a
servlets)) y los Servlets. El Servlet provee funciones como el “threading”, el manejo de
sesiones y la conexión con el servidor WEB (razón por la cual se denomina Web-
Container).
Tomcat es un “Servlet Engine” “open source” (de código abierto de libre uso y sin
costo) muy utilizado en combinación con servidores WEB. Existen otros “Servlet Engines”
como ServletExec (con licencia comercial) y Resin (“open source”) que también se
combinan con servidores WEB.
Para utilizar estos servidores de aplicación se requiere el componente JDK (“Java
Development Kit” o paquete de Desarrollo de Java), quien lleva a cabo la ejecución de los
programas (Servlets y JSP’s) en Java. Existen varias versiones de JDK, pues cada una está
diseñada para diferente sistema operativo. A esto se le denomina en particular JVM (“Java
Virtual Machine” o Máquina virtual de Java). Existen versiones particulares de JDK (como
la de IBM) y otras más generales (como la JSE o Java Standard Edition y la JEE o Java
Enterprise Edition).
2.6 Virtualización
La virtualización consiste en crear una versión ya sea extendida o consolidada de un
recurso como un sistema operativo, un servidor, un dispositivo de almacenamiento o un
recurso de red, agregando un nivel de abstracción entre esta versión y la real. Se utiliza
virtualización cuando se fragmenta el ancho de banda de un enlace en canales que pueden
funcionar como si se tratara de enlaces independientes. Otra aplicación es la creación de
tablas de ruteo virtuales dentro de un ruteador (como lo ofrece Cisco Systems en sus
equipos de ruteo de última generación), dando la apariencia de que se tienen varios
ruteadores independientes en un mismo hardware. En cuanto a dispositivos de
almacenamiento, se utiliza virtualización cuando se agrupan diferentes discos conectados a
la red, para que aparezcan como un solo disco o cuando se particiona un disco duro y
aparece como si fueran varias unidades independientes (Virtualization, 2008).
La virtualización de servidores por su parte, se refiere a la metodología que se
utiliza para dividir los recursos de una computadora en múltiples ambientes de ejecución.
Esto permite ejecutar diferentes sistemas operativos al mismo tiempo sobre un mismo
hardware, compartiendo sus recursos (memoria, disco, procesador y tarjetas de red) y
mostrando al usuario final equipos de cómputo independientes. Inicialmente se instala

14. directamente sobre el hardware el primer sistema operativo, de manera normal. A este
sistema operativo se le llama “host” o principal. Enseguida se instala el software de
virtualización (e.g. VmWare, Virtuozzo, Xen, Virtual PC), encargado de crear la capa
intermedia capaz de generar máquinas virtuales y finalmente se pueden montar diferentes
sistemas operativos que se ejecutan sobre el software de virtualización. Estos sistemas
operativos se llaman “guest” o invitados y funcionan de manera aislada, como si fueran
totalmente independientes. Es decir, cuentan con sus “propios” dispositivos de red,
almacenamiento, procesador y memoria (hardware virtual), pero lo que sucede es que los
emulan compartiendo sus recursos con el hardware real.
Utilizar esta tecnología (Virtualización) puede tener un impacto negativo en el
desempeño de la aplicación que se va a insertar en este ambiente, por lo que es necesario
considerar algunos aspectos que se mencionarán en el capítulo de “Optimización de
Aplicaciones Web”. Sin embargo, existen muchas ventajas, como las que se mencionan a
continuación.
Moverse hacia un ambiente de virtualización ofrece beneficios relacionados
directamente con los costos y la administración de una aplicación Web. A continuación se
mencionan algunos de ellos:
 Espacio en el Site
Cuando se cuenta con servidores de diferentes fabricantes y modelos, se requiere
reservar espacio especial en el site de cómputo de la empresa para cada tipo de
disposición física (servidores tipo torre, rackeables de diferente altura,
computadoras personales, minicomputadoras, mainframes, etc.), lo cual obliga a
dispersar los servidores, ocupando mayor espacio. Como la virtualización permite
integrar en un mismo equipo físico diferentes servidores virtuales, la cantidad de
equipos decrece y el espacio requerido es menor. Si este espacio fuera rentado, esta
reducción impactaría directamente sobre el costo, reduciéndolo también
dramáticamente.
 Energía eléctrica y enfriamiento
Si la relación (siendo conservadores) de consolidación es 3:1; es decir, tres
servidores virtualizados por cada servidor físico, el requerimiento de energía
eléctrica (y su costo asociado) se reduce en esta misma relación. Adicionalmente, el
costo de enfriar cada servidor se puede entonces reducir en la misma proporción,
duplicando los ahorros (se asume que el costo de energizar un equipo es comparable
con el costo de enfriarlo).
 Administración
El despliegue de nuevos servidores normalmente consume demasiado tiempo
debido a la instalación de varios elementos para soportar la operación de la
aplicación que se va a instalar: el sistema operativo, los parches de seguridad, los
controladores de los dispositivos y el software necesario (bases de datos,
middleware, plug-ins). Por el contrario, en un ambiente de virtualización es posible
seguir este proceso sólo para el primer servidor y guardar una imagen de éste,
copiando en algún medio secundario o remoto todos los archivos que conforman al
servidor virtual. Para desplegar los siguientes servidores ya no es necesario seguir el

15. mismo proceso, pues en su lugar solamente hay que recuperar la “imagen” y partir
de ésta para instalar la nueva aplicación, reduciendo el tiempo del despliegue
generalmente a minutos (dependiendo del tamaño de los archivos) y disminuyendo
también la complejidad.
El soporte técnico también se facilita, debido a la homogeneidad de plataformas
virtuales. Por ejemplo, un grupo de máquinas virtuales con Linux, utiliza los
mismos controladores, pues el hardware es común, y si los servidores físicos
también están agrupados en un “enclosure”(gabinete con fuentes de poder, abanicos
y puertos de red) para servidores tipo blade, la homogeneidad beneficia a todos los
blades que utilicen el mismo sistema operativo. En consecuencia, el mantenimiento
a cualquiera de estos servidores virtualizados se puede realizar con el mismo
conocimiento de solamente uno de ellos.
 Recuperación
La recuperación de un servidor en caso de un desastre es mucho más rápida, debido
a que las máquinas virtuales están almacenadas en simples archivos. Se puede
recuperar la instalación inicial de un respaldo de la máquina virtual y luego
recuperar los datos o se puede tener un esquema de respaldo incremental de la
máquina virtual y recuperar el servidor completo en poco tiempo. Esta recuperación
se puede hacer en el mismo equipo o en otro diferente, sin tener prácticamente
problemas de compatibilidad, pues los controladores del sistema operativo son
también virtuales. Existen herramientas,como VmWare vmotion, que
automáticamente mantienen copias de las máquinas virtuales en diferentes lugares
(servidores o localidades) y pueden recuperarlas en cuestión de segundos.
Hay dos métricas que se utilizan para describir el estado deseado después de un
desastre. Estas métricas son RTO o Tiempo de Recuperación Objetivo (Tiempo
máximo aceptable que un servicio puede estar sin operar a causa del desastre) y
RPO o Punto de Recuperación Objetivo (Cantidad máxima de datos perdidos que es
aceptable como parte del desastre). La cantidad de “imágenes” recuperadas en sitios
alternos y la habilidad de ponerlas en línea gracias a las características de la
virtualización, impactan directamente estas métricas.
Otra ventaja que tiene la virtualización contra instalar “n” cantidad de aplicaciones
en el mismo servidor (sin virtualizar) es que las aplicaciones se encuentran aisladas
y la falla en un componente (por ejemplo, el servidor Web) no afecta a las demás
aplicaciones.
 Licenciamiento
En general, cada sistema operativo instalado, se virtualice o no, requiere el pago de
una licencia. Sin embargo, compañías como Microsoft ofrecen para algunas
versiones de sus sistemas operativos, esquemas de licenciamiento que permiten
utilizar cuatro licencias virtualizadas por cada licencia física adquirida (2003 Server
Enterprise). Microsoft, en su versión DataCenter, tiene soluciones donde ofrece uso
ilimitado de licencias virtualizadas. Esto por supuesto reduce los costos de
adquisición de software.
 Portabilidad
Todos los fabricantes de software que ofrecen soluciones de virtualización tienen en
común que reducen las máquinas virtuales a un contenedor (como una carpeta)

16. donde se ubican los archivos necesarios para que se ejecute la máquina virtual. Esta
sencillez permite crear “appliances” virtuales. Esto es, máquinas virtuales
preinstaladas con un propósito específico, que se pueden abrir dentro de cualquier
virtualizador (del mismo fabricante). Por ejemplo, se puede instalar VmWare Server
sobre Linux y crear dentro de un servidor HP modelo Proliant una máquina virtual
con Windows que ofrezca servicios de DNS/DHCP. Una vez creada, se puede
almacenar en un repositorio y llevarse posteriormente a otra localidad y montarse
sobre un servidor IBM eSeries. Debido a esta portabilidad es que algunos
fabricantes tienen versiones de su software específicamente para abrir y correr
máquinas virtuales (VmWare por ejemplo tiene VmWare Player).
Existen diferentes tipos de virtualización: Virtualización de Hardware,
Virtualización de Sistema Operativo, Paravirtualización y Virtualización de
Aplicaciones (Shields, 2008). A continuación se describe cada una de ellas.
2.6.1 Virtualización de Hardware
Figura 2.13. Virtualización de hardware(Shields, 2008)
La virtualización de hardware consiste en replicar los recursos internos de cada
máquina virtual (ver figura 2.13). Cada máquina virtual es atómica y solicita recursos
físicos a través de la capa de virtualización (Hipervisor), la cual actúa como un Proxy entre
las máquinas virtuales (con hardware virtual) y el hardware real.
Entre los productos comerciales que utilizan virtualización de hardware se
encuentran: Microsoft Virtual Server, VMware Server y VMware ESX

17. 2.6.2 Virtualización del Sistema Operativo
Figura 2.14. Virtualización de Sistema Operativo
Con la virtualización de Sistema Operativo, la capa de virtualización (Hipervisor)
desaparece y aunque cada máquina virtual es independiente, comparten su hardware con el
Sistema Operativo Host. Esto ocasiona que al no necesitar la emulación de hardware, el
desempeño mejora, pero los Sistemas Operativos huésped y el Host deben ser exactamente
iguales, incluso en actualizaciones (Service Pack). Cada máquina virtual es como una
“imagen” del software que la conforma. Debido a este efecto se elimina la duplicación de
archivos y configuraciones dentro de cada máquina virtual.
Entre los productos comerciales que utilizan virtualización de sistema operativo se
encuentra el Parallels Virtuozzo Containers.
2.6.3 Paravirtualización
Figura 2.15. Paravirtualización

18. La paravirtualización opera de manera parecida a la Virtualización de Hardware,
solamente que en lugar de emular hardware, ofrece una API (Application Programming
Interface o Interfase de Programación de Aplicaciones) especial a los Sistemas Operativos
huésped, con lo cual el desempeño mejora notablemente. Sin embargo, para poder
aprovechar la API, el Sistema Operativo debe estar codificado de manera especial. Son
estas modificaciones al Sistema Operativo lo que ha hecho que no sea muy popular.
Entre los productos comerciales que utilizan paravirtualización se encuentra: Xen.
2.6.4 Virtualización de Aplicaciones
Figura 2.16. Virtualización de aplicaciones (Virtualización de software)
A diferencia de los demás tipos de virtualización, la virtualización de software no
lidia con sistemas completos. En lugar de esto, encapsula las aplicaciones dentro de
ambientes de virtualización para su distribución y administración.
Entre los productos comerciales que utilizan virtualización de aplicaciones se
encuentran: Microsoft SoftGrid, Citrix Streaming Server, Thinstall Virtualization Suite y
Altiris Software Virtualization Solution.
2.7 Seguridad
Los ambientes de cómputo de las organizaciones continúan evolucionando a medida
que el Gobierno, la milicia, las instituciones educativas y las industrias se interconectan a
través de Internet. Pero a medida que es más fácil intercambiar información, se vuelve cada
vez más difícil protegerla. Al principio, cuando los equipos que procesaban información
eran utilizados por pequeños círculos de académicos e incluso posteriormente, cuando los
usuarios accedían mediante sus terminales “tontas” (sin memoria, disco ni procesador) a las
grandes computadoras, el centro de cómputo se ubicaba en un área física delimitada y
controlada, de tal modo que los sistemas de información eran totalmente cerrados. Pero con
el desarrollo del procesamiento distribuido el poder de cómputo se desplegó hacia el

19. interior de las organizaciones. Esto aumentó la eficiencia y la capacidad para realizar más
funciones en cada lugar de trabajo, pero también abrió una multitud de brechas de
seguridad que ahora amenazan a los activos de la información. En los días del
procesamiento centralizado y las mainframes, la seguridad de la información era
responsabilidad del oficial de seguridad de la mainframe. Ahora, la seguridad de la
información les corresponde a todos dentro de la Organización. Cada persona que trabaja
con un equipo de cómputo tiene la responsabilidad de cuidar la confidencialidad, integridad
y disponibilidad de la información a la que tiene acceso.
Con el nacimiento del modelo cliente servidor sobrevino el concepto del
procesamiento distribuido, que dio lugar a los sistemas abiertos, con los cuales se
obtuvieron ventajas como:
- Mayor eficiencia en trabajo de usuarios y uso de recursos.
- Mayor rapidez para obtener información.
- Acceso transparente a datos compartidos.
- Interfases gráficas más fáciles de usar.
- Mayor facilidad para agregar recursos (procesamiento y almacenamiento) y menor
costo.
Pero por otra parte trajeron desventajas como:
- Mayor dificultad para distribuir y configurar software.
- La necesidad de sincronizar diferentes bases de datos.
- El software y las aplicaciones no han madurado.
- Mayor costo para interconectar redes y protocolos diferentes.
Para implantar controles de seguridad a los sistemas abiertos, es necesario utilizar
una arquitectura que se aplique a cada uno de los puntos de acceso a los sistemas: la red, las
aplicaciones, las bases de datos y los sistemas operativos. La arquitectura propuesta es la
arquitectura ISA (Information Security Architecture), un mecanismo para asegurar que
todos en la Organización conocen su responsabilidad y saben cómo proceder para proteger
los recursos (Killmeyer, 2006). La administración de la seguridad de la información se
adquiere a través de esta arquitectura, la cual implica definir políticas, estándares y
procedimientos para asegurar que la información cuente con confidencialidad (Personas no
autorizadas no tienen acceso), privacidad, autenticidad, integridad (la información no sufre
alteraciones), disponibilidad (información disponible para personas autorizadas) y no
repudio (No hay forma de negar actos en contra de la información), que constituyen los
Activos de la Seguridad de Información.
Las estrategias de seguridad se deben reflejar en toda la Compañía. La seguridad
debe ser reconocida al nivel necesario para que se puedan reservar recursos que permitan
que se implante de manera efectiva. Para comprometer a la empresa en el tema de la
seguridad, el área de Tecnologías de Información (TI) lo debe incluir en su Plan
Estratégico. La Dirección Ejecutiva elabora el Plan Estratégico del Negocio, el cual refleja
los planes estratégicos de todas las áreas, incluido el Plan Estratégico de Tecnologías de
Información. El Plan Estratégico de TI contiene al menos seis secciones: Introducción,
Descripción de TI, Alcance y viabilidad, Relación a Plan Estratégico del Negocio, Metas
estratégicas de TI, Resumen y Conclusión.
El primer paso para emprender acciones es identificar las amenazas y los riesgos.
Una vez identificados, la Dirección Ejecutiva tiene que definir cómo decidirá afrontarlos.
Existen tres posibilidades para hacerlo: aceptar, mitigar o transferir. Si la Dirección decide

20. aceptar los riesgos, significa que interpreta que los riesgos no son muy altos o la
probabilidad de que ocurran es poca o el impacto es bajo, de modo que no emprenderá
ninguna acción para manejarlos. Si la Dirección Ejecutiva decide transferir los riesgos,
significa que piensa comprar aseguranza para que una compañía de Seguros se encargue de
manejarlos. Pero si decide mitigar los riesgos, es aquí donde se requiere la aplicación de
controles que eviten daños por robo, alteración de datos o suplantación de identidad en la
Intranet, destrucción, daño, retardo o negación del servicio en la red interna de parte de
usuarios autorizados intencional o accidentalmente, contaminación por virus o daños
derivados de desastres naturales, intercepción de datos o contaminación con virus a través
de Internet de parte de usuarios no autorizados o de sitios Web falsos. Estos controles
pueden ser Predictivos o Detectivos. Los controles que se pueden aplicar pueden ser
Administrativos (Políticas, procedimientos, revisión, auditoría), Físicos (personal de
seguridad, alarmas, sistemas ambientales, respaldos, sistemas ininterrumpibles de poder o
“UPS”) o Técnicos (antivirus, firmas digitales, encriptación, detección de intrusos).
La arquitectura ISA consta de los siguientes componentes (Killmeyer, 2006):
- Verificar la Infraestructura de Seguridad en la Organización
- Definir políticas, estándares y procedimientos
- Determinar los riesgos
- Entrenar a los usuarios e informarles
- Medir el cumplimiento
- Monitoreo y detección
- Respuesta a emergencias
- Recuperación de desastres
Adicionalmente, el uso de tecnologías emergentes como la virtualización, han
aumentado los riesgos contra la seguridad en los centros de cómputo. La virtualización ha
llamado la atención del mundo de las TI, pues permite consolidar en un mismo servidor
aplicaciones que normalmente se ejecutaban en múltiples sistemas de cómputo,
prometiendo con esto ayudar a administrar mejor la información y aprovechar con mayor
eficiencia los recursos de hardware.
Sin embargo, algunos administradores de TI e investigadores de seguridad
informática han advertido que esta tecnología hace los sistemas más vulnerables a ataques
de hackers (neologismo utilizado para designar a los expertos en alguna rama de la
Informática, que de forma equivocada se usa para hacer referencia al cracker o hacker
negro que tiene la intención de causar daño) y más complejos los proyectos de
cumplimiento.
La tecnología de virtualización (disponible de parte de compañías como Intel,
AMD, VMware, Microsoft e IBM) permite crear múltiples máquinas virtuales dentro de un
mismo recurso físico, donde cada máquina virtual corre un sistema operativo separado y
funciona exactamente como una computadora independiente. Según George Gerchow, -
estratega tecnológico del proveedor de seguridad Configuresoft’s Inc.- es importante que
los administradores comprendan que colapsar muchos servidores dentro de una sola caja,
no cambia sus requerimientos de seguridad, pues cada servidor virtualizado enfrenta las
mismas amenazas que un servidor tradicional. “Si un host resulta vulnerable, todas las
máquinas virtuales ‘guest’ y las aplicaciones de negocio que están en esas máquinas
también están en riesgo”. Por lo tanto un servidor que ejecuta máquinas virtuales enfrenta
mayor peligro ante una vulnerabilidad que un servidor simple.

21. La virtualización permite a los desarrolladores, grupos de aseguramiento de calidad
y otros usuarios corporativos instalar máquinas virtuales con relativamente poco esfuerzo y
sin supervisión del área de TI. Por lo tanto, si los administradores de TI no toman medidas
para llevar un buen control de las máquinas virtuales, éstas pueden aparecer, moverse o
desaparecer constantemente, con el riesgo de no poder aplicarles las mismas políticas que a
los demás servidores como actualizaciones y parches de seguridad.
Chad Lorenc, jefe de seguridad informática de una empresa de servicios financieros,
sugiere que las compañías instalen herramientas que detecten y descubran rápidamente
máquinas virtuales y que creen políticas estrictas para controlar su despliegue y la
administración del cambio, así como controles para restringir el acceso al ambiente virtual
(Vijayan, 2007).
Lloyd Hession, jefe de seguridad en BT Radianz, opina que la virtualización abre un
puñado de problemas de control de acceso a la red, pues la mayoría de las tecnologías de
control de acceso no toman en cuenta siquiera que existe este tipo de ambientes.
Expertos en seguridad también notaron que el uso extendido de herramientas de
virtualización de los mayores proveedores está abriendo a los hackers nuevas brechas de
seguridad y métodos de ataque. Microsoft por ejemplo ha liberado parches para corregir
fallas en su software de seguridad que permite a un usuario con permisos de Administrador
en solamente un sistema operativo guest, ejecutar otros sin permiso. Kris Lamb, Director
del grupo X-Force de sistemas de seguridad de Internet de IBM, afirma que el despliegue
de tecnologías de virtualización está dando a los hackers y a los investigadores de sombrero
blanco una gama de código relativamente inexplorado en el cual buscar agujeros de
seguridad y métodos de ataque. Lamb mencionó las herramientas de monitoreo de
máquinas virtuales como una plataforma potencial para lanzar ataques de hackeo. El
software de monitoreo utiliza consolas para administrar los recursos de hardware y se
posiciona justo un nivel arriba de éste, así que se puede usar para lanzar ataques
indetectables contra el sistema operativo y las aplicaciones de software que están niveles
más arriba. De hecho, algunos investigadores ya han probado cómo se pueden realizar estos
ataques. Un ejemplo es la herramienta SubVirt, que inventaron investigadores de Microsoft
y la Universidad de Michigan. Este software utiliza una “rootkit” (herramienta tipo
administrador) que instala un monitor de máquinas virtuales bajo un sistema operativo y
permite ganar el control completo de múltiples máquinas virtuales. En la conferencia de
seguridad “BlackHat” que se desarrolla en Las Vegas, se demostró un método de ataque
similar llamado “Blue Pill”, que también ganaba acceso a máquinas virtuales al estilo
“SubVirt”, permaneciendo completamente indetectable. Este ataque fue desarrollado por
Joanne Rutkowska, investigador de “malware” (software malicioso) de la firma de
seguridad Coseinc. “Ud. Tiene este gran comando y software de control [de monitoreo] que
se ha convertido en la pieza central de la infraestructura y además contiene las llaves del
reino”, dijo Lamb (Vijayan, 2007).