ALGUNOS TIPOS DE ARQUITECTURAS Estilos arquitectnicos

Despus de habernos detenido en nuestros dos artculos anteriores en los fundamentos del concepto de arquitectura de software (ver nmeros de agosto y septiembre) podemos ir viendo algunos tipos de arquitectura, tratando de agrupar esos tipos en conjuntos a los que podamos asignar cierto nivel de generalizacin como los que muestran Mary Shaw y David Garlan en su clsico libro Software Architecture (1996). Al generalizar los tipos en estilos podremos ver elementos comunes entre los primeros, que es una de las actividades a la que se aplica cualquier disciplina cuando quiere sacar conclusiones un poco ms genricas que las que podra deducir al analizar slo casos particulares. Para comenzar, los autores aclaran que utilizan tres trminos como equivalentes: patrn de arquitectura, modismo arquitectnico (architectural idiom) y estilo arquitectnico, y presentan 5 de estos estilos: Sistemas de flujo de datos Secuencial en lote Tubos y filtros Sistemas de llamada y retorno Programa principal y subrutina Sistemas orientados al objeto Capas jerrquicas Componentes independientes Procesos comunicativos Sistemas de eventos De esta forma, es evidente que un estilo arquitectnico define una familia de sistemas en trminos de un patrn de organizacin estructural. En particular, de acuerdo a los autores, un estilo arquitectnico define tanto un vocabulario de tipos de componentes y conectores como en el caso de filtros y tubos- como un conjunto de restricciones sobre cmo combinar esos componentes y conectores. Veamos algunos de estos estilos: Mquinas virtuales Intrpretes Sistemas basados en reglas Sistemas centrados en los datos Bases de Datos Sistemas de hipertexto Pizarras

Figura 1 Estilo de tubos y filtros Una de las metforas utilizadas para el nombre filtro- no es quizs muy adecuada, porque sugiere que los que ocurre dentro del proceso es retener algunos de los datos y dejar pasar a otros, cuando lo que pasa en realidad es una verdadera transformacin de los datos de entrada. La descripcin realizada para este tipo de estilo es que cada componente tiene un conjunto de entradas y un conjunto de salidas; cada componente lee corrientes de datos en sus entradas y produce corrientes de datos en las salidas.

Normalmente esto se produce aplicando una transformacin local a las corrientes de entrada y realizando una computacin incremental, de tal manera que la salida comienza antes de haberse consumido toda la entrada. Esto en cuanto a la organizacin, pero si consideramos las restricciones en particular las invariantes- del estilo, es que los filtros deben ser entidades independientes, es decir ninguna depende del estado o condiciones de ninguna otra. Otra invariante importante es que los filtros no conocen la identidad de los otros, ya sea anteriores o posteriores en la cadena de transformaciones. Las especificaciones se restringen a lo que aparece en las corrientes de entrada, o a garantizar lo que se producir como corrientes de salida, pero nunca podrn identificar lo que hay al final de estos tubos de entrada y salida. Otro estilo importante es el de abstraccin de datos u orientacin al objeto, dentro del grupo de los denominados de llamada y retorno. Los componentes de este estilo arquitectnico son los objetos tambin considerados originalmente como instancias de tipos abstractos de datos, aunque ahora diramos clases. Los objetos son ejemplos de un tipo de componentes que algunos llaman gestor porque es responsable de preservar la integridad de un recurso, es decir la representacin. Los objetos interactan a travs de invocaciones de funciones y procedimientos.

Figura 2 Tipos abstractos de datos y objetos Hay dos aspectos importantes en relacin con este estilo: 1) un objeto es responsable de preservar la integridad de su representacin (normalmente, manteniendo algn invariante de la misma) y 2) la representacin permanece oculta respecto de los dems objetos

Patrones arquitectnicos
Ya se habr percibido a lo largo de estos artculos la variedad de denominaciones y sobre todo- la dificultad para compartir las definiciones sobre arquitectura. En la seccin anterior vemos la propuesta de llamar a los estilos patrones, pero optaremos por reservar este trmino a algo que est en un nivel distinto de lo que llamamos estilos. Si tuviramos que relacionar el estilo con algo, podramos decir que est vinculado a la forma ms general en que est organizado un sistema de software, independientemente de consideraciones ms especficas (los tipos de objeto que estamos considerando, por ejemplo). En el ejemplos anterior, podemos describir el estilo mostrando entidades genricas llamadas objetos, y no nos interesa saber a qu tipos de datos abstractos o clases pertenecen. De esta manera, el estilo est asociado a formas generales de organizacin sistemas orientados al objeto- mientras que los patrones estarn asociados a formas ms concretas, que tienen que ver con la especializacin que adoptan los objetos y clases de acuerdo al tipo de aplicacin o entorno tecnolgico, a tcnicas conocidas por su eficiencia para resolver ciertos problemas, etc.

Por ejemplo, pensando que el entorno de ejecucin de una aplicacin puede estar distribuido en distintos elementos nodos- es aconsejable y beneficioso descomponer la aplicacin en capas, correspondientes a los nodos donde podra tener que ejecutarse. Los beneficios de dicha descomposicin son varios, entre los cuales se mencionan: 1) Se puede comprender una capa como un todo coherente, sin necesidad de conocer las restantes; 2) Se puede sustituir una capa con implementaciones alternativas de los mismos servicios bsicos; 3) Se minimizan las dependencias entre las capas; 4) Las capas son un buen sitio para la estandarizacin y 5) Una vez implementada una capa, se la puede utilizar para muchos servicios de alto nivel. La descomposicin ms habitual es decir el patrn usualmente empleado- es dividir la aplicacin en tres capas: 1) Lgica de presentacin, que se ocupa de toda la interaccin entre el usuario y el software, pudiendo tratarse de un sistema de mens muy simple o una interfaz grfica de usuario relativamente compleja; 2) La lgica del dominio, tambin conocida como la lgica de negocio, que es todo lo que necesita conocer la aplicacin para poder trabajar con el dominio en cuestin. Implica realizar clculos basados en datos de entrada o almacenados, validacin de cualquier dato proveniente de la capa de presentacin y la ejecucin de algoritmos especficos en funcin de los comandos de la presentacin; y 3) la lgica de fuente de datos, que se ocupa de comunicarse con otros sistemas que se encargan de tareas en representacin de la aplicacin. Estos pueden ser monitores de transacciones, otras aplicaciones, sistemas de mensajes, etc. Otro ejemplo de patrn arquitectnico podra ser el de Mdulo Tabla, uno de los mltiples patrones presentado por Martin Fowler en Patterns of Enterprise Application Architecture (2003). El enfoque tradicional de la orientacin al objeto est basado en objetos que tienen una identidad. Es decir que si tenemos una clase Empleado, cualquier instancia de la misma corresponde a un empleado particular. Este esquema funciona bien porque una vez que tenemos una referencia a un empleado, podemos ejecutar operaciones, seguir relaciones y recoger informacin sobre el mismo. Pero uno de los problemas con este modelo es la interfaz con las bases de datos relacionales. En muchos casos este enfoque se asemeja al del pariente loco, que vive encerrado en un tico y del cual nadie quiere hablar: con frecuencia este enfoque requiere un trabajo considerable de programacin para llevar los datos y extraerlos de la base de datos y transformarlos a otro tipo diferente de representacin. La ventaja de este patrn es que organizamos la lgica del dominio con slo una clase por tabla de la base de datos, ya que una nica instancia de la clase contiene los diversos procedimientos que se aplicarn a los datos. La diferencia fundamental con un esquema clsico llamado tambin Modelo de Dominio- es que, si tenemos varios pedidos, este ltimo modelo emplear un objeto por cada pedido, mientras que el Mdulo Tabla tendr slo un objeto para manejar todos los pedidos, con lo cual aumentamos la granularidad de los objetos de la aplicacin. Como hemos podido ver, la diferencia entre los estilos y patrones arquitectnicos est en el nivel de abstraccin en el que nos movemos. Los estilos se aplican a un nivel muy alto de abstraccin, en el cual no interesa saber cul es la semntica de los elementos que estamos utilizando, slo hablamos de filtros, tubos u objetos sin interesarnos por lo que estn representando. En el caso de los patrones, tenemos en cuenta el significado de los filtros, tubos u objetos, tal como hemos visto en los patrones de descomposicin en capas en el que se habla de presentacin, dominio de aplicacin y de datos- o en el de Mdulo Tabla, que diferencia entre un objeto que representa un elemento -una lnea de una tabla o registro- u otro objeto que representa la totalidad de la tabla. Otro aspecto importante que menciona Fowler pero que adjudica a Ralph Johnson- es que la arquitectura es algo subjetivo, una comprensin compartida del diseo de un sistema por parte de los desarrolladores de un sistema. En general, esta comprensin compartida est expresada en trminos de los principales componentes del sistema y de sus interacciones. Pero es tambin sobre las decisiones, en especial aquellas que deben tomar correctamente al principio del proyecto porque se las considera difciles de cambiar. Este componentes de subjetividad se debe al hecho de que si algo resulta ms fcil de cambiar de lo que imaginbamos al comienzo, deja de ser una decisin arquitectnica o sobre la arquitectura.

Arquitecturas orientadas a servicios

Hasta ahora nos hemos centrado en la aplicacin, considerndola como una unidad de ejecucin de un procesador o - cuando la visin se ampla y la distribuimos entre nodos- un grupo de procesadores. Por eso tambin tenemos que considerar patrones arquitectnicos para que esa descomposicin sea adecuada y eficiente en funcin de los factores considerados. Pero el concepto de aplicacin sigue amplindose, ya no se reduce a un grupo humano que interacta con el software dentro de los lmites de la empresa u organizacin. La Web nos ha conducido a generalizar lo que en un origen estaba en algn nodo corporativo y a pensar que algunos de los componentes de la aplicacin pueden estar donde sea ms rentable o adecuado que estn. Si necesitamos acceder a algn sitio de la Web para poder ejecutar nuestra aplicacin, diremos que estamos utilizando un servicio de Web. Algunas definiciones genricas que encontramos en la Web nos plantean que un Servicio de Web puede ser incluso el FTP (File Transfer Protocol), que se poda acceder en los 1990 slo desde un comando Unix, pero que desde 1995 poda accederse desde un navegador Web. Esto se denominaba una evolucin de los servicios Web y todava no tenan nada que ver con el uso de XML. Si nos obligaran a resumir este concepto, podramos decir que un servicio Web es "una funcin de negocio autocontenida que opera en Internet" . En algunos sitio de la Web (http://www.servicearchitecture.com) se considera que los Servicios son lo que conectamos utilizando los Servicios Web, Un servicio es el punto final de una conexin. Adems, un servicio tiene algn tipo de sistema de computacin subyacente que soporta la conexin ofrecida. La combinacin de servicios internos y externos a la organizacin- configura una arquitectura orientada a servicios. Al ser ms compleja la coordinacin de todos estos servicios para obtener como resultado una aplicacin, tambin es necesario apelar a conceptos metforas- utilizados en actividades de coordinacin de conjuntos: coreografa y orquestacin. Y tambin es cierto que aparecieron es ese orden. El W3C (WorldWide Web Consortium) cre un grupo de trabajo con la intencin de desarrollar un estndar para describir los vnculos y patrones de uso entre los servicios de Web. El grupo considera a la coreografa un equivalente de los conceptos de orquestacin, de colaboracin, coordinacin, etc. Por otro lado, la orquestacin es considerada como la coordinacin de eventos de un proceso, tambin superponindose con el concepto de coreografa. La orquestacin dirige y gestiona el ensamblado sobre demanda de mltiples servicios componentes para crear una aplicacin o proceso de negocio compuesto. La orquestacin tiende a ser considerada como una nica fuerza coordinadora, mientras que la coreografa tambin se aplica a una coordinacin compartida a travs de mltiples sistemas autnomos. La tendencia actual despus de haberse evaluado varias especificaciones en competicin- est convergiendo en considerar la propuesta conjunta de IBM/Microsoft/Bea como especificacin BPEL4WS (Business Process Execution Language for Web Services) como el estndar principal para la orquestacin de los servicios Web. Es decir que no slo se trata de la organizacin en componentes y sus vinculaciones, de aadir incluso las decisiones ms importantes, sino que a partir de ahora se trata de una coordinacin compleja de eventos para lograr un resultado en el que se integran servicios que estn distribuidos en diversos sitios de la Web (la propia instalacin de la empresa, la de sus clientes, proveedores y partenaires) junto a las propias intervenciones de los usuarios en un todo proceso de negocio genrico- que combina servicios de software y acciones humanas. En el nuevo modelo de empresa gil y eficiente, el software deber implementarse como componentes para una fcil reutilizacin y adaptacin a las arquitecturas orientadas a servicios. La orquestacin es una lgica de negocio que secuencia, coordina y gestiona conversaciones entre servicios Web.