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).

Por otra parte, analicemos cuales son las ventajas de los CGI, si es que las hay. Primeramente, no hay que perder de vista que los scripts CGI fueron creados con el único objetivo inicial de resolver una tarea de recolección de información por parte del servidor. En su tarea batch, el CGI podría decirse que es útil. Si hablamos de un sitio parcialmente estático o que no centre toda su aplicación de una forma absolutamente interactiva, podríamos aún considerarlo como una alternativa viable.

A su vez, si de hecho los scripts se programan en lenguajes potentes y rápidos como C, C++ o Perl, esto hace que las apliaciones no consuman tantos recursos. Además, los scripts CGI son cien por cien portables. Es decir que como se ejecutan sobre cualquier servidor y sólo reciben código HTML (ya sea por el método POST o GET) y eventualmente devuelve código también en HTML, esto los hace absolutamente independientes del tipo de servidor que se desee utilizar. Por último, los CGI son una tecnología muy probada y su popularidad surgió a partir del surgimiento de lenguajes como PERL, que permitió la creación rápida de aplicaciones basadas en dicho paradigma.

Ahora veamos que nos ofrecen las Páginas Activas del Servidor o ASP. Esta tecnología surgió con Microsoft como dijimos al comienzo y por tanto, su principal desventaja (amén de todas las ventajas que se describirán a continuación), es que dependen de un sistema operativo. Esto quiere decir que fueron creadas para funcionar sobre servidores Windows NT con IIS (Internet Information Server ).

Antes de analizar las ventajas, entendamos bien el concepto que hay detrás de las Páginas de Servidor Activas. ASP es en sí una tecnología que se utiliza para la realización de scripts. A través de la misma, se pueden crear aplicaciones web dinámicas e interactivas.

Una página ASP es en esencia una página HTML que contiene código que será ejecutado del lado del servidor y procesado por el Web Server antes de que el cliente reciba la información. Es decir que el cliente lo que recibe es código HTML puro. Esa programación se puede combinar a su vez con XML, COM y HTML.

De esta forma, cada vez que el cliente solicita una archivo .asp del servidor, se ejecuta primero el código dentro de dicha página y luego se envía el resultado formateado de dicha página al cliente. Así pues, dentro de ese código tanto se pueden utilizar elementos de XML como se pueden hacer llamadas a componentes COM para acceder a otro tipo de información.

¿Cuáles son las ventajas del uso de las Páginas Activas del Servidor?. Pues bien, la primera y más importante es que el cliente no tiene acceso nunca al código que se ejecuta. Los scripts CGI clásicos han sido el principal objetivo de los hackers por su alta vulnerabilidad, ya que a través de los Forms se envía información que llega al servidor como flujo de STDIN. Este conocimiento conjugado con astucia y tenacidad, conforman la puerta número uno de entrada a los sistemas.

Por otra parte, otra ventaja importante yace en el hecho de que las páginas se ejecutan dentro del propio servidor Web (IIS) en lo que se denomina IN-PROC. Es decir, no salen a tomar recursos de memoria fuera del servidor web, como lo hacen los CGI; lo cual permite un mejor aprovechamiento del sistema de hebras con el que cuenta Windows NT. Además, si a esto le sumamos una óptima reutilización de objetos por parte del propio administrador del IIS, obtenemos un entorno bastante más optimizado en lo que concierne a utilización de recursos.

Finalmente, las Páginas Activas permiten a su vez el acceso a bases de datos a través de objetos que administran esas llamadas. Por tanto, tampoco se desperdician recursos a ese nivel. El concepto en sí convengamos que es intersante. En lo que respecta a su utilización y/o difusión, está evidentemente en crecimiento.

Es una tecnología relativamente nueva y la razón por la cual quizá en estos tiempos de cambios aún no ha permitido que popularice en su totalidad, radica en su baja portabilidad y en la existencias de demasiados sitios ya establecidos con scripts CGIs aún funcionales. Su aceptación como estándar ya es un hecho. Su uso generalizado, una muy posible realidad.