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