Viaje al corazón del proceso cliente/servidor

¿Qué mecanismo sustituirá al sistema operativo del mainframe en el papel de garante de la unidad y la coherencia del sistema de información? En el futuro, posiblemente los sistemas operativos orientados a objetos, pero, por ahora, el middleware es la llave maestra del proceso cliente/servidor.

Lo mismo que los champiñones que aparecen de un día para otro, el término "middleware" ha invadido de repente el vocabulario informático. ¿Qué es el middleware? A decir de los proveedores mismos, es muy difícil dar una definición exacta. Tanto si se le considera como un pegamento, como dicen los americanos, entre las aplicaciones y los sistemas, una tecnología que permite desplegar sistemas de información distribuidos o un conjunto de elementos de software que se interponen entre una aplicación y las especificidades de su entorno, las explicaciones son imprecisas y tienen el aire de algo ya visto. Y esto no tiene nada de sorprendente, ya que la noción de middleware, aunque cubre soluciones efectivas e industrializadas, señala al mismo tiempo la existencia de un problema a resolver.

Este problema es la consecuencia directa de la revolución cliente/servidor. En un entorno de proceso centralizado, el software que permite a las aplicaciones funcionar, acceder a los recursos y comunicarse entre sí tiene un nombre: es el sistema operativo.Con el paso de los años y la aparición de nuevas necesidades, los sistemas operativos se han convertido en algo cada vez más pesado y esta pesadez ha repercutido sobre los sistemas de información, cuya evolución es lenta y su flexibilidad casi nula. Sin embargo, al dominar el fabricante, directa o indirectamente, la totalidad de los elementos de hardware y software subyacentes, el sistema operativo sigue siendo el instrumento necesario para el buen funcionamiento y la coherencia de todo. En este universo, no hay necesidad de ningún otro "pegamento" o medio de unión, y el middleware no tiene un lugar.

Las arquitecturas cliente/servidor obligan a reconsiderar estas nociones básicas. En un entorno heterogéneo y distribuido, cada sistema operativo (existen, por definición, muchos) sólo es responsable de la plataforma en la que es ejecutado ¿Qué mecanismo va a realizar entonces, en este nuevo contexto, las funciones fundamentales que se desarrollan tradicionalmente en el sistema operativo? ¿Quién va a garantizar la disponibilidad de los recursos, la comunicación entre las aplicaciones, la sincronización de los procesos? ¿Quién va a vigilar la coherencia y la integridad de los datos, la seguridad del sistema, el control de su rendimiento? Una por una, nivel por nivel, las cuestiones resueltas hace mucho tiempo por los diseñadores de arquitecturas centralizadas deben ser abordadas de nuevo. En el marco del proceso cliente/servidor, estas cuestiones no se refieren ya a una sola técnica con fuerte repertorio (sistema operativo, base de datos, red...) sino que las abarcan todas; y, como novedad con importantes consecuencias, escapan al dominio de los fabricantes. Son ellas las que forman el campo de acción del middleware.

Un dominio abierto

El middleware constituye un dominio abierto, en el doble sentido del término. Técnicamente -a pesar de una oferta bien establecida y sólida, sin la cual el proceso cliente/servidor sería un mito- no todo está resuelto, ni mucho menos. Las arquitecturas cliente/servidor, tal como existen, representan una forma aún imprecisa de sistemas distribuidos y su realización debe mucho al esfuerzo de los desarrolladores de aplicaciones. Se hace sentir la necesidad de sistemas más transparentes y más flexibles, capaces de responder a las necesidades inducidas por modalidades de encadenamiento de tareas totalmente nuevas (como el workflow).

En el plano industrial, el dominio se caracteriza por la ausencia -en todo caso, por el momento- de un actor dominante capaz de imponer su ley al mercado. Aquí, las empresas medianas y pequeñas tienen aún todas sus posibilidades: firmas como Iona Software, Hyperdesk, Tivoli,.. han obtenido, de un día para otro, una visibilidad mundial. No hay nadie que presida sobre los destinos del middleware: es el mercado el que decide, paso a paso, lo que es útil y lo que no lo es.

Este empirismo ha conseguido perfectamente no obstante establecer la primera generación del proceso cliente/servidor, verdadera invención colectiva a la que los grandes vendedores sólo han contribuido modestamente.

¿Cuáles son hoy las herramientas del middleware? A grandes trazos, una arquitectura middleware típica incluye una pequeña cantidad de servidores de datos (muchas veces, uno solo), generalmente bajo Unix, rodeados de varios centenares de puestos de trabajo clientes bajo Windows. Los datos no están distribuidos: los servidores desempeñan un papel centralizador. En contraste -y esto es fundamental- los correspondientes "oficios cliente" (correspondientes, por ejemplo, a las etapas sucesivas del ciclo de vida de un negocio: recepción de pedido, seguimiento operacional, facturación, contabilidad,...) son trasladados hacia los puestos cliente. Ahí reside enteramente el secreto de la flexibilidad, frente a los sistemas tradicionales, de las arquitecturas cliente/servidor tal como existen actualmente.

El papel del SGBDR

El punto de apoyo de este modelo es el Sistema Gestor de Bases de Datos Relacionales (SGBDR). Es éste el que enmascara las especificidades de las máquinas y de los sistemas operativos, garantiza el uso compartido de los datos, gestiona la integridad y la coherencia de la información. El SGBDR es la herramienta middleware por excelencia.

Los vendedores de sistemas SGBDR, después de haber descuidado durante mucho tiempo este sector, han tenido que trabajar el doble durante estos dos últimos años para compensar el retraso. La etapa siguiente, fácilmente previsible, es la de los monitores transaccionales. Con este concepto, procedente directamente de los grandes sistemas (y que ofrece al mismo tiempo un nuevo ejemplo de middleware), está en vías de producirse un cambio de escala o magnitud. Sin embargo, no es cierto que la segunda generación de cliente/servidor -y de middleware- se encuentre de ese lado, ya que la verdadera apuesta no está en limitarse a reproducir, en un entorno distribuido, las funcionalidades de los grandes sistemas. Están en curso de aparición nuevos tipos de aplicaciones, inspirados por la abundancia de plataformas potentes y económicas, la madurez del sector software y el crecimiento de las redes.

Bajo el nombre de groupware, de workflow, de ingeniería simultánea, se elaboran nuevos modelos informáticos que no se contentan ya con automatizar el tratamiento de los datos, sino que son aptos para representar procesos operacionales y que explican mejor el funcionamiento real de las empresas. El gran éxito de los sistemas SGBDR procede de que han permitido ofrecer una memoria compartida a un grupo de personas. Con el groupware, se ofrece un tratamiento de grupo que gestiona las interacciones entre las personas. Es el logro más avanzado del proceso cliente/servidor. El diseño de sistemas, ofreciendo un marco natural a tales aplicaciones, plantea cuestiones que los diseñadores de antaño no habían tenido ocasión de prever.

En resumen, nos encontramos en el terreno de la gestión de objetos distribuidos. Y las estrategias que se elaboran en torno al OMG y su norma CORBA (Common Object Request Broker), en torno a Microsoft y su modelo concurrente OLE/COM, nos trasladan, curiosamente, a los sistemas operativos, ya que, detrás de DSOM (la implementación IBM de CORBA) está Taligent, y detrás de OLE/COM, está Cairo. Se trata de una nueva generación de sistemas operativos, concebida para responder a las nuevas necesidades. ¿Seguirá siendo el middleware en el día de mañana la obra de las firmas independientes? Es lo menos probable.