Evoluacion de las aplicaciones web

1.1 EVOLUCIÓN DE LAS APLICACIONES WEB

Con la introducción de Internet y del Web en concreto, se han abierto infinidad de posibilidades en cuanto al acceso a la información desde casi cualquier sitio. Esto representa un desafío a los desarrolladores de aplicaciones, ya que los avances en tecnología demandan cada vez aplicaciones más rápidas, ligeras y robustas que permitan utilizar el Web.

Afortunadamente, tenemos herramientas potentes para realizar esto, ya que han surgido nuevas tecnologías que permiten que el acceso a una base de datos desde el Web, por ejemplo, sea un mero trámite. El único problema es decidir entre el conjunto de posibilidades la correcta para cada situación.

1.1.1 Web 1.0

ejemplo de web 1.0

La 'Web 1.0 (1991-2003) es la forma más básica que existe, con navegadores de sólo texto bastante rápidos. Después surgió el HTML que hizo las páginas web más agradables a la vista, así como los primeros navegadores visuales tales como IE, Netscape, explorer (en versiones antiguas), etc.

La Web 1.0 es de sólo lectura. El usuario no puede interactuar con el contenido de la página (nada de comentarios, respuestas, citas, etc), estando totalmente limitado a lo que el Webmaster sube a ésta.

Web 1.0 se refiere a un estado de la World Wide Web, y cualquier página web diseñada con un estilo anterior del fenómeno de la Web 2.0. Es en general un término que ha sido creado para describir la Web antes del impacto de la fiebre punto com en el 2001, que es visto por muchos como el momento en que el internet dio un giro.

Es la forma más fácil en el sentido del término Web 1.0 cuando es usada en relación a término Web 2.0, para comparar los dos y mostrar ejemplos de cada uno.

CARACTERÍSTICAS

Diseño de elementos en la Web 1.0 Algunos elementos de diseño típicos de un sitio Web 1.0 incluyen:

• Páginas estáticas en vez de dinámicas por el usuario que la visita

• El uso de framesets o Marcos.

• Extensiones propias del HTML como el parpadeo y las marquesinas, etiquetas introducidas durante la guerra de navegadores web.

• Libros de visitas online o guestbooks

• Botones GIF, casi siempre a una resolución típica de 88x31 pixel en tamaño promocionando navegadores web u otros productos.

• formularios HTML enviados vía email. Un usuario llenaba un formulario y después de hacer clic se enviaba a través de un cliente de correo electrónico, con el problema que en el código se podía observar los detalles del envío del correo electrónico.

• No se podían adherir comentarios ni nada parecido

1.1.2 Web 2.0

El término Web 2.0 está asociado a aplicaciones web que facilitan el compartir información, la interoperabilidad, el diseño centrado en el usuario y la colaboración en la World Wide Web. Un sitio Web 2.0 permite a los usuarios interactuar y colaborar entre sí como creadores de contenido generado por usuarios en una comunidad virtual, a diferencia de sitios web donde los usuarios se limitan a la observación pasiva de los contenidos que se ha creado para ellos. Ejemplos de la Web 2.0 son las comunidades web, los servicios web, las aplicaciones web, los servicios de red social, los servicios de alojamientos de videos, las wikis, blogs y mashups.

SERVICIOS ASOCIADOS

Para compartir en la Web 2.0 se utilizan una serie de herramientas, entre las que se pueden destacar:

• Blogs: Un blog es un espacio web personal en el que su autor (puede haber varios autores autorizados) puede escribir cronológicamente artículos, noticias...(con imágenes y enlaces), pero además es un espacio colaborativo donde los lectores también pueden escribir sus comentarios a cada uno de los artículos (entradas/post) que ha realizado el autor. La blogosfera es el conjunto de blogs que hay en internet.

• Wikis: En hawaiano "wiki" significa: rápido, informal. Una wiki es un espacio web corporativo, organizado mediante una estructura hipertextual de páginas (referenciadas en un menú lateral), donde varias personas elaboran contenidos de manera asíncrona. Basta pulsar el botón "editar" para acceder a los contenidos y modificarlos. Suelen mantener un archivo histórico de las versiones anteriores y facilitan la realización de copias de seguridad de los contenidos. Hay diversos servidores de wiki gratuitos.

• Entornos para compartir recursos: Todos estos entornos nos permiten almacenar recursos en Internet, compartirlos y visualizarlos cuando nos convenga desde Internet. Constituyen una inmensa fuente de recursos y lugares donde publicar materiales para su difusión mundial.

• Documentos: podemos subir nuestros documentos y compartirlos, embebiéndolos en un Blog o Wiki, enviándolos por correo.

• Videos: Al igual que los Documentos, anteriormente mencionados, se pueden "embeber" un video tomado de algún repositorio que lo permita, tal como YouTube.

• Presentaciones

• Fotos

• Plataformas educativas

• Aulas virtuales (síncronas)

Redes Sociales

1.1.3 Web 3.0

Bases de Datos

Inteligencia Artificial

Web Semántica

3D

•

• Bases de Datos

•  Surgimiento de la “Data Web” con la tecnología SPARQL.

•  SPARQL: Protoclo RDF Query Lenguage

•

• Inteligencia Artificial

•  Programas más avanzados e Inteligencia Humana:

•  Extraen el Sentido

•  Ordenan la Red.

•  Establecen un patrón de conducta de interacción

•

• Web Semántica

•  Extensión del Sistema SPARQL e Inteligencia Artificial.

•  Programas con el poder de razonar.

•  Basado en descripciones lógicas, interconectar conceptos y datos en la red.

• Web 3D

•  Concepto de Espacios Tridimensionales.

•  Creación de Avatars.

HITORIA DE LA PROGRAMAMCION 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.

...