Geeks•ms
Todo lo que los geeks de Windows y .Net tienen que contar
El mayor evento de comunidad sobre Windows Azure

Breve historia del desarrollo Web

Breve historia del desarrollo Web

Creo que es importante para un desarrollador Web no sólo conocer las herramientas que tiene a su disposición, sino también el conocer el por qué de estas. Este es el objetivo de esta entrada: proporcionar una visión histórica del desarrollo Web (centrándome en IIS) hasta llegar a ASP.NET para comprender mejor las herramientas que hoy tenemos.

En primer lugar, decir que la Web no fue concebida para el desarrollo de aplicaciones. El problema que se pretendía resolver su inventor, Tim Berners-Lee, era el cómo organizar información a través de enlaces. De hecho la Web nació en el laboratorio de partículas CERN básicamente para agrupar un conjunto muy grande de información y datos del acelerador de partículas que se contraba muy dispersa y aislada.

Mediante un protocolo muy simple (HTTP), un sistema de localización de recursos (URL) y un lenguaje de marcas (HTML) se podía poner a disposición de todo científico en el mundo la información existente en el CERN de tal forma que mediante enlaces se pudiese acceder a información relacionada con la consultada.

Hoy en día la Web es algo muy distinto a lo que Tim Berners-Lee concibió.

Inicialmente se construyó un navegador Web (llamado WorldWideWeb) y un servidor Web llamado (httpd) ambos bajo NEXTSTEP (que fue comprada en 1997 por Apple y del que su sistema operativo se basó para la construcción del que hoy en día es Mac OSX).

Pronto se popularizó el servicio y se vio en la necesidad que el servidor Web pudiese devolver páginas Web dinámicas y no únicamente contenido estático residente en ficheros HTML. Para ello se desarrolló la tecnología CGI (Common Gateway Interface) donde el servidor Web invocaba un programa el cual se ejecutaba, devolvía la página Web y el servidor Web remitía este flujo de datos al navegador.

Un programa CGI podía ser cualquier programa que la máquina pudiese ejecutar: un programa en C, o en Visual Basic o en Perl. Normalmente se elegía este último por ser un lenguaje de script el cual podía ser traslado con facilidad de una arquitectura a otra. CGI era únicamente una pasarela que comunicaba el servidor Web con el ejecutable que devolvía la página Web.

De hecho el ejecutable era el encargado de devolver toda la página Web perfectamente formada. CGI proporcionaba un buffer de escritura a la aplicación donde esta debería devolver toda la salida que quería devolver. El servidor Web recibía ese buffer a la terminación del programa y devolvía el buffer escrito de forma íntegra al navegador.

En http://support.microsoft.com/kb/239588 podréis encontrar un ejemplo en VB de cómo escribir una aplicación CGI.

CGI era una solución cómoda de realizar páginas Web dinámicas pero tenía un grave problema de rendimiento que lo hizo insostenible en cuanto la demanda de la Web comenzó a disparar las peticiones de los servidores Web.

Al invocar el navegador un programa externo, el sistema operativo tiene que crear todo el contexto de la aplicación. Es decir, el sistema operativo reserva 4 GB de memoria (virtual, claro), reserva los 2 primeros GB al sistema operativo, los 2 restantes a la aplicación, inicia la memoria para la aplicación, crea la pila de llamadas de la aplicación, la invoca, se ejecuta nuestro CGI y devuelve los parámetros. Y a continuación el sistema operativo tiene que destruir todo el contexto de aplicación creado y liberar recursos... para a continuación volver a empezar de nuevo en el momento en que alguien volviese a solicitar esa página dinámica.

Es decir, un servidor Web estaba más ocupado creando/destruyendo contextos de aplicaciones que ejecutando esas mismas aplicaciones.

Para agilizar esto, los principales servidores Web del momento (Netscape e IIS) desarrollaron un sistema para la ejecución dinámica de aplicaciones usando el propio contexto del servidor Web. En el caso de Netscape se le denominó NSAPI (Netscape Server Application Program Interface) y en el caso de IIS se le llamó ISAPI.

En estos casos, la aplicación Web no era un ejecutable independiente, sino un plug-in. En caso de Windows se trataba de una DLL que era invocada en el propio contexto del servidor Web.

Es decir, cuando se arrancaba el servidor Web, se cargaban las DDLs ISAPI registradas en el servidor Web y cuando se pedía una página Web dinámica, se ejecutaba la DLL correspondiente. En este caso no había creación de contexto pues esa DLL estaba cargada ya en el contexto del propio servidor Web.

La ejecución con la tecnología xSAPI permitía un aumento de rendimiento espectacular en las aplicaciones Web pero tenía un problema de estabilidad.

En el caso de las aplicaciones CGI, si tu ejecutable tenía problemas (uso de un puntero inválidos, uso de un puntero null, ...) el sistema operativo invalidaba todo el contexto de aplicación y liberaba recursos. El servidor Web quedaba esperando una respuesta de un programa que había sido matado por el sistema operativo pero esto quedaba resuelto dando un tiempo de respuesta: en el caso que se superase este tiempo de espera, el servidor Web descartaba obtener respuesta de ese proceso y se enviaba un error 500 al navegador).

En cambio con ISAPI, si teníamos el mismo problema era el sistema operativo el que liberaba el contexto de aplicación entero al encontrarse un puntero inválido o el uso de un puntero nulo. Pero recordemos que la DLL se estaba ejecutando en el contexto del servidor Web, así que lo que el sistema operativo liberaba era el servidor Web entero.

Es decir, un error de programación con CGI hacía que se devolviese un error 500 pero el resto del servidor seguía sirviendo páginas y peticiones con normalidad. Pero en el caso de ISAPI un error de programación directamente tiraba el servidor Web.

¿Qué hacer ante eso? La solución sería crear un lenguaje de script donde no hubiesen punteros ni nada que pudiese tirar el servidor Web y crear un módulo ISAPI que interpretase ese lenguaje. Este es el caso de ASP.

Con ASP tenemos un lenguaje de script sin punteros ni nada peligroso de tal forma que un error de programación sea algo inofensivo. Y para interpretarlo tenemos una DLL ISAPI llamada ASP.DLL que es la que interpreta ese script.

El único fallo posible sería un error en la DLL ISAPI, pero aquí tenemos las espaldas cubiertas puesto que para la creación de esta DLL hay un equipo muy grande detrás que ha tenido sumo cuidado en evitar esto.

Básicamente, hoy en día hay 4 grandes lenguajes de programación Web que se basa en este sistema. Por un lado está Microsoft con ASP basado en Visual Basic Script. Por otro tenemos a SUN con su versión en Java llamada JSP (bueno, en Java también existe una tecnología llamada Servlet que equivale a escribir un CGI en Java donde trabajas la petición Web a un nivel más bajo que con JSP), también está PHP basado en una sintaxis de C y por último está ColdFusion de Adobe.

Así pues si queremos ejecutar páginas ASP o páginas JSP o páginas PHP en IIS lo único que hay que registrar la correspondiente DLL ISAPI proporcionada por el fabricante y decirle a IIS que ante una petición de una página terminada en .asp o en .jsp o en .php, invoque ese ISAPI y espere respuesta.

Puede que te estés pregntando ¿y donde queda ASP.NET en todo esto? Pues para ello tenemos aspnet_isapi.dll.

Comentarios Recientes

No se ha escrito ningún comentario para esta página.
Sigue a Plain Concepts en Facebook