Nueve preguntas sobre tecnología cliente/servidor
Para muchas compañías, adoptar la tecnología cliente/servidor ya no es una posibilidad a considerar, es un hecho real. Sin embargo, puede suceder que los directores de informática que han basado sus carreras en redes heredadas de mainframes o miniordenadores basados en terminales comprendan la necesidad de pasar a entornos cliente/servidor, pero no sepan cómo llegar allí. Por ello, y como introducción tecnológica a la problemática cliente/servidor, incluimos a continuación las respuestas a las nueve preguntas más habituales sobre esta tecnología
1. ¿Cómo se define el proceso cliente/servidor?
Aunque en una discusión sobre proceso cliente/servidor lo primero que viene a la mente son los interfaces gráficos de usuario, el lenguaje SQL y el downsizing, estas cuestiones son sólo la parte superficial de lo que puede hacerse. La tecnología cliente/servidor no está limitada a ninguna clase específica de aplicación, sino que permite a los usuarios finales acceder a programas y datos en cualquier parte que existan en una empresa, bien en mainframes, en plataformas de gama media o en servidores de red de área local.
El proceso cliente/servidor es también un nuevo modelo comercial para la nueva generación de funciones de sistemas de información corporativos. En este modelo, los usuarios finales son clientes y los consumidores, presentadores y manipuladores de información. El personal informático proporciona servidores, que ofrecen acceso a los datos, protege la información y garantiza que están disponibles a todas las personas autorizadas para utilizarlos a demanda.
2. ¿Requiere el proceso cliente/servidor que el usuario realice el downsizing de las aplicaciones?
No. En cierto modo resulta irónico que el proceso cliente/servidor sea considerado con frecuencia como la tecnología de downsizing, cuando en realidad podría ser utilizado igualmente para extender la vida útil de la tecnología mainframe existente. El proceso cliente/servidor es en realidad la tecnología del rightsizing.Por ejemplo, la firma Computer Associates ha desarrollado un proceso servidor que funciona en mainframes y ofrece a los clientes PC el acceso a su sistema de bases de datos IMS. Utilizando una aplicación de base Windows llamada QbyX, o query by example, los usuarios pueden manipular información IMS como si los datos estuvieran almacenados en alguna parte de la LAN. La tecnología de CA convirtió al mainframe en un servidor al que los usuarios pueden acceder directamente. Aunque aplicaciones como la QbyX de CA son aún raras, las herramientas para crear puentes cliente/servidor a y desde mainframes se están haciendo cada vez más abundantes. Lo cierto es que, para poder ajustarse a la nueva realidad distribuida del proceso de datos corporativo, muchos otros vendedores de software para mainframes están añadiendo ahora conexiones cliente/servidor a sus antiguos sistemas, con el fin de que estos resulten más fáciles para los usuarios finales y las redes.
3. ¿Dónde deberán los usuarios comenzar a implementar aplicaciones cliente/servidor?
Quizá para acceder a los mainframes existentes, o para un downsizing de las aplicaciones a plataformas más económicas. Esta tecnología puede utilizarse también para introducir en las redes capacidades completamente nuevas, como el proceso de imágenes, datos en tiempo real e interfaces gráficos de usuario (GUIs), sin desechar los sistemas existentes. En lugar de ser agente de un cambio revolucionario, la tecnología cliente/servidor puede ofrecer el elemento evolutivo que parece faltar en la era actual.
4. ¿Qué aplicaciones deberán migrar primero los usuarios al proceso cliente/servidor?
En realidad no hay una respuesta correcta a la cuestión, pero pueden aplicarse algunas reglas prácticas de tipo general. Por ejemplo, crear nuevas aplicaciones es con frecuencia menos traumático que reescribir aplicaciones ya existentes. De forma similar, implementar las que se conocen como aplicaciones de prueba-de-concepto (que utilizan tecnología cliente/servidor para enlazar diferentes plataformas de proceso, por ejemplo) es una acción muy corriente y que puede reducir los riesgos.
Aparte de las nuevas aplicaciones, hay argumentos sólidos que hacen que varios tipos de aplicaciones existentes estén maduras para el paso a los entornos cliente/servidor. Los programas de aplicación que, a lo largo de años de modificación, resultan ya imposibles de soportar y son improductivos, o funcionan en plataformas anticuadas que son injustificables, caras o arriesgadas de mantener, son ideales para un paso al proceso cliente/servidor.
Además, las aplicaciones dBase y Paradox -creadas ad hoc por usuarios finales no experimentados- que se han convertido de facto en sistemas críticos para la empresa, grupos de aplicaciones que son demasiado difíciles o complicadas para mantener una base de usuarios en expansión y nuevas aplicaciones en soporte de funciones comerciales, que requieren el uso de nuevas tecnologías como el tratamiento de imágenes y el intercambio electrónico de datos, son candidatas a ser incluidas en entornos cliente/servidor. Incluso compañías con una gran base instalada de aplicaciones 3270 o de terminales de caracteres harían bien en considerar la utilización de pantallas en aplicaciones front-end, obteniendo información de pantallas mainframe existentes y visualizándola en aplicaciones de ordenador personal. Este uso de las pantallas es un paso intermedio hacia verdaderas aplicaciones cliente/servidor y, si se realiza con cierto grado de planificación previa, puede evitar a los usuarios tener que saber que se han producido cambios fundamentales.No obstante, también existen formas estratégicas -algunos dirían que premeditadas- para enfocar la selección de aplicaciones para una posible migración al proceso cliente/servidor. Por ejemplo, los usuarios pueden seleccionar aplicaciones con ese fin en base a componentes de la aplicación que sean reutilizables, tales como motores de base de datos SQL, gateways DB2, sistemas de gestión de documentos o software de flujo de trabajo.
Una vez implementada, la estrategia tecnológica se convierte en una base familiar para el desarrollo de nuevas aplicaciones cliente/servidor. Otro método estratégico consiste en utilizar tanta tecnología de aplicación inmediata como sea posible, para poner soluciones imperfectas pero útiles en manos de usuarios finales y hacer evolucionar con el tiempo las aplicaciones hacia un entorno cliente/servidor. Esto se conoce como creación evolutiva de prototipos, y es una técnica cliente/servidor utilizada por integradores de sistemas que desean una pronta aceptación de la tecnología por parte del usuario final.
5. ¿Existen aplicaciones que no deban ser consideradas como candidatas al proceso cliente/servidor?
Debido a las limitaciones actuales en áreas críticas de la tecnología de redes, las plataformas cliente/servidor puras -como por ejemplo algunos servidores de base de datos SQL- resultan enormemente inadecuadas para muchas plataformas. Por ejemplo, las bases de datos cliente/servidor no pueden aún manejar miles de estaciones de trabajo simultáneas para una determinada aplicación, lo mismo que pueden hacerlo los mainframes. Las grandes cantidades de usuarios geográficamente remotos plantean un desafío aún mayor, mientras que no existen aún como tecnología coherente bases de datos distribuidas o datos compartidos, sincronizados en múltiples estaciones remotas.
6. ¿Qué aplicaciones son entonces las más adecuadas para el proceso cliente/servidor?
Los entornos cliente/servidor resultan adecuados para aplicaciones en las que el énfasis está en la interacción del usuario con información de la empresa, como soporte de decisiones, análisis estadísticos, previsiones y otras funciones de soporte de la actividad comercial. El proceso cliente/servidor es también una forma muy econó
