Evolución de la arquitectura: desde la arquitectura de los marcos principales hasta la arquitectura orientada a los servicios




La arquitectura del software se puede definir simplemente como el diseño o copia de un paquete de software o aplicación. Esta copia describe la organización del desarrollo de la aplicación, incluyendo la división de su lógica comercial entre los servidores (computadoras). La arquitectura por lo tanto incorpora protocolos e interfases para interactuar con otros programas o computadoras, y todo esto debe responder por la futura flexibilidad y capacidad de expansión. Por otro lado, aunque un programa integrado e independiente tiene una lógica de programa, ciertamente no tiene la arquitectura del software. Esto no implica que los programas independientes no necesiten diseño, sino para propósitos del presente artículo, la arquitectura entra cuando se habla de “sistemas de sistemas”. Durante las últimas décadas, la arquitectura de las aplicaciones empresariales ha pasado por varias olas de pasos evolutivos y mejoras, por lo que incluso el artículo publicado a principios del año 2000 ahora es algo arcaico (consulte La tecnología de ERP).

Primera parte de la serie Evolución de la arquitectura: desde la arquitectura de los marcos principales hasta la arquitectura orientada a los servicios

El paso rápido que tienen los negocios globales actualmente les presenta a todas las empresas que buscan mejorar y automatizar las operaciones, un conjunto único de retos, y al mismo tiempo las forza a adaptarse rápidamente al cambio. Con la creciente competencia, la globalización y las actividades de fusión y adquisición (M&A), los compradores de aplicaciones empresariales se han dado cuenta de que la arquitectura de los productos juega un papel de gran importancia en la rapidez con que los vendedores (y sus socios, e incluso los mismos usuarios) pueden implementar, mantener, expandir, adaptar e integrar sus productos. La arquitectura de los productos hará mucho más que ofrecer funcionalidades técnicas, interfaces de usuarios (UI), presentación y soporte de las plataformas. Determinará si el producto durará, será graduable para muchos usuarios y podrá incorporar las tecnologías emergentes para adaptarse a los requisitos de los usuarios que están en evolución.

Pasos evolutivos de la arquitectura de las aplicaciones empresariales

Desde un punto de vista arquitectónico, los primeros paquetes de aplicaciones empresariales, en su mayoría de los años 80, se escribieron originalmente en una unidad de proceso o ambiente computacional hospedado. Unidad de proceso se refiere a una computadora grande y cara capaz de soportar cientos o incluso miles de usuarios simultáneamente. En la jerarquía que comienza con un simple microprocesador (como por ejemplo en las calculadoras o los relojes) y va hasta las supercomputadoras, las unidades de proceso están justo abajo de las supercomputadoras. De cierta forma, éstas son incluso más poderosas que las supercomputadoras debido a que soportan más programas de forma simultánea. La diferencia entre las pequeñas unidades de procesos y las mini computadoras es muy vaga, realmente depende de cómo quiere el fabricante comercializar sus máquinas.

La unidad de proceso (o una mini computadora extremadamente poderosa) representa el cerebro, mientras que las llamadas terminales “elementales” solo le permiten al usuario accesar e ingresar los datos. En otras palabras, ya que una terminal elemental es una simple combinación de un teclado y una terminal, no puede procesar información por sí misma. La primera era estaba caracterizada por el procesamiento inmediato de información que hace la unidad de proceso, pero las aplicaciones separadas departamentales de silos residirían en plataformas separadas de la unidad de proceso. Cualquier integración entre, digamos las aplicaciones de cuentas por pagar y compras, significarían grandes transferencias en lotes, sin mencionar que los únicos usuarios de los sistemas eran sólo algunos staff privilegiados de tecnología de la información (IT) que pasarían días o semanas para producir algunos reportes significativos (por lo general después del hecho).

Conforme las computadoras personales (PCs) se hicieron lo suficientemente poderosas para tomar algunas de las tareas de procesamiento que solían llevarse a cabo únicamente en los marcos principales o en las mini computadoras, a finales de los 80 nació la era del cliente/servidor. Cuando se combinan las PCs con computadoras más grandes, ya sea marcos principales, mini computadoras, o servidores basados en PC, al sistema se le conoce como la plataforma cliente/servidor, donde este nombre de cliente/servidor significa que el procesamiento del trabajo se divide entre (por lo menos) dos computadoras. El cliente es la computadora en el escritorio (la máquina del usuario), que contiene la interfase de usuario (UI) y lleva a cabo muestras (como la interfase gráfica de usuario [GUI] de Mac o Microsoft Windows) y algunas funciones lógicas y procesamientos de aplicaciones, mientras que el servidor es la computadora central que contiene bases de datos y programas de aplicación.

En otras palabras, cliente/servidor muestra la división de una aplicación en tareas llevadas a cabo en computadoras separadas conectadas por la red, de la que por lo menos una es una estación de trabajo programable como una PC. El cliente por lo tanto es un programa de software que se utiliza para contactar y obtener datos del programa de servidor y otra computadora. Cada programa de cliente está diseñado para trabajar con uno o más tipos específicos de programas de servidor, y cada servidor requiere una clase específica de cliente. Debido a que el cliente es un dispositivo computacional de escritorio (como una PC) o un programa “servido” por otro dispositivo computacional conectado por red (en otras palabras, el “servidor”), un navegador Web también sería un tipo de cliente.

En cuanto al servidor, es una computadora o paquete de software que proporciona una clase específica de servicio al software del cliente que corre en otras computadoras. El término servidor puede referirse a una pieza del software en particular (una aplicación de servidor Web) o a la máquina en sí en la que opera el software. La principal diferencia entre el cliente y el servidor es que el servidor responde a las solicitudes de los distintos clientes, mientras que los clientes por lo general inician las solicitudes de información desde un sólo servidor. Una sola máquina servidor puede tener varios paquetes diferentes de software del servidor corriendo en éste, y con ello proporcionarles varios servidores distintos (y servicios) a los clientes en la red. Por ejemplo, los servidores de archivos, que en tamaño van desde las PCs hasta los marcos principales, almacenan datos y programas, y comparten dichos archivos con los clientes, en cuyo caso el servidor funciona como una unidad de disco remota para los clientes.

En resumen, cliente/servidor es una arquitectura en la que la PC del usuario (el cliente) es la máquina que solicita, y el servidor es la máquina que suministra, ambas están conectadas por medio de una red de área local (LAN) o red expandida (WAN). A finales de los años 80 principios de los 90, cliente/servidor era la palabra de moda conforme las aplicaciones migraban de mini computadoras centralizadas y unidades de programa a redes de computadoras de escritorio. Para ser un ambiente realmente de cliente/servidor, tanto el cliente como el servidor deben compartir el proceso comercial. Por ejemplo, un servidor de base de datos procesa las solicitudes del cliente para buscar o actualizar los datos en su base de datos, en cuyo caso el servidor lleva a cabo una búsqueda para responder a la pregunta del cliente. No actúa como una unidad de disco remoto, pero participa por completo en la transacción.

La arquitectura cliente/servicio, una de las primeras aplicaciones de de computación distribuida, se convirtió (y todavía es) en la elección predominante de varias compañías por varias razones. En primer lugar, utiliza las PCs en lugar de las terminales elementales para crear un aumento en el poder computacional. Por ejemplo, el procesamiento de gráficas es muy intensivo para la unidad central de procesamiento (CPU) y no es práctico llevar a cabo en una computadora central y por lo tanto es necesario descargarlo en las PCs. En segundo lugar, la velocidad general del sistema aumenta debido a la posibilidad de utilizar bases de datos distribuidas, mientras que los costos de hardware son mucho más bajos en comparación a utilizar un sistema de unidad de proceso.

La primera era también estaba caracterizada por las posibilidades inmediatas de reporteo, dado que un sistema integrado de planificación de los recursos empresariales (ERP) puede estar en una sola base de datos y una plataforma del sistema operativo (OS), y los usuarios (que ahora son más numerosos y pueden encontrarse en algunas funciones a nivel corporativo) no tienen que operar en el departamento IT una producción específica de reporte a un tiempo específico. El cambio de las unidades de proceso a los ambientes cliente/servidor sucedió debido a que las unidades de proceso se percibían como barrera para la reingeniería de los procesos comerciales (BPR), que estaba de moda durante los años 90. Las unidades de procesos, caras y difíciles de utilizar por una gran población de usuarios, parecían ser una barrera para tener una empresa ágil y flexible, que la combinación ERP y BPR intentaba vender en ese tiempo.

Variantes de cliente/servidor

Las principales estrategias para implementar cliente/servidor han estado basadas en dos, tres o n niveles e Internet o intranet. El concepto de niveles proporciona una forma conveniente para agrupar distintas clases de arquitectura.

En un acercamiento de dos niveles, la máquina cliente se conecta a una sola máquina servidor, y el servidor por lo general controla la base de datos central (en otras palabras, una base de datos dedicada maneja los datos para mejorar un desempeño de usuarios múltiples), el cliente controla la UI, y la lógica de aplicación puede estar en el cliente o en el servidor. Los diseños de dos niveles por lo general colocan la lógica comercial con el servidor de datos para centralizar el control y la gestión, mientras que el diseñador decide que tanto de la lógica de procesamiento se debe implementar en el cliente y cuanto en el servidor. Si la mayoría del trabajo se hace en la PC del cliente, se le conoce como una aplicación de cliente grueso, la computadora de un usuario que contiene sus propias aplicaciones que operan en la máquina. Los nuevos programas se instalan en la unidad de disco local, que es la forma más común en que la gente utiliza sus computadoras. Por otro lado, una aplicación de cliente esbelto significa que la mayoría del trabajo se hace en el servidor. En otras palabras, la computadora del usuario no realiza ningún procesamiento de aplicación, sino que realiza funciones como una terminal de entrada/salida (I/O), procesa sólo la entrada del teclado y el ratón y la salida de la pantalla, y todos los procesos de aplicación se hacen en el servidor. Este procesamiento de cliente esbelto por lo general se logra con tecnologías como Microsoft Windows Terminal Server, Citrix Presentation Server (antes Citrix MetaFrame), o X Window System de fuente abierta. Los clientes esbeltos están acompañados lógicamente por “servidores gruesos” que llevan a cabo la mayoría o todos los procesamientos de aplicación, y en el cliente casi no se lleva a cabo ningún procesamiento.

Un desarrollo de tres niveles añade un tercer programa a la mezcla, además de una base de datos (en donde el servidor almacena sus datos), por lo que la lógica comercial se puede dividir en varias computadoras para mejorar la confiabilidad y esparcir la carga de procesamiento. En un acercamiento de tres niveles, la máquina cliente controla la UI y alguna lógica de procesamiento, un servidor de aplicación (posteriormente se proporciona una noción más detallada) maneja el proceso de aplicación comercial empresarial, y uno o más servidores de bases de datos maneja las bases de datos corporativos. Este acercamiento de una interacción de tres formas en un ambiente cliente/servidor, en la que la UI se almacena en el cliente, el volumen de la lógica de la aplicación comercial se almacene en uno o más servidores de aplicación, y los datos se almacenan en un servidor de base de datos, ayuda la gestión de los lanzamientos de versión y las reglas comerciales empresariales. Las aplicaciones empresariales líderes más actuales se construyen con una arquitectura de tres niveles.

La arquitectura de tres niveles es la base para la arquitectura de nivel n, que divide aún más la carga del procesamiento para grandes aplicaciones al distribuir piezas del programa en múltiples servicios. Por definición, las aplicaciones de nivel n se puede romper en modelos en múltiples computadoras. En el término nivel n, la n implica cualquier número de niveles distintivos en la arquitectura del usuario. Una vez que los módulos se colocan en distintas computadoras, cada computadora y módulo se puede optimizar para un uso específico, como una base de datos, lógica comercial, o UI o presentación. Las computadoras en red puede entonces compartir componentes con otras computadoras y aplicaciones para eliminar la redundancia y para optimizar más el desempeño. En algunos escenarios de nivel n, los módulos se pueden reasignar para mejorar el desempeño de la red para locaciones remotas sin comprometer la integridad de la aplicación. La arquitectura de la aplicación de nivel n proporciona un modelo para que los desarrolladores creen una aplicación flexible y reutilizable. Al romper una aplicación en múltiples niveles, los desarrolladores sólo tienen que modificar o añadir un nivel específico en lugar de volver a escribir toda la aplicación, si deciden cambiar las tecnologías o subirlos en la escala.

La arquitectura de nivel n permite un número virtualmente ilimitado de programas que operen simultáneamente, envíen información entre ellos, utilicen protocolos para comunicar e interactuar al mismo tiempo. Esto permite una aplicación escalable mucho más poderosa, que proporciona varios servicios distintos a varios clientes diferentes. También contiene un número de anotaciones que crean problemas de complejidad en el balance del diseño, implementación, desempeño y carga. Existen varias tecnologías que se añaden a esta complejidad, incluyendo la norma CORBA (Common Object Request Broker Architecture), JavaBeans empresarial (EJB), modelo de objeto común distribuido (DCOM) y invocación de método remoto/llamada de procedimiento remoto (RMI/RPC), que son predecesores de la arquitectura orientada al servicio (SOA). Por lo general, si se utiliza una arquitectura de objeto distribuida le permite al cliente escribir programas que son más rápidos, más grandes, más poderosas y más robustas, por lo tanto definitivamente vale la pena el esfuerzo a pesar del inevitable cambio de controlar tal ambiente dinámico con varias partes en movimiento.

Debido a que los clientes cada vez más se han dado cuenta de que la arquitectura juega un papel muy importante en la rapidez con que los vendedores pueden implementar, mantener, expandir, adaptar e integrar sus productos con los módulos de otros vendedores, más y más productos de aplicación empresarial desarrollados o mejorados dentro de los últimos años incorporan ambientes de desarrollo por componentes u orientados a objetos, al igual que las arquitecturas de nivel n.

 
comments powered by Disqus