Tutorial de CGI

Desde la aparición de esta nueva tecnología, se ha venido discutiendo mucho sobre el tema. Sin embargo, aún surgen muchas dudas sobre los pros y contras de cada tecnología.

Desde que Microsoft lanzó al mercado su Visual Studio 97 y junto él uso de algo llamado Páginas Activas del Servidor (o ASP, por su sigla en inglés: Active Server Pages), se ha gestado toda una intriga en torno a qué es mejor si la ejecución de scripts en el servidor usando CGI o ASP.

El tema en sí resulta ser bastante más complejo. Cuando queremos utilizar tecnología de Internet para intercambiar información dentro de nuestra empresa y montar lo que se denomina una Intranet, indefectiblemente nos surge la necesidad de poder ejecutar aplicaciones a partir de información ingresada a través de páginas HTML. En definitiva debemos crear y administrar procesos que interactúen con los usuarios.

Este es el momento cuando debemos decidir cual va a ser la metodología a utilizar. Es decir, a qué tipo de programación vamos a ceñirnos. De hecho, ya ha pasado el tiempo en el que programar se limitaba a hacer un análisis simplemente enfocado a la resolución de problemas concretos que tan sólo concernían al sistema. Bajo esta nueva realidad de centralización de procesos en servidores Web y múltiples plataformas del lado del cliente, ha llevado a que se considere con más detenimiento elementos tales como: qué cantidad de hebras habrán de ejecutarse por vez y de quién es la responsabilidad de administrar las mismas.

Como en todas las cosas de la vida, el proceso de cambio y purificación de métodos para lograr una solución óptima al respecto, ha venido sufriendo un inevitable devenir que ha sido acorde a las realidades. Primeramente, recordemos que lo único que se pretendía lograr era obtener alguna forma de capturar y procesar información ingresada por el usuario a través de Forms HTML, devolviendo al cliente algún resultado.

En estas circunstancias es que surgieron los llamados scripts CGI (Common Gateway Interface). Bajo ese acrónimo, se encerraba la posibilidad de desarrollar aplicaciones que decodificaban los elementos enviados desde el cliente y procesar la información devolviendo los datos hacia la salida estándar de vuelta al cliente. De esta forma, en el servidor se define un directorio que aloja los scripts, el cual queda configurado en el servidor como el lugar desde donde se ejecutarán al ser invocados desde algún Form en HTML (<Form Method=�Post� Action=�/cgi-bin/script� > Donde SCRIPT es el nombre del ejecutable). Una vez que dicho scripts son invocados, se ejecutan en el servidor y luego vuelcan la información hacia el cliente.

Analicemos pues, como funcionan los programas CGI. Primeramente, el usuario solicita su ejecución a través del Form en HTML. Una vez ejecutado, surgen algunas contras. Primeramente, el código se ejecuta siempre fuera del servidor Web.

Esto sin dudas es una contra porque lo que se carga en memoria es el mismo proceso una y otra vez, cada vez que el programa es invocado. De esta forma, con cada proceso que se crea, nuevos recursos de memoria son asignados a él cada vez que el usuario hace click en el botón SUBMIT del Form HTML. A su vez, el mismo proceso se elimina tan pronto como se envia la respuesta por HTTP. A este procedimiento se lo denomina OUT-OF-PROC o proceso externo al servicio web.

Por otra parte, la forma en la que se comunican dos aplicaciones CGI es a través de archivos de E/S. Al comienzo, en lenguajes como Visual Basic que no poseían la capacidad de leer de la entrada estándar (stdin) o escribir hacia la salida estándar (stdout) -como es el caso de PERL o C- este proceso se llevaba a cabo a través de llamadas a una API que permitía dejar o tomar datos de los archivos INI. Evidentemente, nos referimos a un tiempo pretérito cuando no existían los COM o DCOM.

Si bien la técnica descrita fue ampliamente utilizada, de hecho también se ha transformó en una desventaja en tanto la creación de tantos archivos intermedios generaba un cuello de botella a nivel de acceso a los discos.

Finalmente, si a través de un programa CGI debemos acceder a algún motor de base de datos, el mismo también se carga con cada llamada al programa y se descarga cada vez que se cierra la aplicación. Esto también implica tiempo y recursos (Estamos de acuerdo que se podría llegar a levantar alguna base de datos independientemente y luego simplemente ejecutar consultas. El artículo plantea el análisis para el peor de los casos).

Usuarios que han visto este tema también han visto...

- Cómo detectar los principales errores en aplicaciones CGI
- Introducción a la programación CGI en Pascal
- ¿Cual es la diferencia entre GET y POST?
- Redactar páginas completas con CGI

- Versión imprimible de este documento

- Enviar por e-mail este documento