A medida que salen al mercado sistemas de información para salas de producción más nuevos y complejos, deben cambiar las técnicas utilizadas para desarrollar software para los mismos. A fin de crear software para esos sistemas tan distintos, las compañías de software necesitan ofrecer mejores métodos para instrumentar sus productos. En consecuencia, el siguiente paso lógico proviene de la tecnología “orientada a objetos” (OO) que ha madurado desde fines de la década de 1980 hacia el actual modelo basado en componentes. Mediante este modelo, los componentes reutilizables que “se programan una vez y se ejecutan en cualquier parte” tienen el potencial de revolucionar la industria del software.

Al apalancar dicha tecnología, los proveedores de productos de software para la industria del cartón corrugado podrán aprovechar mejor la constante explosión de las comunicaciones. Con el tiempo, para el usuario final, esto implicará una instrumentación más rápida de los sistemas de información para plantas, menos interrupciones para las operaciones de fabricación en el proceso y un mayor rendimiento general de la inversión a largo plazo.

A fin de comprender la actual situación de la tecnología cliente-servidor, primero debemos examinar la computación en redes. La estructura cliente-servidor se describe comúnmente en términos de hileras. Cada hilera representa un cambio de paradigma en la tecnología de computación, lo cual genera mejores niveles de servicio a los usuarios finales.

HILERA ÚNICA

El modelo de unidad central y terminal de computación interactiva fue el primero en adoptarse ampliamente. En este modelo de computación todos los datos y programas residen en una sola máquina o unidad central. Dicha unidad centralizada ejecuta la interfaz del usuario así como la base de datos y las aplicaciones comerciales. En consecuencia, se conoce como “de hilera única”.

El usuario se relaciona con esta máquina a través de una terminal que tiene escasa inteligencia. Solamente sabe cómo recibir pantallas, responder a secuencias de teclas y enviar datos de vuelta a la unidad central. [Valesky 99]

DOS HILERAS

En la década de 1980, las computadoras personales se hicieron populares. Las PC eran atractivas porque costaban menos y respondían más que sus contrapartes de unidad central, no necesitaban del costoso tiempo de computación por unidad central y otorgaban a los usuarios una nueva sensación de libertad y autonomía al brindarles potencia de procesamiento o “inteligencia” local. Un usuario de PC podía traer un conjunto de datos a una aplicación comercial, tal como una hoja de cálculo y manipularlo localmente durante horas sin exigirle requisito alguno al sistema de unidad centralizada. El principio, las PC consistían en unidades autónomas, pero con el tiempo se fueron integrando en redes. Con el tiempo, muchas organizaciones comenzaron a crear nuevos sistemas de información en la PC en lugar de la unidad central. Al mismo tiempo, comenzaron a aparecer los sistemas de administración con base de datos dedicada. La combinación de esos dos elementos: el servidor de la base de datos y la PC cliente se conocen como la arquitectura “de dos hileras” o de cliente-servidor. [Valesky 99]

En un sistema de cliente-servidor de dos hileras, la interfaz del usuario se ejecuta en la PC cliente y la base de datos reside en otro servidor. El servidor en ese escenario se denomina “servidor de base de datos”. La aplicación que se ejecuta en la máquina cliente envía consultas al servidor de la base de datos. La máquina cliente contiene tanto la lógica de presentación —que consiste en el código necesario para desarrollar y ejecutar la interfaz del usuario— y las reglas comerciales —que consisten en la lógica que gobierna la manera de manejar los datos. Actualmente, los sistemas de dos hileras todavía son muy comunes.

Si bien esta es una solución muy flexible, surgen problemas cuando las necesidades de actualizar los clientes y la base de datos ocurren simultáneamente. Todas las máquinas deben paralizarse para las actualizaciones, y los clientes o servidores que se atrasan en la versión de software típicamente no pueden utilizarse hasta que se actualizan. El siguiente ejemplo sirve para ilustrar los problemas que surgen cuando se necesitan cambios en un sistema de dos hileras. [Valesky 99]

Nos han dado la tarea de implementar una aplicación que sencillamente calcula la escala de pago para todos nuestros empleados. Nos reunimos con nuestros amigos del departamento contable y determinamos que la lógica comercial para la remuneración es la siguiente:

salario = horas_trabajadas x escala_de_pago

En un sistema de dos hileras, la lógica de la aplicación sigue este modelo:

1. Solicitar al usuario escala_de_pago, horas_trabajadas y un número_de_empleado.
2. Calcular el salario para el empleado.
3. Generar una sentencia en SQL (lenguaje de consulta estructurada) para actualizar la base de datos.

Actualizar pago de nómina
fijar salario = (salario calculado)
donde número_de_empleado = (ingreso de número de identificación del empleado por el usuario)


4. Ejecutar la sentencia en SQL frente al servidor de la base de datos.

Luego implementamos nuestra aplicación, la instalamos en 50 unidades de escritorio diferentes y nos vamos a casa. A la mañana siguiente, cuando llegamos al trabajo, nos recibe un alboroto de enfadados empleados por hora. Parece que nos olvidamos de un pequeño detalle en nuestra lógica comercial: ¡horas adicionales!

Luego de reconocer la omisión —y de culpar al departamento contable por la definición inexacta del problema— se reescribe el programa del cliente y se vuelve a distribuir a las mismas unidades de escritorio. Por un breve lapso todos están contentos. Sin embargo, después de algunas semanas el departamento de pago de nómina nota que nuestra aplicación ¡paga horas adicionales a empleados que solamente deben recibir un salario normal! Nuevamente hacemos los cambios necesarios en el programa del cliente, desconectamos a todos del sistema, hacemos la actualización y volvemos a distribuir la aplicación.

Este sencillo ejemplo ilustra cómo la interfaz del usuario desarrollada para nuestro sistema de cliente-servidor para pago de nómina de dos hileras se mantuvo sin cambios durante varias modificaciones de la lógica comercial. Desafortunadamente, el sistema de cliente-servidor de dos hileras no nos da la capacidad de distinguir entre las especificaciones de la interfaz y las reglas comerciales; ni tampoco simplifica el proceso de implementación de dichos cambios. Además, la implementación de dichos cambios de software en nuestro sistema de cliente-servidor de dos hileras demostró que seguía implicando interrupciones para nuestras operaciones administrativas. En consecuencia, consideremos una arquitectura de sistemas de información que reduzca en gran medida las interrupciones que todos han aprendido a aceptar cuando se implementan incluso cambios de software menores.

TRES HILERAS

En una tecnología de cliente-servidor tradicional, la aplicación del cliente ha “engordado” porque contiene una lógica de presentación que gobierna el manejo de ventanas y controles, una lógica comercial que gobierna algoritmos y reglas comerciales, y una lógica de manipulación de datos que gobierna conexiones con la base de datos y consultas en SQL. En una arquitectura de tres hileras, la aplicación del cliente contiene solamente la lógica de presentación, lo cual la constituye en un cliente “delgado”. [Thomas 98]

Este método, como en el método de dos hileras, utiliza la base de datos como archivo de información por excelencia y el cliente sigue siendo responsable de proporcionar la lógica de interfaz del usuario. Las reglas comerciales, sin embargo, se separan en una hilera media conocida como el servidor de la aplicación. En lugar de que la máquina cliente deba actualizar directamente la base de datos, el cliente llama al servidor de la aplicación, el cual actualiza entonces la base de datos. Esto libra a los programadores de los detalles de manejar transacciones a bajo nivel del sistema, manejar series de sentencias de ejecución y equilibrar la carga del sistema. El programador de la aplicación puede concentrarse en la lógica comercial y dejar los detalles del manejo del procesamiento de datos a la infraestructura del sistema. [Valesky 99]

Un método de tres hileras para el problema del cálculo de salario analizado anteriormente consistiría en un cliente que presente la misma interfaz del usuario como el modelo de dos hileras. Sin embargo, en lugar de hacer por sí mismo el cálculo de salario y la actualización de la base de datos, el cliente sencillamente llama una función denominada actualizar_salario() en el servidor de la aplicación. El cliente pasa todos los parámetros proporcionados por el usuario a la rutina actualizar_salario(). La rutina actualizar_salario() ejecuta luego la lógica comercial para determinar el salario de los empleados y actualiza la base de datos según corresponde.

Entonces, cuando enfrentamos la necesidad de hacer cambios a nuestra lógica comercial en una arquitectura de tres hileras, solamente hay que cambiar la hilera media. Como podrá imaginar, este método simplifica en gran medida la instrumentación de nuestro cambio ya que necesita aplicarse en un solo lugar: la hilera media.

No obstante, ¿qué tipo de implementación nos permitirá crear esta distribución de software cuando se considera que un entorno de computación empresarial contiene unidades centrales, unidades intermedias, PC, unidades portátiles y otros “aparatos electrónicos”?, sin detallar la diversidad de proveedores de software y hardware que hay en una sala de producción de cajas. En efecto, nuestra industria no está sola:

Datos de encuestas procedentes de establecimientos de fabricación indican que el 41% de los mismos implementarán como mínimo de 2 a 6 módulos de aplicación de fabricación en 1996. Se tratará de aplicaciones distribuidas y se esperará que funcionen en conjunto. Entre los establecimientos de fabricación que invierten en alguna aplicación vertical, el 55% preferiría adquirir las aplicaciones en suites y solamente el 4% afirmó que preferiría adquirir solamente la mejor de su clase, sin considerar su integración. El 41% restante afirmó que prefería una combinación de suites y aplicaciones tipo “la mejor de su clase", según la importancia de la aplicación específica para su negocio. [IDC 98]

Las fábricas de cajas deben tener la libertad de adquirir las mejores soluciones para puntos de proceso, conocidas también como las “mejores de su clase”, de diferentes proveedores e integrarlas luego sin obstáculo alguno a sus redes de información existentes. Como cuestión práctica, las compras de sistemas de información se limitarán en el futuro inmediato por la realidad de tener que soportar una multitud de plataformas y productos de proveedores, los cuales deben funcionar conjuntamente. Además, una porción demasiado grande de casi todos los presupuestos de proyectos es consumida por los costos de integración. La integración se ha constituido en un área gris sin respuestas claras, por lo cual algunos opinan que ya es tiempo de regresar a las suites monolíticas de fuente única.

MODELO BASADO EN COMPONENTES

Se necesitará un nuevo tipo de aplicación distribuida para facilitar las “comunicaciones” entre esos sistemas distintos. Muchos de los proveedores de software más importantes han trabajado conjuntamente para crear un nuevo paradigma denominado “el modelo basado en componentes”.

Primero, definamos el término “componente”.

Un componente es un módulo de software reutilizable: una pieza prefabricada de código de aplicaciones encapsulada, la cual puede combinarse con otros componentes y con código manuscrito para producir rápidamente una aplicación de modificación especial. La programación basada en componentes posibilita las áreas comunes a gran escala y la reutilización de componentes entre uno y otro proyecto. [Thomas 98]

Los componentes vienen en una diversidad de formas y tamaños. Un componente puede ser un sencillo y muy pequeño dispositivo de interfaz gráfica de usuario, tal como un botón; o puede implementarse como un servicio de aplicación complejo, tal como una función de administración de pago de nómina. La arquitectura que guiará la programación e interacción entre dichos componentes se denomina el modelo basado en componentes.

Un modelo basado en componentes define la arquitectura básica de un componente, especificando la estructura de sus interfaces y los mecanismos por los cuales interactúan con su contenedor y los demás componentes. El modelo basado en componentes proporciona los lineamientos para crear e implementar componentes que puedan funcionar conjuntamente para constituir una aplicación mayor. Los diseñadores de aplicaciones pueden combinar componentes de diferentes programadores o proveedores para construir una aplicación. [Thomas 98]

A pesar de que cada componente comprado constituye un producto estandarizado con sus propias ventajas, el proceso de ensamble de los componentes brinda la oportunidad de una importante modificación especial. El software de los componentes también soluciona el problema de los ciclos de actualización masiva. Tradicionalmente, las soluciones totalmente integradas necesitaban actualizaciones periódicas, lo cual solía implicar un complicado proceso de migración desde bases de datos obsoletas, para asegurar la compatibilidad con productos más recientes, de mayor capacitación para el personal, de compra de hardware más potente, etc. En una solución basada en componentes, la evolución reemplaza a la revolución. La actualización individual de componentes puede hacerse según se requiera, lo cual posibilita un funcionamiento mucho más equilibrado. Obviamente, ello requiere un modo diferente de manejar los servicios, pero los beneficios potenciales son enormes. [Szyperski 97]

VENTAJAS DE ESTE METODO

Hay varias áreas clave en las cuales la tecnología de componentes afectará el diseño, la implementación, el mantenimiento y las actualizaciones para las aplicaciones programadas. Es posible que cada una de las siguientes ventajas tenga un efecto directo y positivo en el escenario del rendimiento de la inversión para la implementación del sistema en las fábricas de cajas. [Hurwitz 98]

Según Hurwitz, el modelo basado en componentes:

• Posibilitará diseños de implementación altamente distribuidos.
El modelo basado en componentes permite una distribución más completa de la funcionalidad en tanto que mantiene una integración estrecha.


• Permitirá a los clientes combinar aplicaciones integradas con soluciones tipo “mejor de su clase”.
Las interfaces publicadas disponibles en una infraestructura de componentes permiten que las aplicaciones de terceros se integren eficazmente como componente complementario a una aplicación comercial de mayor escala.


• Posibilitará las estrategias de actualización diferenciales.
En lugar de actualizar la totalidad de un paquete monolítico, los usuarios pueden actualizar componentes individuales a un costo significativamente menor.


• Controlará la complejidad.
La tecnología orientada hacia objetos y las técnicas de programación basadas en componentes son compatibles con el modelado, el diseño, la construcción y la prueba de componentes de software bien definidos, los cuales facilitarán la creación de aplicaciones críticas para la misión.


• Reducirá el tiempo de programación.
Los costos de programación y mantenimiento del software se reducen al distribuir componentes que pueden compartirse y volverse a usar entre proyectos múltiples.


• Se adaptará a requisitos cambiantes.
Mediante las técnicas del modelo basado en componentes, se logra una magnífica facilidad de rastreo entre modelos de proceso comercial, modelos de software de aplicaciones y modelos de bases de datos físicas durante la vida útil de la aplicación.

Aunque los componentes de servidor y los conceptos de hileras múltiples han circulado por casi una década, hay relativamente pocas organizaciones que los hayan puesto en uso. Hasta hace poco tiempo, no se sentían las presiones de escalabilidad que exige una arquitectura de hileras múltiples. El impulso de la computación basada en la web estimula un creciente interés en el método de hileras múltiples. Las aplicaciones comerciales basadas en la web necesitan una arquitectura de aplicaciones de cliente delgado para soportar una escalabilidad masiva, y ser compatibles con clientes basados en exploradores y transferencias de pequeñas aplicaciones (applets). [Gilpin 98]

Una aplicación de cliente delgado es más fácil de manejar que las aplicaciones de cliente-servidor tradicionales. En realidad se instrumenta muy poco código en el sistema del cliente. Casi toda la lógica de la aplicación se instrumenta, maneja y mantiene sobre los servidores. Todas las reparaciones, actualizaciones, nuevas versiones y ampliaciones pueden administrarse a través de un entorno de gestión centralizado. Los expertos de la industria del software opinan que ese es el futuro del diseño de cliente-servidor. “Para el año 2000, el servidor de la aplicación constituirá el modelo de computación dominante”, declara Del Yocam, Director Ejecutivo de Inprise. “Su efecto será aun mayor que el de las bases de datos relacionales”.

Como sucede con cualquier tecnología, la programación basada en componentes no es una solución infalible. Pero trae algo nuevo al proceso de programación que aborda directamente los problemas inherentes a la integración y abre las puertas a mejores sistemas. Sin la llegada de esta tecnología, seguramente la programación se habría paralizado ya que los sistemas de diseño insuficiente no podrían escalarse. En definitiva, los sistemas no podían mantenerse debido a que la complejidad de la lógica comercial había superado los límites del espectro de los servicios básicos prestados en los esquemas de cliente-servidor más antiguos. [Rivas 97]

Este método causa un efecto mayor en el diseño de aplicaciones, su programación e instrumentación. El uso que hace el modelo basado en componentes con respecto a la tecnología orientada a objetos y las técnicas de programación basadas en componentes para desarrollar y distribuir progresivamente las aplicaciones críticas para la misión formaliza un proceso que era demasiado complejo e incontrolable. A medida que se vuelve más difundido y mejor definido, y a medida que se adoptan estrategias de programación de aplicaciones repetibles, el índice de concreción satisfactoria de aplicaciones de cliente-servidor comenzará a ascender. [Rivas 97] Poder adoptar tales normas emergentes como procedimiento y, en el proceso, satisfacer los exigentes requisitos del usuario tiene el potencial de ahorrarle a nuestra industria millones de dólares en costosas sobrecargas en programación de sistemas de información.

HACIA DONDE NOS DIRIGIMOS DESDE AQUI?

Como con toda tecnología riesgosamente avanzada, necesitamos abordar con cautela el modelo basado en componentes. En este momento, el modelo se presenta con diferentes “sabores”. A fin de lograr su adopción en toda la industria, tiene que surgir un líder. Debido a que hay diferencias sutiles entre cada uno de los modelos en competencia, podría ser inadecuado implementar directamente cualquier tecnología en particular. Sin embargo, creemos que es un avance importante en la industria de la computación y estamos utilizando estos conceptos para diseñar los sistemas futuros. Actualmente, hay dos escuelas de pensamiento importantes en cuanto a la implementación concreta del modelo basado en componentes. Una es conducida por Microsoft y se denomina DCOM. La otra se denomina Java y es conducida por un grupo de compañías que incluye a IBM, Oracle, Baan, Sybase y Netscape. En este momento ninguna opción es absolutamente preferible porque cada modelo tiene sus puntos fuertes y débiles.

Desde una perspectiva de programación, esas nuevas tecnologías de componentes probablemente serán objeto de amplia adopción en los próximos 3 a 5 años. Aunque quizás esto no tenga importancia para los compradores de aplicaciones de software hoy día, tendrá mucho peso cuando haya que hacer actualizaciones, mejoras e integraciones entre proveedores.

En definitiva, ello resultará en menos interrupciones así como en una instrumentación más rápida y mayor rentabilidad para el cliente.

Referencias:

[Gilpin 98] Gilpin, Mike. A Market is Born. Miller Freeman Inc., 1998

[Hurwitz 98] Hurwitz Group, Inc. J.D. Edwards’ OneWorld: Componentization for Business Advantage. Hurwitz Group Inc. 1998

[IDC 98] Picardi, Anthony C. Beyond Client/Server: Application Paradigms for the Rest of the Century. IDC 1998

Rivas 97] Rivas, Erick. Enterprise Component Modeling Strategies-ECM clears the applications bottleneck through component-based development and object-oriented techniques. Object Magazine Abril de 1997

[Szyperski 97] Szyperski, Clemens. Component Software – Beyond Object-Oriented Programming. Addison-Wesley, 1997

[Thomas 98] Thomas, Anne. Enterprise JavaBeans Technology-Server Component Model for the Java Platform. Patricia Seybold Group, 1998

[Valesky 99] Valesky, Tom. Enterprise JavaBeans – Developing Component-Based Distributed Applications. Addison-Wesley, 1999