Resumen

Todas las páginas de una intranet tienen una dirección URL única que la identifica. Los exploradores de Web solicitan una página mediante el envío de una dirección URL a un servidor Web. El servidor utiliza la información de la dirección URL para encontrar y mostrar la página.

La sintaxis de las direcciones URL es una secuencia específica de protocolo, y ruta de acceso a la información solicitada. El protocolo es el método de comunicación utilizado para tener acceso a la información; por ejemplo, el Protocolo de transporte de hipertexto (HTTP), FTP y gopher. El nombre de dominio del Host está dentro del Sistema de Nombres de Dominio (DNS) del equipo que contiene la información. La ruta de acceso es el camino a la información solicitada dentro del equipo.

Una dirección URL también puede contener información que el servidor Web debe procesar antes de devolver una página. Los datos se agregan al final de la ruta de acceso. El servidor Web pasa los datos a un programa o a un archivo de comandos para su procesamiento y devuelve los resultados en forma de una página Web.

Un servidor Web responde a la petición de un explorador de Web devolviendo una página HTML. La página devuelta puede ser de tres tipos: una página HTML estática, una página HTML dinámica o una página de lista de directorio.

Paginas Estáticas 

Las páginas estáticas son páginas HTML fijas ya preparadas antes de la petición. El servidor Web devuelve las páginas HTML al usuario, pero no realiza ninguna acción especial. El usuario pide una página estática escribiendo una dirección URL (en la siguiente figura) o haciendo clic en un vínculo que apunte a una dirección URL. La petición de dirección URL se envía al servidor y éste responde devolviendo la página HTML estática.

Paginas Dinámicas

Las páginas dinámicas se crean como respuesta a las peticiones de los usuarios. Un explorador de Web recopila información presentando una página con cuadros de texto, menús y casillas de verificación que el usuario completa o activa. Cuando el usuario hace clic en un botón de un formulario, los datos procedentes del formulario se envían al servidor Web. El servidor pasa los datos a un archivo de comandos o una aplicación para su procesamiento, o bien consulta o envía datos a una base de datos. Entonces, el servidor devuelve los resultados al usuario en forma de una página HTML.

 La siguiente figura muestra cómo un usuario puede enviar una consulta a una aplicación de API de Internet Server (ISAPI) que suma dos números. El usuario escribe los dos números que se van a sumar y después hace clic en un botón, lo que hace que los dos números se envíen al servidor Web. El servidor Web llama a la aplicación ISAPI para sumar los números y devuelve el resultado al usuario en forma de una página HTML.

Interfaz de Programa de Aplicación para Servidores Internet “ISAPI”

La Interfaz de programación de aplicaciones para servidores de Internet (ISAPI) es una Interfaz de Programación de Aplicaciones (API) de extensión del servidor de gran rendimiento compatible con Microsoft Internet Information Server(IIS) y Servicios Web punto a punto. ISAPI permite que haya respuestas dinámicas a las peticiones del Protocolo de transporte de hipertexto (http por sus siglas en Ingles), en lugar de simplemente devolver archivos HTML estáticos.

Esta interfaz fue originalmente desarrollada por PROCESS SOFTWARE, y adoptada por Microsoft en 1997 como su API server estándar por ser una alternativa más rápida que la Interfaz de puerto de enlace CGI (El Common Gateway Interface), y a está incluida en el Servidor Microsoft Internet Information (IIS).

Los programas escritos usando la interfaz ISAPI son compilados como bibliotecas de enlace dinámico (DLL - Dynamic Link Library), ya que son cargados por el servidor Web cuando éste se inicia. Dichos programas se vuelven residentes en memoria, por lo que se ejecutan mucho más rápido que las aplicaciones CGI, debido a que requieren menos tiempo de uso de CPU al no iniciar procesos separados.

La interacción entre el servidor y una determinada DLL de la aplicación ISAPI se realiza mediante una extensión control block (ECB), en lugar de hacerlo, como en el caso de CGI mediante variables de entorno y las stdin/stdout.

Las DLLs de aplicaciones ISAPI deben ser construidas con capacidad multitarea (MULTITHREAD) dado que podrán recibir múltiples peticiones de ejecución.

Escribiendo un filtro de ISAPI

Un filtro ISAPI es una biblioteca reemplazable de enlace dinámico a la que el servidor llama a cada petición http. Cuando el filtro es cargado le dice al servidor en que tipo de Notificaciones esta interesado. Luego en el momento que ocurra el evento seleccionado, El filtro es llamado y permite procesar dicho evento. Estos filtros son suficientemente poderosos como para permitir la compresión de datos, Análisis de trafico u otros análisis requeridos, Encriptación de datos, Esquemas de autenticación de clientes entre otras de sus aplicaciones.

Múltiples filtros pueden ser instalados. Las ordenes de notificación se basan en la prioridad especificada por el filtro y es entonces que la orden se carga en el registro para cualquier lazo. Es de notar que una vez que el filtro ha expresado interes en una petición, recibirá la data sin importar que sea de un archivo, una aplicación CGI o una aplicación ISAPI.

Fortalezas de ISAPI

· Mayor Rapidez: El conjunto de interfaces que componen ISAPI fueron diseñadas para proveer a los desarrolladores de aplicaciones de una manera poderosa de extender la funcionalidad de los IIS. La principal ventaja sobre otras tecnologías de aplicación disponibles es que usa llamadas a funciones DLL(DYNAMIC-LINK LIBRARY) para comunicarse con extensiones, en lugar de variables de ambiente y E/S estándar. Hay mucha sobrecarga(OVERHEAD) cuando se inicia un nuevo proceso en plataformas WIN32, y las llamadas a librerías DLL eliminan la necesidad de nuevos procesos, reduciendo así el tiempo de ejecución.

· El más alto rendimiento: Las extensiones apropiadamente planeadas y desarrolladas por ISAPI pueden activar cualquier otra tecnología de aplicación en la Web disponibles actualmente para IIS.

· Bajo Nivel de Control: Desde una extensión ISAPI o un filtro, se puede tener acceso al arreglo completo de funciones API de Win32. Por lo tanto se puede crear un conjunto de tareas que trabajen para la extensión ISAPI con el fin de agilizar el procesamiento usando las funciones de tareas de Win32 para acceder a la funcionalidad de las tareas nativas del windows 2000.

Muchas veces , las extensiones y los filtros ISAPI están mejor posicionados para resolver los cuellos de botella críticos en su aplicación, especialmente si se espera la escalabilidad como algo importante para su aplicación, debido a los altos volúmenes de trafico. Por lo que si al usuario le gusta crear su propia aplicación Web de búsqueda sobre las IIS, ISAPI será la mejor opción si el rendimiento rápido es una meta importante.

Debilidades de ISAPI

En muchos casos, ISAPI le puede proveer con las mejores soluciones de Rendimiento posibles existen algunas debilidades a tener en cuenta:

· El desarrollo requiere más tiempo: Debido a que las extensiones y los filtros ISAPI son escritas usualmente en C o C++, el tiempo de desarrollo es más largo que por decir un ejemplo una pagina ASP.

· Las ganancias de Escalabilidad no son necesariamente automáticas: Como sea las extensiones y los filtros ISAPI generalmente correrán más rápido que sus contrapartes de componentes ASP, no hay garantía de escalabilidad perfecta.

· ISAPI opera bajo la total ayuda de la infraestructura IIS: Ciertamente la total ayuda en la programación de abstracciones , mas notablemente la sesión de abstracción, se encuentran ausentes en la programación ISAPI el cual es de menor nivel que el scripting. Además las interacciones con objetos COM deben ser también manejadas cuidadosamente –Mas cuidadosamente que si se estuviera creando una aplicación de Web fuera de los componentes del servidor y los ASP scripts.

Es de notar que si estas debilidades hacen mayor peso en la balanza que los beneficios de escoger a ISAPI para una aplicación de componentes Web, entonces quizás el scripting y los componentes de servidor COM serán mas apropiados para el usuario.

Última Actualización: 03JUL02

[Principal] [Papers] [Infografia]