Programación Cliente-Servidor
Posted by Danny in Cliente Servidor
Internet puede resultar algo misterioso al principio, sobre todo porque se utiliza un vocabulario propio, que hasta que no se domina, uno anda un poco despistado. Pero, en esencia, Internet es un sistema Cliente-Servidor gigante. La idea primaria de un sistema cliente-servidor es que debe haber un sitio donde se centraliza la información, que se desea distribuir bajo demanda a un conjunto de personas o máquinas.
La clave de este concepto radica en que si se produce un cambio en la información del sistema central, inmediatamente es propagada a los receptores de la información, a la parte cliente. Luego, el concepto básico es muy simple; el problema se presenta cuando hay solamente un servidor que tiene colgados a muchos clientes, en que el rendimiento general del sistema decrece de forma exponencial al aumento del número de clientes.
El funcionamiento de la Web sigue este mismo principio. Inicialmente, se solicita una información a un servidor y éste envía de vuelta un fichero que será interpretado por el navegador (el cliente) que lo formateará para visualizarlo en la máquina cliente. El navegador fue el primer paso adelante en la expansión de Internet, ya que permitía visualizar un mismo fichero en plataformas diferentes sin hacerle cambio alguno; pero su finalidad principal es la visualización de ficheros, no la interactividad con el usuario, ni la posibilidad de ejecutar programas en la parte del usuario, en la parte cliente del sistema.
Para proporcionar un poco de interactividad, se dotó al lenguaje HTML de ciertos mecanismos básicos de entrada de datos, como botones, cajas de selección, campos de texto, y algunos otros; pero la carga que incorporaban al sistema caía del todo dentro del lado del servidor, con lo cual, si había muchos clientes colgando, el colapso del servidor era casi seguro. Así que surgieron algunas alternativas a los CGI, para que se pudiese descargar al servidor de tanto trabajo y que el cliente realizase también operaciones.
Esto son piezas de código que se incorporan al navegador y le indican que "a partir de ahora dispones de una nueva característica". Hay carasterísticas que se añaden a los navegadores a través de plug-ins que son muy rápidas y eficientes, pero el problema es que escribir un plug-in no es una tarea trivial ni tampoco es algo que haya que hacer en el proceso de construcción de un Site. Luego los pulg-ins son herramientas válidas para programadores muy expertos que permiten incorporar características nuevas al navegador sin necesidad de que el vendedor conceda su permiso.
Un lenguaje script permite embeber código fuente para la programación del lado cliente, directamente en la página HTML, y el plug-in que interpreta ese lenguaje se activará automáticamente cuando se cargue en el navegador. Estos lenguajes tienden a ser muy simples y sencillos, además se cargan muy rápidamente porque van incluidos en la página que envía el servidor. La pega es que el código del programador está expuesto a la vista de cualquiera, aunque tampoco se pueden hacer demasiadas filigranas con un lenguaje script.
Estos lenguajes se utilizan fundamentalmente para hacer más atractivos los interfaces gráficos de las páginas, porque disponen de elementos gráficos y pueden llegar a resolver el 80% de los problemas que se plantean en la programación de la parte cliente del sistema cliente-servidor; y, además, son lenguajes mucho más sencillos de aprender e implementar soluciones con ellos que recurrir a Java o ActiveX. Siempre que los problemas del caigan dentro de ese 80% que son capaces de resolver los lenguajes script, y el programador se encuentre cómodo con este tipo de lenguajes, serían la elección prioritaria, antes de adentrarse en las profundidades que representa siempre el estudio de un nuevo lenguaje de programación.
El lenguaje script más utilizado es JavaScript, que no tiene nada que ver con Java, me imagino que se llamará así para aprovechar el tirón de popularidad de Java, pero también se pueden realizar scripts en la parte cliente con Visual Basic o con Tcl/Tk.
¿Y qué pasa con el 20% de los problemas que no pueden resolver los lenguajes script? La respuesta más común, si se hiciese una encuesta, sería Java, y no solamente porque sea un poderoso lenguaje de programación enfocado a la seguridad, multi-plataforma e internacional, sino porque Java está siendo continuamente extendido para proporcionarle nuevas características y librerías que resuelven elegantemente problemas que son muy difíciles en la programación tradicional como el acceso a bases de datos, el uso de multihilo, la programación de redes y la programación distribuida, y además porque Java, a través de los applets, permite la programación de la parte cliente.
Un applet es un miniprograma que corre solamente bajo un navegador y es descargado automáticamente como parte de una página Web, al igual que cualquier gráfico, y cuando se activa, ejecuta un programa. Este es el interés, proporciona una forma a través de la cual se puede distribuir software al cliente desde el servidor, en el momento en que el cliente necesite ese software, y no antes, con lo cual siempre tendrá el cliente la última versión de ese software, se actualice cuando se actualice. Además, tal como está diseñado Java, el programador necesita crear su programa una sola vez, y ya estará listo para ser ejecutado en todas las plataformas que dispongan de un navegador con soporte Java.
Con Java se podrá realizar tanto trabajo como sea posible en el cliente antes y después de hacer peticiones al servidor. Por ejemplo, se puede evitar el enviar una petición a través de Internet mientras el usuario no haya introducido los parámetros correctos de esa petición, que estará chequeando el cliente, sin necesidad de tener que consultar continuamente al servidor; con ello se gana en velocidad de respuesta ante el usuario, una reducción general en el tráfico de red y una gran descarga de trabajo para el servidor.
Una de las ventajas de los applets sobre los scripts es que están en forma compilada, con lo cual el código fuente no es visible; aunque se puede descompilar sin demasiadas complicaciones, pero vamos, no está del todo accesible. Además, un applet puede comprimir varios módulos, utilizando ficheros JAR, evitando múltiples conexiones con el servidor, ya que en una sola se descargan todos los componentes necesarios.
Y, finalmente, está la curva de aprendizaje, porque a pesar de lo que el lector haya podido escuchar o leer por ahí, Java no es un lenguaje trivial. Si el lector domina Visual Basic, por ejemplo, el que realice sus trabajos en VBscript le resultará más fácil y rápido y resolverá sus problemas de programación cliente-servidor sin embarcarse en la dura empresa de aprender Java.
La competencia directa de Java es ActiveX, de Microsoft, aunque su enfoque sea bastante diferente. ActiveX es originalmente una solución orientada a entornos Windows, aunque parece ser que ahora está siendo desarrollado para ser multiplataforma. Lo que hace ActiveX es decir "si tu programa se conecta a este entorno, se podrá descargar en una página Web y correr bajo un navegador que soporte controles ActiveX". Microsoft Internet Explorer soporta ActiveX directamente y Netscape lo soporta a través de plug-in. Por lo tanto, ActiveX no está constreñido a un solo lenguaje de programación, sino que se pueden desarrollar componentes ActiveX en el lenguaje que domine el programador, ya sea C++, Visual Basic o el Delphi de Borland.
Microsoft ha subido una vez más la apuesta en su batalla contra Java con el lanzamiento de los scriplets, que son similares en naturaleza a los componentes JavaBeans, y aparecen como una campaña de vaporware por parte de Microsoft. Su aparente meta es posicionar esta tecnología como un potencial rival multiplatafroma de Java, que, según dice Microsoft, no cumple su compromiso de ser tan manejable como propugna su publicidad. Los scriptlets, a diferencia de Java, sólo se pueden utilizar sobre un navegador Web. Si bien es cierto que a los applets les ocurre lo mismo, Java deja abierta la posibilidad de crear aplicaciones, dependientes de una máquina virtual Java, pero no de un navegador; y en cuanto la máquina virtual Java se encuentra incluida en el propio sistema operativo, el usuario no advierte dependencia alguna. La verdad es que los scriptlets no aportan nada nuevo a las posibilidades de las herramientas actuales, sino que son otra forma de hacer lo mismo.
La descarga y ejecución automática de programas a través de Internet, en principio, suena como el sueño de cualquier creador de virus. Los componentes ActiveX son especialmente sensibles a este ataque, ya que se puede hacer lo que se quiera, sin control alguno, con lo cual, el usuario puede bajarse un componente ActiveX que haga estragos en su máquina. Esto no es nuevo, sino que es un problema largamente conocido desde los tiempos de las BBS, pero que aquí se ve amplificado por la velocidad de Internet.
Cuando se pide una página Web, se reciben ficheros gráficos, el código de la página (con o sin scripts), código Java precompilado y componentes ActiveX. De estos, algunos son casi inofensivos, como los ficheros gráficos y el código HTML de la página, porque es muy poco lo que se puede manipular sobre ellos. Java está diseñado para ejecutar los applets en una caja cerrada (sand box), envuelta en una capa de seguridad que impide cualquier acceso a disco o a memoria que se encuentre fuera de esa caja cerrada. Así que, la parte más propensa a introducir elementos no deseados en la máquina cliente son los componentes ActiveX.
Actualmente se está intentando paliar esta desagradable posibilidad a través de las firmas digitales, que permiten reconocer al autor. Esta idea parte de que los autores de virus normalmente son anónimos, y si se eliminan estos componentes anónimos, siempre se podrá forzar al programador a que sea responsable de sus acciones. Puede se una buena idea, porque permitirá a los programas ser más funcionales, aunque si un programa tiene un bug inadvertido que pueda resultar destructivo, todavía podrá causar problemas.
Con respecto a Java, hay diversas opiniones respecto a la draconiana restricción a que un applet no pueda escribir en el disco local del cliente; porque, que pasa si el usuario quiere crear una base de datos local, o quiere guardar cualquier tipo de información para cuando se encuentre desconectado de Internet. La asunción inicial de que todo el mundo estaría conectado es impracticable, aunque si se redujesen los precios del teléfono, pudiese llegar a ser el estado normal de muchos usuarios; así que la solución debe llegar por otra vía. Los applets firmados, que utilizan una clave pública para comprobar que el applet viene del lugar correcto y no ha sido manipulado puede ser una de esas soluciones. Desde Java 1.1 se dispone de un entorno para implementar firmas digitales, por lo que si fuese necesario se podría hacer que un applet se saliese de su caja cerrada.
