Implementación de una Plataforma ESB Adaptativa

Transcripción

1 Instituto de Computación - Facultad de Ingeniería Universidad de la República Montevideo, Uruguay Implementación de una Plataforma ESB Adaptativa Informe de Proyecto de Grado Jorge Luis Laborde de los Santos Mauricio Fenoglio Armand Ugon Matías Galnares Rodríguez Supervisor y Orientador: Ing. Laura González 12 de Diciembre, 2012

2 - 2 -

3 Resumen Los sistemas de software orientados a servicios operan en ambientes altamente cambiantes, por lo que se hace más frecuente la necesidad de contar con capacidades de adaptación que permitan afrontar rápidamente cambios inesperados. Dado que el Enterprise Service Bus (ESB) es la plataforma preferida para implementar Arquitecturas Orientadas a Servicios (SOA), han surgido propuestas de plataformas ESB adaptativas para abordar esta problemática. En este proyecto, se realizó una implementación de una de estas plataformas, la cual se basa en las capacidades de mediación de los ESB, para responder a necesidades de adaptación en una SOA de forma dinámica, automática y en tiempo de ejecución. Dicha implementación apuntó a analizar la factibilidad técnica de desarrollar la Plataforma ESB Adaptativa sobre un producto ESB existente, a tener una plataforma funcional que aplique acciones de adaptación en sistemas orientados a servicios y que además permita validar su correcto funcionamiento y desempeño. En primer lugar, se analizaron diferentes productos ESB existentes en el mercado, con el fin de seleccionar el producto ESB que contara con las mejores cualidades de acuerdo al contexto de este proyecto. Este análisis permitió seleccionar a JBoss ESB como el producto base para la implementación, debido a su buena documentación y a su amplio conjunto de capacidades de mediación. La plataforma fue diseñada e implementada para tener un alto grado de extensibilidad. La implementación aprovechó varios de los componentes de JBoss ESB y además extendió su conjunto base de funcionalidades. En particular, se implementaron funcionalidades concretas como el Ruteo Basado en Itinerario y el componente Cache, que pueden ser reutilizadas en otros contextos. En la etapa final de este proyecto, se definió un caso de estudio en el contexto de Gobierno Electrónico, y a partir de él se especificaron pruebas que permitieron evaluar si la plataforma con la implementación realizada mejora los atributos de calidad de los servicios. Las pruebas ponen de manifiesto una mejora en dichos atributos de calidad, permitiendo además que los problemas de adaptación sean detectados y solucionados rápidamente. Por último, se observa que el overhead generado por la plataforma es despreciable en relación a las mejoras que se generan. Palabras claves: arquitectura orientada a servicios, enterprise service bus, web services, mediación, adaptación, monitoreo

4 - 4 -

5 Contenido 1 Introducción Contexto y Motivación Objetivos Aportes del Proyecto Organización del Documento Conocimiento Existente Web Services Enterprise Service Bus (ESB) Patrones para Enterprise Service Bus Otras Tecnologías Plataforma ESB Adaptativa Selección del Producto ESB Productos ESB analizados Criterios de evaluación Evaluación de los Productos Selección del Producto ESB JBoss ESB Solución Propuesta Descripción Conceptual Arquitectura General Principales Componentes Interacción entre componentes Extensibilidad Limitaciones y mejoras Detalles de Implementación Mecanismos de Adaptación Mecanismos de Monitoreo Administrador de Monitoreo Administrador de Requerimientos de Servicios Gateway de Adaptación Registro de Servicios y Configuración Motor de Adaptación y Monitoreo Consola de Administración Componentes ESB Reutilizables Problemas Encontrados Caso de Estudio y Pruebas Realizadas Caso de Estudio: Gobierno Electrónico Pruebas Realizadas Conclusiones

6 7 Conclusiones del Trabajo Resumen y Contribuciones Trabajo a Futuro Referencias Apéndice 1. Estrategias de Adaptación Apéndice 2. Principales Características de los Productos ESB Apéndice 3. Estructura Física de la Plataforma Apéndice 4. Opciones de Extensibilidad de la Plataforma

7 1 Introducción Este proyecto, posicionado en el área de Adaptación de Sistemas Basados en Servicios (SBSs), propone y lleva a cabo una implementación de la solución propuesta en "Plataforma ESB Adaptativa para Sistemas Basados en Servicios" [1]. Dicha platataforma adaptativa se basa en las capacidades de mediación brindadas por los Enterprise Service Bus (ESB), infraestructura base preferida para la implementación de una Arquitectura Orientada a Servicios (Service Oriented Architecture, SOA), a fin de abordar necesidades de adaptación en los SBSs de forma dinámica, automática y en tiempo de ejecución. Este capítulo presenta el contexto y la motivación del proyecto, los objetivos planteados, los aportes del proyecto y finalmente la organización del resto del documento. 1.1 Contexto y Motivación Los sistemas de software actuales operan en ambientes altamente dinámicos por lo que necesitan, cada vez más, contar con capacidades de adaptación que les permitan abordar rápidamente cambios inesperados, por ejemplo en metas de negocio o entorno de ejecución. [1] El concepto de Arquitecturas Orientadas a Servicios nace a mediados de los años 80, impulsado por las comunidades que iniciaron el diseño de software a través de componentes (Programación Orientada a Objetos). Este tipo de arquitecturas conceptuales permiten organizar las empresas en términos de aplicaciones, servicios y procesos de negocio [2] [3]. A su vez, estas arquitecturas poseen un enfoque alentador para abordar requerimientos de adaptación, dado que permiten mejorar la agilidad en el desarrollo e incrementar la reutilización de los servicios, con el consiguiente beneficio de reducción de costos y tiempo en los denominados Sistemas Basados en Servicios. Sin embargo, las tecnologías y métodos actuales para SOAs no proveen soluciones nativas y completas que aborden requerimientos de adaptación, de forma automática, dinámica y en tiempo de ejecución [1]. Esto limita considerablemente la rapidez con la que los SBSs pueden responder frente cambios inesperados, como por ejemplo, cambios en los contratos de los servicios y variaciones en los tiempos de respuesta. Por otra parte, el Enterprise Service Bus (ESB) está ampliamente reconocido como la infraestructura preferida para dar soporte a la implementación de una SOA. Un ESB proporciona una plataforma de integración basada en estándares que combina, mensajería, Web Services, transformación de datos y ruteo inteligente en una arquitectura SOA regida por eventos [4]. Este tipo de plataformas permiten mitigar las diferencias existentes entre los distintos servicios que se deseen intercomunicar. En este contexto, en lugar de interactuar directamente, los servicios se comunican enviándose mensajes a través del ESB. Según lo mencionado anteriormente, el ESB resulta un lugar ideal para efectuar acciones de adaptación debido a su rol mediador en una SOA. Por este motivo, han surgido recientemente propuestas de ESB adaptativos, tales como la plataforma propuesta en [1] y Adaptive SOA Solution Stack [5], las cuales tienen la habilidad de responder a requerimientos de adaptación en una SOA, utilizando las capacidades nativas de los ESBs

8 En particular, en [1] se propone y especifica una plataforma adaptativa basada en las capacidades de mediación de los ESBs, la cual permite responder a necesidades de adaptación en una SOA de forma dinámica, automática y en tiempo de ejecución. Dicha plataforma se basa en patrones de mensajería e integración comúnmente soportados en los productos ESB, por lo que brinda una solución genérica y factible de aplicarse en la mayoría de estos productos. En [1] se describe también el desarrollo de un prototipo que permitió evaluar la factibilidad técnica de la implementación de algunos de los componentes de la plataforma propuesta. Sin embargo, este prototipo no constituye una solución completa, que permita evaluar, por ejemplo, el correcto funcionamiento y desempeño de la plataforma adaptativa. 1.2 Objetivos En el marco de la problemática descripta anteriormente, el objetivo general de este proyecto es realizar una implementación de un ESB Adaptativo a partir de la solución propuesta en Plataforma ESB Adaptativa para Sistemas Basados en Servicios [1]. Para esto, se plantean los siguientes objetivos específicos: Analizar diferentes productos ESB existentes en el mercado, para luego seleccionar aquel producto que mejor se ajuste a las limitaciones de tiempo de este proyecto, y además brinde facilidades que permitan su extensión. Implementar la Plataforma ESB Adaptativa tomando como base el producto ESB seleccionado. Implementar una herramienta que facilite la administración y configuración de la Plataforma ESB Adaptativa, y que permita realizar un seguimiento de sus acciones de adaptación. Definir un caso de estudio que permita realizar pruebas para validar el correcto funcionamiento y desempeño de la plataforma. Como requerimiento adicional al proyecto, el producto ESB seleccionado debe estar implementado en Java y su licencia debe ser Open Source. 1.3 Aportes del Proyecto Los principales aportes del proyecto son: Análisis de las principales capacidades de los productos ESBs basados en la plataforma Java y con licencia Open Source, que puede servir como guía para posteriores proyectos que requieran realizar una comparativa entre distintos ESBs

9 Implementación de una Plataforma ESB Adaptativa de acuerdo a la propuesta en Plataforma ESB Adaptativa para Sistemas Basados en Servicios [1]. Dicha implementación se apoya en el producto JBoss ESB y en particular en los patrones de mensajería e integración soportados por el producto. La plataforma implementada provee distintas opciones de extensibilidad para sus principales componentes, que permiten integrar fácilmente nuevos servicios y nuevas funcionalidades. Por ejemplo, se podrían crear nuevos mecanismos de monitoreo, que permitan obtener más información acerca del funcionamiento de los servicios registrados en la plataforma. Implementación de mecanismos de adaptación y monitoreo concretos, tales como Cache, Retardador de Mensajes, Balanceador de Carga y Monitoreo de Contratos de Servicios, entre otros. Concretamente, estos mecanismos permiten hacer frente a necesidades de adaptación que surgen por la degradación de la calidad de servicio (tiempo de respuesta y porcentaje de respuestas exitosas), la saturación de servicios (cantidad de invocaciones por período de tiempo), y cambios en los contratos de servicios. Diseño e implementación de componentes para la plataforma JBoss ESB que pueden ser reutilizados en otros proyectos de igual dominio. En particular, el Ruteo Basado en Itinerario no es implementado de forma nativa por JBoss ESB, por lo que debió ser implementado para la plataforma adaptativa, pudiendo ser reutilizado en otros proyectos. Desarrollo de las principales funcionalidades de los distintos componentes del Motor de Adaptación y Monitoreo, que implementan decisiones básicas de adaptación según los distintos datos monitoreados. Cabe destacar, que la implementación de este motor es totalmente independiente del resto de los componentes de la plataforma, lo que facilita su integración con nuevos componentes. Por ejemplo, se podría utilizar la misma implementación del Motor de Adaptación y Monitoreo con una nueva implementación del ESB Adaptativo, basada en otro producto ESB. El motor implementado, está compuesto por diferentes componentes, uno encargado de detectar aquellas situaciones que generen requerimientos de adaptación, otro que encapsula las diferentes estrategias que permiten abordar las necesidades de adaptación, y finalmente, un componente que selecciona y aplica las estrategias según las necesidades de adaptación detectadas. Implementación de una consola de administración que facilita administrar, configurar y monitorear toda la información brindada por la Plataforma ESB Adaptativa. En particular, esta consola presenta de forma gráfica los datos de todos los servicios registrados, permitiendo además, visualizar las acciones de adaptación que se realizan en la plataforma

10 Realización de pruebas a través de un caso de estudio, lo que permitió evaluar distintos aspectos de la plataforma, como por ejemplo, su correcto funcionamiento y desempeño en un escenario simplificado de Gobierno Electrónico. 1.4 Organización del Documento El resto del documento se organiza de la siguiente manera. En el Capítulo 2, se presenta un resumen del conocimiento existente relevante a la problemática abordada en este proyecto. En el Capítulo 3, se presentan los diferentes productos ESB que fueron analizados en el marco de este proyecto, y se detallan los criterios de evaluación utilizados para seleccionar el producto ESB más adecuado a las necesidades de este trabajo. Además, se presenta un breve resumen de las características técnicas particulares del producto JBoss ESB, en el cual se basa la Plataforma ESB Adaptativa implementada. En el Capítulo 4, se presenta la plataforma implementada, para la cual se especifican sus características generales, sus componentes y sus principales interacciones. Conjuntamente, en este capítulo se presenta cómo se implementaron los distintos componentes de la Plataforma ESB Adaptativa. En el Capítulo 5, se describe detalladamente la implementación de los principales componentes de la Plataforma ESB Adaptativa, destacando aquellos componentes que pueden ser reutilizados en otros contextos, y comentando algunas de las problemáticas presentadas durante la etapa de implementación de este proyecto. En el Capítulo 6, se presenta el caso de estudio de Gobierno Electrónico, que proporciona un contexto para evaluar el desempeño de la plataforma. Además, se describe cada una de las pruebas a las que fue sometida la plataforma. Finalmente, en el Capítulo 7, se presentan las conclusiones del proyecto, resumiendo el trabajo realizado, describiendo sus contribuciones, y comentando posibles trabajos a futuro

11 2 Conocimiento Existente Este capítulo presenta los conceptos fundamentales de la problemática planteada en este proyecto, estableciendo un marco conceptual que permita una mejor comprensión del documento. En primer lugar, en la Sección 2.1 se describen los conceptos generales: tecnología de Web Services y las Arquitecturas Orientadas a Servicios. En la Sección 2.2 se presenta el Enterprise Service Bus (ESB). La Sección 2.3 presenta un conjunto de patrones (patterns) asociados a los ESB, los cuales constituyen las bases fundamentales de la solución propuesta en este trabajo. En la Sección 2.4 se describen algunas tecnologías del lenguaje Java que facilitan la comprensión de este documento. Finalmente, en la Sección 2.5 se describen las principales características de la Plataforma ESB Adaptativa propuesta en [1]. 2.1 Web Services Un Web Service es un conjunto de estándares y protocolos. Es utilizado para intercambiar información entre distintos sistemas, brindando interoperabilidad entre máquinas (a través de una red) y logrando independizarse de las distintas plataformas. Además, posee una interfaz pública bien definida, la cual es fácilmente procesable. Los mensajes son transportados generalmente sobre el protocolo HTTP y codificados en lenguaje XML. La interoperabilidad se consigue a partir de estándares abiertos que son regulados por la W3C 1 y OASIS 2, entre otros. [6] Actualmente, los Web Services son el principal mecanismo para lograr la interoperabilidad entre aplicaciones tecnológicamente heterogéneas y constituyen la tecnología preferida para la implementación de una SOA. La tecnología de Web Services está basada en tres estándares fundamentales: Web Services Description Languaje (WSDL), Simple Object Access Protocol (SOAP) y Universal Description Discovery and Integration (UDDI). En las siguientes sub-secciones se describe con mayor detenimiento los estándares mencionados Web Services Description Language (WSDL) WSDL [7] es un formato XML para describir servicios de red, como un conjunto de puntos finales (endpoints) que operan sobre los mensajes que contienen información orientada a documentos u orientada a procedimientos. Los documentos WSDL, se componen de dos grandes partes: una descripción abstracta y una descripción concreta. A modo de ejemplo la Figura 1 presenta gráficamente las descripciones de un WSDL

12 Figura 1 - Representación gráfica de las descripciones de un WSDL. En la descripción abstracta, se encuentran las características de la interfaz, independientemente de la tecnología, como lo son las Operaciones, el Tipo de Puerto y los Mensajes de Entrada y Salida. En la descripción concreta, se encuentran los elementos de Vinculación (posible tecnología de transporte: SOAP, HTTP, etc.), Puerto (dirección física para acceder según protocolo) y Servicio (conjunto de puertos relacionados). En la Figura 2 y Figura 3 se presentan ejemplos de descripciones abstractas y concretas del WSDL respectivamente. Se considera un servicio denominado TestService, que contiene una operación hello, la cual recibe como parámetro un String y retorna como respuesta otro String. Figura 2 - Descripción Abstracta WSDL

13 Figura 3 - Descripción Concreta WSDL Simple Object Access Protocol (SOAP) SOAP [8] es un protocolo ligero para el intercambio de información en un entorno descentralizado y distribuido. En la Figura 4 se presenta gráficamente la estructura de un mensaje SOAP. Figura 4 - Estructura de un mensaje SOAP. Este protocolo se basa en un documento XML, que consiste de una sección denominada Envelope (obligatoria), la que a su vez está compuesta de otras dos secciones: una denominada Header (opcional) y otra denominada Body (obligatoria). Cada una de ellas se detalla en las siguientes sub-secciones SOAP Envelope Esta estructura sintáctica define un documento XML como un mensaje SOAP, la cual debe estar siempre presente y ser la primera sección del mensaje. En esta sección se definen los distintos namespaces 3 que son usados en el resto del mensaje. Los namespaces son utilizados para garantizar la unicidad de los

14 elementos XML y evitar ambigüedades. A modo de ejemplo, la Figura 5 presenta el Envelope de un mensaje SOAP SOAP Header Figura 5 - Envelope de un mensaje SOAP. Esta estructura sintáctica es opcional y es un mecanismo genérico para extender las características de los mensajes SOAP, de una manera descentralizada y sin previo acuerdo entre las partes que se comunican. En caso de estar presente, debe ser el primer elemento del Envelope. A modo de ejemplo algunas extensiones que pueden ser implementadas mediante esta estructura son: transportar información auxiliar para la autenticación, manejo de transacciones, etc. En la Figura 6 se presenta un ejemplo de posibles extensiones que se pueden adjuntar en un Header de un mensaje SOAP SOAP Body Figura 6 - Header de un mensaje SOAP. Es una estructura sintáctica que actúa como contenedor de la información que se envía al receptor del mensaje. Debe estar siempre presente en los mensajes SOAP y se ubica a continuación del Header, si este último está presente, en caso contrario será el primer elemento del Envelope. Típicamente esta estructura es utilizada para proveer un mecanismo simple de intercambio de información con el receptor del mensaje SOAP. En esta parte del mensaje es donde se encuentran las invocaciones RPC 4 o bien el resultado de la invocación. A modo de ejemplo, la Figura 7 presenta un mensaje SOAP que invoca a la operación sayhello de un determinado servicio, enviando como parámetro un nombre (name=test)

15 Figura 7 - Body de un mensaje SOAP Universal Description, Discovery and Integration (UDDI) Las especificaciones UDDI [9] definen un servicio de registro para los Web Services y otros servicios electrónicos y no electrónicos. Un servicio de registro UDDI es un servicio web que gestiona la información sobre proveedores de servicios, las implementaciones de servicios, y los metadatos de servicios. Los proveedores de servicios pueden usar UDDI para anunciar los servicios que ofrecen, mientras que los consumidores pueden usar UDDI para descubrir los servicios que se adapten a sus necesidades y obtener los metadatos necesarios para poder consumirlos. 2.2 Enterprise Service Bus (ESB) Esta sección describe el Enterprise Service Bus y el rol que éste juega en las Arquitecturas Orientadas a Servicios. En la sección se define el concepto de ESB. En la sección se detallan algunas de las características más importantes que poseen los ESB para brindar soporte a arquitecturas SOA Definición de ESB El concepto de ESB fue descripto por primera vez como una nueva arquitectura que aprovecha las ventajas de los Web Services, tecnologías middleware, ruteo inteligente y transformaciones por Roy Schulte, en la publicación Predicts 2003: Enterprise Service Buses Emerge en Diciembre del Hoy en día las definiciones de ESB no hacen referencia a una nueva arquitectura, sino que representan una infraestructura que sirve de backbone de las Arquitecturas Orientadas a Servicios. Una de las más completas definiciones es la formulada por Mike Papazoglou en El ESB es una columna vertebral de mensajería basada en estándares abiertos y diseñada para posibilitar la implementación, despliegue y administración de soluciones SOA. Es un conjunto de capacidades de infraestructura implementadas vía tecnologías de middleware que posibilitan una SOA y alivianan problemas de disparidad entre aplicaciones que se ejecutan en plataformas heterogéneas y usan diversos formatos de datos. [10] Este tipo de plataformas puede traer ventajas significativas en contextos en los que existan necesidades de integración de sistemas. Las ventajas del uso de un ESB se ven con mayor claridad en contextos en donde dicha integración se realice en un ambiente heterogéneo de aplicaciones que trabajen en

16 múltiples plataformas. Los ESBs pueden resolver gran parte del proceso de integración permitiendo tener un buen control del mismo Características básicas de un ESB Un ESB brinda una gran cantidad de características o funcionalidades para facilitar la implementación de una aplicación orientada a servicios. En general, las características de los ESBs dan soporte a las necesidades de las arquitecturas SOA, ya que cuentan con capacidades de conectividad, adaptación, ruteo y transformación de mensajes, flujos de mediación, mensajería asincrónica y capacidad de monitoreo para los mensajes que se envían a través de él. La Tabla 1 presenta el conjunto de capacidades mínimas que debe poseer un ESB de acuerdo a lo relevado en [11]. Categoría Capacidad Motivo Comunicación Ruteo. Manejo de Direcciones. Al menos un tipo o estilo de mensaje. Provee transparencia para localizar servicios y brinda soporte para la sustitución entre servicios. Al menos un protocolo de transporte. Integración Integración entre varios estilos o adaptadores. Transformación entre protocolos. Brindar soporte para la integración en entornos heterogéneos y la posibilidad de sustituir un servicio por otro. Servicio de interacción Definición de interfaces de servicios. Modelo de mensajes de servicios. Posibilidad de sustituir la implementación de un servicio por otra. Soporte para los principios de las arquitecturas SOA, aislando la aplicación de las implementaciones concretas de los protocolos de servicio. Dirección y autonomía Administración de las características. Un punto de control para el manejo de los nombres y las direcciones de los servicios. Tabla 1 - Características básicas de un ESB. 2.3 Patrones para Enterprise Service Bus La integración de procesos de negocio continúa siendo un problema complejo, dado que las aplicaciones de negocio en general no funcionan aisladas de otros sistemas. Para manejar esta problemática frecuente para Arquitectos y Desarrolladores, existen los patrones de integración (Enterprise Integration Patterns), que se han convertido en el estándar para describir problemas recurrentes de integración y sus posibles soluciones

17 El libro Enterprise Integration Patterns [12] de los autores Hohpe & Woolf s junto con su web se han convertido en lectura obligatoria cuando se trabaja con SOA 5. Hohpe y Woolf comparten años de experiencias en trabajos de integración mostrando soluciones a problemas recurrentes en forma de patrones o recetas agnósticas de tecnologías, lo que permite que sean aplicables en distintos escenarios. La solución al problema de implementar un ESB Adaptativo se apoya en distintos patrones de mensajería, como por ejemplo los identificados por Hohpe y Woolf. A continuación se describen los patrones más relevantes en el contexto de este proyecto, agrupados de acuerdo a la problemática que solucionan Routing Patterns (Patrones de ruteo) Esta categoría agrupa los patrones que brindan soluciones a los problemas de dirigir un mensaje que llega al ESB al correcto destinatario. Los patrones de ruteo de mensajes, consumen mensajes desde un canal y lo republican en otro, de acuerdo a una serie de propiedades o condiciones. Los más comunes son los basados en el contenido del mensaje (content-based router), basados en el contexto (context-based router) y los basados en indicadores de carga del sistema (load-balancing router). A continuación se detallan los patrones de ruteo utilizados en el contexto de este proyecto Content Based Router (Ruteo Basado en Contenido) El patrón Content Based Router examina el contenido del mensaje y rutea cada mensaje al canal correspondiente basándose únicamente en su contenido. El ruteo puede estar basado en varios criterios como, la existencia de un determinado campo o un valor específico para un campo dado. Por lo general, los distintos criterios a aplicar sobre el contenido del mensaje son especificados en forma de reglas que determinan la relación entre el destino final y el contenido del mensaje. La Figura 8 presenta la idea general del Ruteo Basado en Contenido. Figura 8 - Content Based Router

18 Routing Slip (Ruteo Basado en Itinerario) Como todos los patrones de ruteo, el ruteo basado en itinerario determina dinámicamente el destino de un mensaje. Lo interesante de este patrón es que el camino que debe seguir un mensaje está definido en el propio mensaje y es transportado como metadato, permitiendo eliminar la dependencia de un motor centralizado de ruteo. A modo de ejemplo, la Figura 9 exhibe la idea general de este patrón. Figura 9 - Routing Slip Scatter-Gather El patrón Scatter-Gather soluciona la problemática de brindar la mejor respuesta al cliente cuando se cuenta con más de un servicio que puede procesar la misma petición. Es común utilizarlo para mejorar los tiempos de respuesta o la calidad de las mismas, en base a una lista de recursos intercambiables. Este patrón es la composición del patrón Broadcast y Aggregator, el primero envía una solicitud a una lista de destinatarios y el segundo genera una respuesta consolidada en base a todas las respuestas recibidas. En la Figura 10 se presenta la idea general de este patrón donde a partir de un mensaje se disparan varias solicitudes a diferentes servicios, con el objetivo de obtener la mejor respuesta. Figura 10 - Scatter-Gather

19 2.3.2 Endpoint Patterns Esta categoría contiene todos los patrones que describen las distintas formas de consumir y generar mensajes, tanto por las aplicaciones que se comunican con el ESB, como las de sus propias comunicaciones internas. Algunos de los patrones de esta categoría se aplican para los receptores de mensajes, otros para los emisores y existen patrones que dan soporte a ambos. Un ejemplo de ello es el patrón Messaging Gateway el cual tiene gran importancia en la plataforma Messaging Gateway Este patrón permite encapsular el acceso al sistema y es utilizado para aplicar un conjunto de operaciones de mediación comunes a todos los mensajes entrantes y/o salientes al ESB. Resulta particularmente útil para dar funciones de borde como seguridad, autenticación y auditoría, implementándose por única vez en el Gateway y utilizándose para todos los mensajes que pasan a través del ESB. Este patrón también admite la aplicación selectiva de los procesos de mediación, de acuerdo a propiedades o datos provenientes del propio mensaje. La Figura 11 presenta la idea general de este patrón, donde el Gateway intercepta los mensajes que se envían a un determinado servicio del ESB. Figura 11 - Messaging Gateway Transformation Patterns Cuando se integran diferentes aplicaciones a través de un sistema de mensajería, difícilmente éstas coincidan en un formato de datos común. Para estos casos existen diferentes patrones de transformación de mensajes que permiten adaptar y resolver las diferencias existentes entre los distintos sistemas a integrar. Dichos patrones permiten agregar (patrón Content Enrichment), eliminar (patrón Content Filter), o simplemente reorganizar (patrones Normalizer y Canonical Data Model) la información contenida en los mensajes. A continuación se describe el patrón Canonical Data Model, el cual es el que más se adecua a los requerimientos de integración de este proyecto

20 Canonical Data Model Este patrón permite minimizar la dependencia a un modelo de datos particular, el cual propone diseñar un modelo de datos independiente de las aplicaciones. Este modelo permite integrar una nueva aplicación simplemente definiendo la transformación entre su modelo de datos particular y un modelo de datos canónico, independientemente de la cantidad de aplicaciones que estén interactuando. Finalmente, la Figura 12 presenta la idea general de este patrón. Figura 12 - Canonical Data Model Otras categorías En esta categoría se localizan aquellos patrones que no fueron detenidamente descriptos en el trabajo de Hohpe & Woolf s Servicio Virtual Los patrones que pertenecen al grupo de Servicios Virtuales describen cómo desacoplar servicios utilizando niveles de indirección en un ESB. Visto de otra manera, estos patrones permiten realizar requerimientos de mediación (ruteos, transformaciones, conversión de protocolos, etc.) que surgen debido a necesidades de conectividad en una SOA. Algunos ejemplos de este grupo de patrones son: Servicio Proxy Simple, Selector de Servicio (Ruteo), Traductor de Servicio, Normalizador de Servicio y Selector de versión. [13] En particular, el patrón Servicio Proxy Simple es el más relevante del grupo de Servicios Virtuales en el contexto de este proyecto, ya que permite crear un nuevo servicio virtual en el ESB a partir de un servicio existente. Por lo tanto, se logra acceder a un servicio original a través de un punto controlado dentro del ESB. La Figura 13 presenta la idea general de este patrón, el cual accede a un Web Service externo a través de un Servicio Virtual publicado en el ESB

21 Patrón Cache Figura 13 - Patrón Servicio Proxy Simple. Cuando se utiliza un middleware como canal de comunicación de mensajes entre los receptores y los emisores de una aplicación orientada a servicios, es común que el rendimiento se vea afectado debido a la mediación de los mensajes realizada por el middleware. El patrón cache [14] permite mejorar los tiempos de respuesta de los servicios, utilizando un almacenamiento de las respuestas previamente procesadas para volver a utilizarlas cuando se reciba una nueva solicitud de idénticas características. De esta manera el tiempo de respuesta total se ve reducido, ya que no es necesario realizar la invocación al servicio porque se tiene almacenada su respuesta. En la Figura 14 se presenta un ejemplo de este patrón. Figura 14 - Patrón Cache. 2.4 Otras Tecnologías En esta sección se describen otras tecnologías relevantes para el contexto de este proyecto y que facilitan la comprensión del resto del documento JMX y Java MBeans Java Management Extensions (JMX) es una API utilizada para monitorear y gestionar los recursos de las aplicaciones Java en tiempo real, permitiendo el control de recursos, como por ejemplo, dispositivos, servicios y por supuesto la propia Java Virtual Machine (JVM). A su vez, esta tecnología permite monitorear y gestionar los recursos de una aplicación de forma remota

22 Los usos típicos de esta API son los siguientes: Hacer cambios en la configuración de una aplicación de forma remota. Extracción y acumulación de datos que permitan un análisis estadístico de la utilización de los recursos o el monitoreo de las aplicaciones. Notificaciones sobre cambios de estado o errores detectados. En JMX, los recursos se gestionan mediante Java MBeans, que son objetos Java similares a los JavaBeans, encargados de representar cada una de las entidades de una aplicación. Estos objetos exponen la información manejable de las entidades, en forma de propiedades y operaciones. Adicionalmente, los MBeans pueden ser cargados o eliminados dinámicamente según sea necesario, lo que brinda una gran flexibilidad. [15] Java Reflection Java Reflection es una API del entorno Java que permite instanciar clases e invocar métodos dinámicamente, posibilitando construir código flexible, que es ensamblado en tiempo de ejecución. Es una característica potente de lenguaje Java, sin la cual protocolos importantes como SOAP y JMX no serían posibles. A través de esta API es posible que una aplicación brinde opciones de extensibilidad, permitiéndole al usuario definir nuevas clases que son instanciadas en tiempo de ejecución por su nombre canónico. 2.5 Plataforma ESB Adaptativa En esta sección se resumen las principales características de la Plataforma ESB Adaptativa propuesta en [1], en la cual se basa este proyecto. En dicha propuesta se presentan soluciones para responder a necesidades de adaptación en una SOA, utilizando las capacidades de mediación de los ESBs. En particular, esta plataforma aborda necesidades de adaptación que surgen debido a la degradación en la calidad de los servicios, a la saturación de servicios y a cambios en los contratos de los servicios Descripción General de la Plataforma ESB Adaptativa La Plataforma ESB Adaptativa hace frente a necesidades de adaptación que se pueden generar en una SOA. Para esto, utiliza las capacidades de mediación de un ESB y construye flujos de adaptación que implementan distintas estrategias de adaptación. Adicionalmente, la plataforma selecciona y aplica dichas estrategias de forma automática, dinámica y en tiempo de ejecución. Por lo tanto, la plataforma es capaz de reaccionar automáticamente sin ninguna intervención humana frente a cambios inesperados, aplicando acciones de adaptación dinámicas, que se realizan en tiempo de ejecución y no requieren de ningún cambio en la implementación de la plataforma

23 En la plataforma propuesta se considera una SOA donde los servicios son provistos a través de un ESB, utilizando el patrón de Servicios Virtuales (Sección ). La Figura 15 presenta la arquitectura general del marco considerado. Figura 15 - Arquitectura General. Extraído de [1]. Los servicios ofrecidos por los proveedores y los Servicios Virtuales están basados en la tecnología de Web Services. Son servicios que se describen mediante WSDL y se invocan enviando mensajes SOAP sobre HTTP. A su vez, se dispone de un Registro de Servicios donde se encuentran registrados todos aquellos servicios pertenecientes al ESB. Para todos aquellos Servicios Virtuales registrados en la plataforma, se evalúa si es necesario realizar algún tipo de adaptación. Cuando se considera necesario realizar acciones de adaptación sobre cierto Servicio Virtual, se interceptan en el ESB todos aquellos mensajes que pretendan invocarlo, y sobre estos mensajes se aplica un flujo de adaptación. Los flujos de adaptación se construyen de forma dinámica, automática y en tiempo de ejecución, cuando se detecta un requerimiento de adaptación, y posteriormente se incluyen en los mensajes interceptados según el patrón Ruteo Basado en Itinerario (Sección ). La plataforma propuesta considera un contexto donde no se tiene el control ni de la infraestructura de los proveedores, ni de la infraestructura de los consumidores. Por lo tanto, las acciones de adaptación se podrán realizar únicamente dentro del ESB. Además, esta plataforma se basa en las capacidades de mediación (transformaciones, ruteo, etc.) del ESB, para efectuar acciones de adaptación sobre los mensajes que se intercambian al invocar a los Servicios Virtuales, logrando así una adaptación a nivel del ESB. La Figura 16 presenta un ejemplo donde se modifica un mensaje SOAP, con el fin de adaptarlo a la nueva interfaz de un Web Service externo

24 Figura 16 - Ejemplo de Adaptación. Extraído de [1]. En función de los requerimientos definidos para cada uno de los Servicios Virtuales registrados (por ejemplo, la cantidad máxima de invocaciones de un servicio por periodo de tiempo), la plataforma puede originar requerimientos de adaptación (por ejemplo, disminuir las solicitudes de un servicio). Los requerimientos de adaptación se generan cuando se detecta algún evento que indique una necesidad de adaptación, a su vez, estos eventos se disparan cuando se detecta que los Servicios Virtuales no satisfacen los requerimientos de servicio establecidos. La Figura 17 detalla los distintos elementos de la plataforma que permiten monitorear las invocaciones de un servicio y detectar si el mismo se encuentra saturado. En caso que un servicio se encuentre saturado, se genera un requerimiento de adaptación para disminuir sus solicitudes. Al originarse este requerimiento de adaptación, la plataforma selecciona alguna estrategia (como por ejemplo, Diferir Pedidos) que permita satisfacer el nuevo requerimiento detectado. Por lo tanto, se deben utilizar los Servicios ESB de adaptación para construir un flujo que implemente la estrategia seleccionada, para finalmente aplicarla. Figura 17 - Esquema General para abordar la saturación de servicios. Extraído de [1]

25 2.5.2 Mecanismos de Adaptación en el ESB En esta sección se presentan las principales características de los mecanismos de adaptación considerados por la plataforma. Los Mecanismos refieren a aquellas funcionalidades brindadas por los ESB (transformación, ruteo, etc.) que permiten realizar algún tipo de adaptación dentro del mismo. En la Tabla 2 se detallan las representaciones gráficas y las características propuestas en [1], para los mecanismos de adaptación considerados por la plataforma. En las siguientes sub-secciones se describen cado uno de estos mecanismos. Mecanismo Representación Gráfica Características Tranformación de Mensajes Lógica de Transformación Cache Máximo tiempo de vida Retardador Tiempo de retardo Ruteo de Mensajes Unificador de Respuestas Lista de Destinarios Servicios ESB destino Lógica de Ruteo Condición de Completitud Algoritmo de Agregación Servicios ESB destino Un mensaje de entrada Varios mensajes salida Tabla 2 - Representaciones Gráficas y Características de los mecanismos de adaptación. Extraído de [1] Transformación de Mensajes El mecanismo de Transformación de Mensajes permite modificar los mensajes que se envían a través del ESB. El mecanismo recibe un mensaje y devuelve otro transformado de acuerdo a una lógica de transformación, la cual puede estar definida por transformaciones XSLT para mensajes XML Ruteo de Mensajes El mecanismo Ruteo de Mensajes es el encargado de determinar el destino de los mismos, y se utiliza cuando existen varios destinos posibles, pero solamente se debe seleccionar uno. Este mecanismo posee además una lógica de ruteo, la cual es responsable de decidir a qué Servicio ESB se envía cada mensaje

26 Algunos ejemplos son: Ruteo Basado en Contenido: Inspecciona el contenido de un mensaje y en base a dicho contenido realiza el ruteo a un Servicio ESB. Ruteo Basado en Contexto: Recibe un mensaje y en base a condiciones del ambiente de ejecución realiza el ruteo a un Servicio ESB. Ruteo para Balanceo de Carga: Tiene como objetivo distribuir la carga de las distintas solicitudes a múltiples Servicios ESB Lista de Destinatarios El mecanismo Lista de Destinarios tiene la responsabilidad de distribuir un mensaje a múltiples Servicios ESB. Este mecanismo recibe un mensaje y genera varios mensajes como salida, uno para cada Servicio ESB destino que se especifique Unificador de Respuestas El mecanismo Unificador de Respuestas recibe varios mensajes, y cuando considera que un conjunto de ellos está completo, consolida su contenido y retorna un único mensaje como respuesta. Algunos ejemplos de condiciones de completitud son: Wait for All, Time Out y First Bet [1]. Además, es necesario un algoritmo de agregación que especifique cómo se combina el contenido de los distintos mensajes que conforman un conjunto. Algunos ejemplos de estos algoritmos son: Select the best answer y Condense data [1] Cache El mecanismo Cache recibe un mensaje correspondiente a una solicitud y en caso de poseer un almacenamiento previo de la respuesta, la retorna. Se debe especificar el tiempo máximo de vida de las respuestas almacenadas Retardador El mecanismo Retardador recibe un mensaje y posterga su entrega por un determinado período de tiempo. Se debe especificar el tiempo de demora en la entrega del mensaje Flujos de Adaptación en el ESB Los mecanismos de adaptación descriptos anteriormente se pueden combinar para formar flujos de adaptación. Estos flujos permiten realizar varias operaciones de mediación sobre los mensajes que se envían a través del ESB. Los flujos están conformados por Servicios ESB, por lo que para utilizar un mecanismo de adaptación en un flujo de mediación, es necesario crear un Servicio ESB que aplique dicho mecanismo. La Figura 18 muestra un ejemplo de un flujo de adaptación que es aplicado cuando una aplicación cliente invoca a un Web Service a partir del ESB

27 Figura 18 - Ejemplo de flujo de adaptación. Extraído de [1]. YAWL es el lenguaje elegido en [1] para especificar y representar gráficamente los flujos de mediación de la plataforma. YAWL (Yet Another Workflow Language) [16] es un lenguaje de Workflow que fue desarrollado tomando como base las redes Petri y un conjunto de patrones de Workflow ampliamente extendido. La Tabla 3 presenta los elementos que se utilizan para representar gráficamente los flujos de adaptación. Elemento Representación Gráfica Descripción Condición de Entrada Representa el inicio de un flujo de red YAWL. Condición de Salida Servicio Virtual Tarea atómica AND-split XOR-split XOR-join Representa el fin de un flujo de red YAWL. Representa un Servicio Virtual presente en la plataforma. Representa una tarea atómica con un único flujo de entrada y un único flujo de salida. Cuando existe más de un flujo de salida para la tarea, el AND-split se utiliza para especificar que se activan todos los flujos. Cuando existe más de un flujo de salida para la tarea, el XOR-split se utiliza para especificar que únicamente se activa un flujo. Cuando existe más de un flujo de entrada para la tarea, el XOR-join se utiliza para especificar que se espera por un único flujo para comenzar la tarea. Tabla 3 - Representación gráfica de los elementos de un flujo. Extraído de [1]

28 A modo de ejemplo, la Figura 19 muestra una red YAWL que representa el flujo de adaptación de la Figura 18, donde se utilizan Servicios ESB que aplican dos mecanismos de adaptación (Retardador y Transformación de mensajes), para finalmente invocar a un Servicio Virtual. Figura 19 - Representación de un flujo de adaptación con YAWL. Extraído de [1] Estrategias de Adaptación En esta sección se detallan las estrategias de adaptación definidas en [1], que son más relevantes en el contexto de este proyecto. Concretamente, se presentan estrategias para abordar las siguientes necesidades: Degradación en la calidad de los servicios: En el contexto de la plataforma, la degradación en la calidad de servicio refiere a la degradación de las propiedades de tiempo de respuesta y porcentaje de respuestas exitosas. La degradación de la calidad se puede detectar en base a la información de las invocaciones de los servicios y de sus requerimientos. Saturación de servicios: En el contexto de la plataforma, la saturación de servicio refiere a aquella situación en la cual un servicio recibe más invocaciones de las que puede procesar un determinado periodo de tiempo. Al igual que la degradación de calidad, la saturación se detecta a partir de la información de las invocaciones a los servicios y de sus requerimientos. Cambios en los contratos de los servicios: En el contexto de la plataforma, el cambio de contrato refiere a la modificación del WSDL de un servicio. Esta necesidad, se puede detectar tanto monitoreando el contrato del servicio, así como también recibiendo una notificación por parte del servicio. A continuación se describen las estrategias de adaptación más relevantes para este proyecto, que permiten hacer frente a las necesidades de adaptación presentadas anteriormente. En el Apéndice 1, se describen con más detalles cada una de estas estrategias. Invocar Servicio Equivalente Esta estrategia consiste en invocar un servicio equivalente para un Servicio Virtual que requiera una necesidad de adaptación. Concretamente, esta estrategia permite abordar las siguientes necesidades: Degradación de Calidad y Cambio de Contrato de un Servicio. Distribuir Solicitud a Servicios Equivalentes Esta estrategia consiste en enviar una solicitud a varios servicios, que sean equivalentes al Servicio Virtual original, para luego responder a la aplicación cliente a partir de la primera respuesta obtenida. En particular, esta estrategia permite abordar la Degradación de Calidad de un Servicio

29 Balancear Carga Esta estrategia permite distribuir uniformemente las diferentes solicitudes a un Servicio Virtual entre sus servicios equivalentes. Con respecto a las necesidades de adaptación, esta estrategia permite abordar la Saturación de un Servicio. Utilizar Información Almacenada Esta estrategia utiliza información almacenada en invocaciones previas de un servicio, generando una respuesta sin la necesidad de invocar directamente al Servicio Virtual. Específicamente, esta estrategia permite abordar las siguientes necesidades de adaptación: Degradación de Calidad, Saturación de un Servicio y Cambio de Contrato de un Servicio Diferir Pedidos Esta estrategia recibe un mensaje y posterga su entrega por un determinado período de tiempo. En los que refiere a las necesidades de adaptación, esta estrategia permite abordar la Saturación de un Servicio. Modificar Solicitud y Respuesta Esta estrategia tiene la capacidad de modificar tanto un mensaje de solicitud a un Servicio Virtual, así como también su respuesta. Específicamente, esta estrategia aborda la necesidad de adaptación de Cambio de Contrato de un Servicio. A modo de resumen, en la Figura 20 se exponen todos los mecanismos, eventos, requerimientos y estrategias, que fueron identificados en [1] para hacer frente a las necesidades de adaptación consideradas en el marco de la plataforma anteriormente descripta

30 Figura 20 - Esquema General para abordar las distintas necesidades de adaptación Arquitectura y Esquema General de la Plataforma La Figura 21 presenta la arquitectura general de la solución propuesta en [1], en la cual se exhibe un Motor de Adaptación y Monitoreo y los componentes internos del ESB que fueron diseñados específicamente para hacer frente a las necesidades de adaptación (Gateway de Adaptación, Servicios de Adaptación, Administrador de Adaptación, Administrador de Monitoreo, Administrador de Capacidades y Administrador de Requerimientos de Servicios). Además, se visualizan otros componentes que comúnmente están presentes en un ESB y son relevantes para la plataforma (Registro de Servicios, Mecanismos de Monitoreo y Mecanismos de Adaptación), así como también las principales interacciones y flujos de información existentes entre los principales componentes

31 Figura 21 - Arquitectura General de la Plataforma. Extraído de [1]. Los elementos exhibidos en la Figura 20 junto con los componentes de la arquitectura presentada anteriormente, permiten a la plataforma generar adaptaciones de forma dinámica, automática y en tiempo de ejecución, logrando así abordar las distintas necesidades de adaptación descriptas en la Sección

32 - 32 -

33 3 Selección del Producto ESB En este capítulo se analizan las distintas alternativas de productos ESB existentes en el mercado, a fin de seleccionar el producto más adecuado para el contexto del proyecto. En la Sección 3.1 se presenta un relevamiento de los productos JBoss ESB, Mule ESB, Apache Synapse, OpenESB y Apache ServiceMix, detallando para cada uno de ellos sus principales características. En la Sección 3.2 se introducen distintos criterios de evaluación de acuerdo a las necesidades del proyecto. La Sección 3.3 presenta la evaluación de los distintos productos ESB considerados, mientras que en la Sección 3.4 se selecciona el producto JBoss ESB con el cual se realiza la implementación de la Plataforma ESB Adaptativa. Finalmente, en la Sección 3.5 se presentan las características particulares con las que cuenta JBoss ESB. 3.1 Productos ESB analizados La creciente cantidad de sistemas y aplicaciones heterogéneas que deben comunicarse entre sí de manera interna dentro de una organización, o externa entre distintas organizaciones, genera un gran desarrollo de los productos de integración como lo son los ESBs. Hoy en día, las tecnologías Open Source ofrecen una gran competencia, y en el área de los productos de integración, los desarrollados en tecnologías como Java, están a la altura de los mejores productos comerciales. [17] A continuación se presenta una introducción de cada uno de los productos ESB analizados en el marco de este proyecto, desarrollados sobre la plataforma Java y con licencia Open Source, los cuales fueron seleccionados de acuerdo a su documentación y a la información recabada en [18] y [19] JBoss ESB Es común que JBoss cuente con productos maduros en sus versiones de JBoss Application Server y por lo general estos cuentan con todas las características de la versión comercial, ya que ésta solamente agrega la posibilidad de acceder a servicios de soporte. El producto JBoss ESB 6 no es la excepción, siendo un producto de gran madurez que aprovecha las tecnologías ya desarrolladas por la comunidad, como el motor de reglas de negocio para el ruteo de mensajes basado en contenido. Además, es posible ejecutar una instancia del ESB sobre el servidor de aplicaciones de JBoss integrado con otras aplicaciones JavaEE Mule ESB Mule ESB es uno de los productos de integración Open Source más utilizados por las compañías alrededor del mundo. Su flexibilidad de configuración lo hizo muy popular entre las demás alternativas, siendo posible diseñar flujos de integración complejos en pocos minutos. Otra de las características de Mule ESB 7 es su gran variedad de opciones para transformaciones, conectividad y ruteos, los cuales pueden ser fácilmente reutilizados

34 3.1.3 Apache Synapse Apache Synapse 8 está posicionado como uno de los productos ESB más livianos del mercado, el cual cuenta con soporte para las funcionalidades esenciales. A su vez, su utilización es simple, debido a su facilidad de configuración a partir de archivos XML. Adicionalmente, su diseño se enfocó para tener muy buena performance, y dadas sus características, resulta un muy buen producto para ser utilizado como mediador de sistemas Web OpenESB OpenESB 9 tiene una curva de aprendizaje moderada, gracias su sólida integración con el servidor de aplicación GlassFish y el popular IDE Netbeans, el cual brinda soporte para la administración y desarrollo de aplicaciones que utilizan OpenESB. Por ser un producto de Sun (Oracle) tiene muchos adeptos que lo consideran uno de los productos más competitivos. Cabe resaltar que en la fecha en que se realizó este relevamiento, su foro, tracker y releases no se encontraban en actividad, por lo cual la opción de seleccionar dicho producto se vio comprometida, debido a su poca actividad y documentación Apache ServiceMix Apache ServiceMix 10 se base en OSGi [20] y es una muy buena opción para la interacción basada en estándares XML. Con Apache ServiceMix es muy sencillo integrar nuevos flujos en tiempo de ejecución, pudiendo integrar nuevos componentes sin tener la necesidad de reiniciar los demás servicios del producto. Camel es una distribución de este ESB, el cual posee un gran soporte para los patrones ESB descriptos en la Sección 2.3. Adicionalmente, esta distribución brinda la posibilidad de ser integrado con el Framework Spring. En la siguiente sección se analiza cada uno de los productos ESB presentados, evaluando sus características y brindando una visión objetiva de cada uno de ellos. Además, en el Apéndice 2 se presenta información específica y detallada de cada uno de estos productos. 3.2 Criterios de evaluación. En esta sección se presentan y analizan las diferentes características que resultan relevantes en el contexto de este proyecto. En general, las características más anheladas refieren a requerimientos como usabilidad, confiabilidad y performance. Sin embargo, aunque se consideran las características mencionadas, se hace foco en aquellas características que faciliten una extensión del producto, valorando por ejemplo la calidad de su documentación

35 En las siguientes sub-secciones se realiza una comparativa de los distintos productos ESB de acuerdo a los criterios estratégicos, funcionales y técnicos presentados en [17], los cuales fueron adaptados y actualizados para el contexto de este proyecto. A continuación se describen cada uno de los criterios mencionados anteriormente. Los criterios estratégicos comprenden aquellas cualidades del producto que si bien no son una limitante para el trabajo a realizar, nos pueden dar una buena pauta de su calidad, utilización por la comunidad JAVA y actividad actual del producto. Los criterios funcionales son aquellos que hacen referencia a las funcionalidades que brinda cada uno de los productos analizados. Dichas funcionalidades serán de gran utilidad al momento de realizar una extensión del producto. En particular, se valorará que el producto provea mecanismos de adaptación y monitoreo nativos, los cuales faciliten la implementación de la Plataforma ESB Adaptativa. Los criterios técnicos abarcan todos aquellos aspectos que refieren a la implementación de bajo de nivel, como por ejemplo los protocolos de mensajería disponibles. Con el fin de comparar cada uno de los productos analizados, se trabaja con cuadros comparativos donde se listan cada una de las características deseables y se mencionan sus correspondientes valores. La gran mayoría de los criterios considerados son estándares y muy nemotécnicos. Sin embargo, para evitar ambigüedades se detallan algunos criterios que podrían generar confusiones. Documentación: Refiere a la calidad de los documentos disponibles, que brindan información relevante acerca del producto, la cual facilita la utilización de sus funcionalidades. Además, se valora en gran medida toda aquella información que facilite una posible extensión del ESB a uno adaptativo. Actividad del Issue-Tracker: Refiere al nivel de actividad presente en la herramienta que utiliza el producto para registrar sus incidentes. Experiencia: Refiere a la suma de la experiencia adquirida por cada uno de los integrantes del grupo, para un determinado producto. Orquestación de Servicios: Este concepto se basa en un modelo centralizado, en el cual las interacciones no se realizan directamente entre los servicios, sino que existe una entidad encargada de definir la lógica de interacción. Tiene como objetivo definir la secuencia de interacción entre servicios, necesaria para realizar los procesos del negocio identificados. Gateway: Refiere a aquellas funcionalidades provistas por el ESB, las cuales permiten de forma nativa implementar el Gateway diseñado en la propuesta del ESB adaptativo

36 Servicio Virtual: Refiere a aquellas funcionalidades provistas por el ESB, las cuales permiten de forma nativa implementar los servicios virtuales diseñados en la Propuesta Adaptativa. JBI: Se distingue entre compatibilidad del ESB con el estándar JBI y su implementación basada en el mismo. Decimos que el ESB es compatible con JBI cuando el estándar es soportado por el producto, y en los casos en que la implementación del producto se basó en JBI, decimos que está basado en JBI Evaluación de los Productos En las siguientes sub-secciones se detallan las características mencionadas en la Sección 3.2 junto con sus correspondientes valores, agrupadas según el criterio y producto al que pertenecen. Los valores de los cuadros comparativos se obtuvieron a la fecha de Junio de Criterios Estratégicos En la Tabla 4 se visualizan los criterios estratégicos considerados y sus respectivos valores para cada uno de los productos ESB analizados. Criterio JBoss ESB Mule ESB Apache Synapse OpenESB ServiceMix Tipo de Licencia LGPL CPAL Apache CDDL Apache Open Source SI SI SI SI SI Comunidad Activa SI SI SI BAJA SI Fecha Última Release Estable 09/04/ /11/ /01/ /01/ /02/2012 Documentación MUY BUENA BUENA REGULAR ESCASA BUENA Actividad en Issue Tracker SI SI SI NO SI Experiencia SI NO NO NO NO Tabla 4 - Comparativa de criterios estratégicos

37 3.3.2 Criterios Funcionales La Tabla 5 muestra los criterios funcionales considerados y sus respectivos valores para cada uno de los productos ESB analizados. Criterio JBoss ESB Mule ESB Apache Synapse OpenESB ServiceMix Ruteo basado en contenido Ruteo basado en itinerario SI SI SI SI SI NO NO NO NO NO Transformaciones XSLT, Smooks XSLT XSLT, Scripting XSLT, TransformXL XSLT, XSLTComponent Orquestación de servicios SI SI SI SI SI Gateway SI SI SI No se encontró información. SI Facilidad para extender comportamientos SI Poca información al respecto SI Poca información al respecto Poca información al respecto Cache NO SI SI No se encontró información SI Servicio Virtual SI SI SI SI SI Unificador de repuestas SI SI SI SI SI Retardo de envió de mensajes NO No se encontró información No se encontró información No se encontró información No se encontró información Funcionalidades de monitoreo JMX Console Mule Management Console Plugins disponibles No se encontró información JMX monitoring Tool, JConsole Tabla 5 - Comparativa de criterios funcionales

38 3.3.3 Criterios Técnicos La Tabla 6 muestra los criterios técnicos considerados y sus respectivos valores para cada uno de los productos ESB analizados. Criterio JBoss ESB Mule ESB Apache Synapse OpenESB ServiceMix IDE Gráfico SI SI SI SI SI Servidores Web soportados JBoss Final Geronimo, JBoss, WebLogic, WebSphere, Tomcat Tomcat, Fullfeatured J2EE AS Glassfish JBossAS Apache Geronimo JBOSS JonAS Compatibilidad estándar JBI SI SI NO SI SI Basado en estándar JBI NO NO NO SI SI Conector JDBC SI SI SI SI SI Conector transporte JMS SI SI SI SI SI Conector transporte HTTP Conector transporte de ficheros SI SI SI SI SI SI SI SI SI SI Conector transporte FTP SI SI SI SI SI Conector transporte TCP SI SI SI SI SI Soporte estándares de Servicios Web (WS-*) SI SI SI SI SI Estándares soportados WS-Security, WSDL 1.1, JAX-WS, WS- Addressing WSDL 1.1, WS Addressing, WS Security, WS Policy, WS Reliable Messaging, WS SecureConversation, WS SecurityPolic, WS Trust, etc. WS-Addressing, Web Services Security (WSS), Web Services Reliable Messaging (WSRM) No se encontró documentación online disponible WS-Security Tabla 6 - Comparativa de criterios técnicos

39 3.4 Selección del Producto ESB En este capítulo se realizó un análisis comparativo de los productos ESB Open Source con mayor difusión en el mercado. La comparativa se basó en tres niveles: a nivel de criterios estratégicos, a nivel de funcionalidad brindada por los productos ESB analizados y por último a nivel técnico. En particular, se analizaron las funcionalidades brindadas por estos productos ESB que faciliten la implementación de un ESB Adaptativo, de acuerdo a los requerimientos de adaptación de la plataforma. Con respecto a la implementación de los componentes requeridos por la Plataforma ESB Adaptativa, se analizaron posibles implementaciones de los componentes primordiales, según la documentación de cada producto. En particular, se analizó la implementación de Servicios Virtuales, Gateway de Adaptación, Monitoreo de la mensajería y la posibilidad de crear los diferentes Administradores de la plataforma. Se determinó que si bien en general los productos ESB analizados brindan un soporte adecuado para la implementación de la plataforma, algunos componentes se pueden implementar de forma más directa que otros. Además, en algunos casos, el costo de implementación depende en gran medida del producto ESB específico que se utilice. En una primera instancia del proceso de selección se descartó el producto Open ESB, ya que al momento de realizada esta investigación no contaba con una buena documentación, y presentaba bajos niveles de actividad. Posteriormente, la investigación se enfocó en identificar aquellos productos que cuenten con la mejor documentación, para la implementación de los componentes más críticos de la plataforma adaptativa. Entre los más destacados, se encontraban JBoss ESB, Mule ESB y ServiceMix, por lo cual la última decisión quedó determinada por la experiencia del grupo en plataformas JBoss. Finalmente, se decidió seleccionar JBoss ESB como producto base para la implementación de la plataforma, destacando la facilidad con la que puede ser extendido, además de la gran comunidad activa que posee. Adicionalmente, el producto JBoss ESB brinda un soporte adecuado para implementar los Servicios Virtuales, Gateway de Adaptación y la posibilidad de implementar fácilmente el patrón Ruteo Basado en Itinerario, utilizando el componente Service Invoker que se describe en la Sección De aquí en más, cuando se mencione JBoss ESB nos referiremos a su última versión estable (v4.11) a la fecha de Junio del JBoss ESB Esta sección presenta un breve resumen de las características técnicas particulares de JBoss ESB, en la cual se basa la implementación de la Plataforma ESB Adaptativa. En la sub-sección se presenta una descripción general de las tecnologías y el framework de la plataforma JBoss Enterprise SOA Platform, mientras que la sub-sección describe cada uno de los componentes de JBoss ESB que fueron utilizados y extendidos para implementar la Plataforma ESB Adaptativa

40 3.5.1 Descripción General JBoss Enterprise SOA Platform es una plataforma certificada, probada y con soporte para el desarrollo de soluciones de Arquitectura Orientada a Servicios, desarrollada por la empresa Red Hat. La plataforma JBoss Enterprise SOA Platform integra varios framework y tecnologías como por ejemplo Hibernate, Seam, JBoss Transactions, JBoss Clustering, JBoss Application Server, JBoss Enterprise Service Bus (ESB) y JBoss jbpm entre otros, para proveer una infraestructura que permita integrar aplicaciones empresariales basadas en SOA. Los productos antes mencionados son desarrollados por comunidades y han sido combinados y evaluados para proveer una plataforma sólida, robusta y escalable. Red Hat define a su plataforma como simple, abierta y asequible. Asequible porque los costos de licencia son gratuitos, los costos al cliente vienen del mantenimiento, servicio y soporte provisto por JBoss. Abierta porque está dentro de lo que se conoce como Open Source o código abierto Componentes de JBoss ESB utilizados en la implementación Esta sección se focaliza en aquellos componentes de JBoss ESB que fueron utilizados y extendidos en la implementación de la plataforma, con el objetivo de que la misma tenga la habilidad de generar y procesar dinámicamente flujos de adaptación, que permitan satisfacer los requerimientos de los Servicios Virtuales registrados en la plataforma Definición de Servicios en JBoss ESB Un Servicio en JBoss ESB se define como una lista de acciones que procesan los mensajes de manera secuencial y se identifica en el ESB por una categoría y un nombre. Normalmente un implementador descompone la funcionalidad de un servicio en un conjunto de acciones y luego implementa cada una de ellas con clases Java. Esta descomposición no solo permite reutilizar los servicios, sino también las acciones implementadas, ya que las mismas se pueden utilizar en múltiples servicios. Paralelamente, JBoss ESB incluye un conjunto de acciones nativas que proveen funcionalidades de transformación, ruteo y soporte a Web Services, entre otras. La lista de acciones que componen a un servicio en JBoss ESB se conoce como action pipeline. En la Figura 22 se presenta un ejemplo de configuración de un servicio JBoss ESB, cuya lista de acciones está compuesta por una única acción, la cual tiene la capacidad de escribir en la salida estándar el mensaje SOAP que se haya enviado al ESB

41 Figura 22 - Implementación de Servicios en JBoss ESB. Extraída de [21] Service Invoker En la versión 4.2 de JBoss ESB se introduce la funcionalidad de Service Invoker para facilitar la comunicación entre servicios, no siendo necesario tener en cuenta detalles de bajo nivel como el manejo de las fallas de los servicios. Es por esta razón que dicha funcionalidad se convirtió en la opción recomendada para trabajar con servicios dentro de JBoss ESB. La interfaz de Service Invoker expone un conjunto de métodos los cuales permiten invocar sincrónica y asincrónicamente servicios registrados en la aplicación, indicando solamente la categoría y el nombre con el cual fueron registrados. El transporte utilizado para la invocación de un servicio está determinado por su configuración y su ámbito de definición. A continuación se presenta el mecanismo InVM Transport utilizado por defecto para invocar servicios dentro de la misma Java Virtual Machine (JVM). InVM Transport InVM Transport es una nueva característica que está presente desde la versión 4.3 de JBoss ESB, la cual posibilita la comunicación entre distintos servicios que estén ejecutando en la misma Java Virtual Machine. Esto significa que las instancias de Service Invoker pueden comunicarse con un servicio instanciado dentro de la misma Java Virtual Machine, sin la sobrecarga de la serialización de los mensajes o las comunicaciones por la red. Para que un determinado servicio pueda ser invocado por otro, utilizando el transporte InVM, ambos deben estar ejecutando en la misma JVM y su InVM Scope debe estar definido previamente como GLOBAL. En caso de que el servicio tenga definido el InVM Scope como NONE, no será posible invocar dicho servicio a través del transporte InVM SOAP Proxy El SOAP Proxy se centra en el consumo de un Web Service externo y la re-publicación de dicho extremo a través del ESB. El ESB se localiza entre el consumidor/cliente y el productor/servidor. El propósito de este intermediario es proporcionar una capa de abstracción que proporcione las siguientes ventajas: El cliente no se conecta directamente al servicio remoto

42 El cliente puede ver un WSDL modificado, cambiando los parámetros de entrada y de salida. Se pueden introducir acciones de transformaciones sobre los mensajes SOAP, las cuales pueden ser aplicadas tanto a las solicitudes de un servicio como a las respuestas del mismo. Se pueden realizar ruteos complejos basados en el contenido del mensaje a través del componente ContentBasedRouter Gateway Un gateway de aplicación es un componente que se ejecuta en un servidor, el cual es el encargado de interconectar dos redes/nodos. Cuando un cliente establece una conexión con un destino, se conecta a una aplicación de gateway. A partir de ese momento, el cliente interactúa con el gateway con el fin de comunicarse con el servicio destino. Una vez establecida la conexión, el gateway se encargará de elaborar todas las decisiones de forwarding. En el producto JBoss ESB existen varios componentes que permiten exponer un gateway para ser invocado desde otros sistemas. En este proyecto se utilizaron HTTP-Gateway y JBR-Gateway, los cuales permiten exponer de forma nativa un único punto de acceso al ESB. A continuación se describen con mayor detenimiento cada uno de los gateways mencionados anteriormente. Gateway HTTP Este Gateway utiliza la suite JBoss ESB y su conector de aplicación HTTP, para exponer end-points. Debido a la utilización de este conector, muchas de sus configuraciones dependen en gran nivel del contenedor (bind/port, SSL, etc.). Este componente permite definir patrones de URLs, los cuales serán utilizados al momento de interceptar los mensajes SOAP que llegan al ESB. A modo de ejemplo, la Figura 23 presenta una configuración donde se expone un end-point HTTP para un servicio con categoría Vehicles y nombre Cars. Esta configuración permite interceptar todas aquellas peticiones que llegan al ESB y coincidan con la URL Figura 23 - Configuración de patrones de URL

43 La propiedad allowedports de este componente permite limitar un servicio a un puerto específico o a un conjunto de ellos. Esto se especifica enumerando una lista de puertos deseados, como se presenta en la Figura 24. Figura 24 - Configuración de restricciones de puertos. La configuración realizada en la figura anterior expone un end-point HTTP para un servicio que intercepta todas aquellas peticiones realizadas sobre los puertos 8080 y En caso de acceder a puertos que no sean los especificados anteriormente retornara un código de error HTTP (404). Gateway JBR El protocolo JBoss Remoting 12 se puede utilizar como una opción de transporte en JBoss ESB. Este servicio se apoya en el protocolo HTTP(S) y Socket (+SSL) a través de JBR. A modo de ejemplo, la Figura 25 presenta una configuración básica de este componente. Figura 25 - Configuración de jbr-provider. La configuración del jbr-provider y del jbr-bus es muy simple, para el jbr-provider basta especificar el protocolo y el host que se desea utilizar, mientras que para el jbr-bus solamente se debe especificar el puerto donde atenderá. En la Figura 26 se presenta un ejemplo de como referenciar un jbr-bus a través de un jbr-listener, para exponer un servicio como Gateway. Figura 26 - Configuración del jbr-listener. El JBR-Gateway posee un gran número de propiedades que pueden ser configuradas para el jbr-listener, jbr-bus y jbr-provider. A continuación, la Tabla 7 presenta las principales propiedades y sus valores por defecto

44 Nombre Descripción Valor por defecto synchronous Servicio destino se invoca de forma sincrónica True serviceinvokertimeout Tiempo de espera de llamada asincrónica asyncresponse Respuesta asincrónica. <ack/> securityns Este es el espacio de nombres para la versión de seguridad de servicios Web que se debe utilizar http-wss-wssecurity-secext-1.0.xsd Tabla 7 - Propiedades configurables del JBR Gateway Unificador de Mensajes (Aggregator) El Aggregator es un filtro especial que recibe un flujo de mensajes e identifica aquellos mensajes que están correlacionados. Una vez que un conjunto completo de mensajes ha sido recibido, el Aggregator recoge información de cada mensaje correlacionado y genera un único mensaje, agregándolo al canal de salida para su posterior procesamiento Monitoreo y Administración de Servicios En JBoss ESB existe una serie de opciones para el seguimiento y la administración de los servicios que se encuentran dentro del servidor JBoss. En particular este producto proporciona una serie de MBeans que exponen información acerca de sus recursos en forma de propiedades y operaciones, las cuales permiten a los administradores supervisar el rendimiento de su servidor. Dentro de la consola JMX del servidor JBoss existe un dominio jboss.esb que contiene los MBeans que se muestran a continuación: deployment: Dentro de deployment se puede visualizar el estado de todos los paquetes de ESB que se han desplegado dentro del servidor, así como también obtener información acerca de la configuración y su estado actual. listener-name: Dentro de esta opción se visualizan todos los listeners desplegados en el servidor, detallando información acerca de su configuración, el tiempo de inicio, máxima cantidad de hilos, estado, etc. El administrador tiene la opción de inicializar, parar y destruir un listener. MessageCounter: Los contadores de mensajes agrupan todos los servicios desplegados en el ESB, brindando información acerca de la cantidad de mensajes procesados, el tiempo de procesamiento de cada uno de ellos, etc. service-name: Muestra estadísticas de un servicio, como por ejemplo el número de mensajes, el estado, el tamaño promedio de mensaje, el tiempo de procesamiento, etc. Además, el número total de mensajes puede ser reseteado y los servicios pueden ser detenidos y reiniciados

45 Servicios Cada uno de los servicios registrados en el ESB puede ser visualizado en la consola de administración JMX, donde se detalla por acción el tiempo de procesamiento, cantidad de mensajes procesados, cantidad de mensajes fallidos, y un contador general de mensajes por servicio Contador de Mensajes (MessageCounter) La consola de administración JMX también proporciona un contador general de mensajes, el cual se encarga de contar todos aquellos mensajes que pasan a través del ESB. El Message-Counter mantiene un registro de la cantidad de mensajes exitosos y fallidos, así como también la fecha y la hora de los mismos Transformaciones Para cada transformación Smooks que está registrada en el ESB, existe un MBean que mantiene su información, conteniendo este registro el tiempo de procesamiento de cada una de ellas y un recuento total de la cadena de transformación. Toda esta información puede ser visualizada desde la consola de administración JMX Servicio de Mensajes Descartados (DeadLetterService) El servicio DeadLetterService (DLQ) se puede utilizar para almacenar aquellos mensajes que no pueden ser entregados. Este es un servicio de JBoss ESB y por lo tanto estos mensajes pueden ser controlados e inspeccionados. Cabe resaltar, que el DLQ no se utiliza si el transporte tiene soporte nativo, como por ejemplo JMS Alertas Esta funcionalidad es utilizada para recibir alertas de eventos relacionados con el ESB, como por ejemplo cuando el contador de DeadLetterService llega a un umbral determinado. Para habilitar estas alertas se debe configurar el archivo de monitoreo de JBoss ESB (monitoring-service.xml). Cabe resaltar que solamente se notifica una sola vez por ocurrencia de alerta, y para volver a ser notificado de una alerta se debe invocar a la funcionalidad de reinicio que brinda el propio servicio

46 - 46 -

47 4 Solución Propuesta En este capítulo se describen las principales características de la plataforma implementada, presentando en la Sección 4.1 una descripción conceptual de la solución, y especificando en la Sección 4.2 el esquema general de su arquitectura, la cual se basa en la solución propuesta en [1]. Conjuntamente, en la Sección 4.3 se describen los distintos componentes de la plataforma, y cómo éstos se implementaron en JBoss ESB. En la Sección 4.4 se describen las principales interacciones que se dan en tiempo de ejecución entre los componentes, ESB Adaptativo, Consola de Administración y Motor de Adaptación y Monitoreo. La Sección 4.5 presenta las distintas opciones de extensibilidad que posee cada uno de estos componentes. Finalmente, en la Sección 4.6 se describen las principales limitaciones y posibles mejoras de cada uno de los grandes componentes con los que cuenta esta plataforma. 4.1 Descripción Conceptual En esta sección se presenta una descripción conceptual de la solución desarrollada en este proyecto, la cual implementa la plataforma propuesta en [1], basándose en las capacidades de mediación del producto JBoss ESB. La Figura 27 permite distinguir entre aquellos componentes nativos de JBoss ESB y aquellos que fueron extendidos o implementados específicamente para hacer frente a los requerimientos de la plataforma. Figura 27 - Descripción conceptual de la Arquitectura

48 La plataforma implementada extiende las funcionalidades brindadas por JBoss ESB para poder abordar de forma dinámica, automática y en tiempo las distintas necesidades de adaptación que pueden surgir en una SOA. JBoss ESB provee de forma nativa soluciones que permiten, interceptar los mensajes que llegan al ESB (Gateway HTTP y JBR) e invocar tanto servicios externos (SOAPProxy), como servicios internos (Service Invoker). Además, se identifica un conjunto de funcionalidades nativas de JBoss ESB que debieron ser extendidas con el fin de variar su comportamiento en tiempo de ejecución. Un ejemplo de este tipo de funcionalidades es la acción que aplica transformaciones XSLT, que debió ser modificada para soportar la definición de transformaciones en tiempo de ejecución. Por otra parte, algunas funcionalidades como el Cache y el Ruteo Basado en Itinerario debieron ser implementadas completamente, ya que JBoss ESB no las implementa de forma nativa. Completando la Plataforma ESB Adaptativa y desacoplados de la implementación del ESB Adaptativo, se encuentran la Consola de Administración y el Motor de Administración y Monitoreo, que brindan las funcionalidades restantes para poder realizar el ciclo completo de configuración, monitoreo y adaptación de los servicios registrados en la plataforma. 4.2 Arquitectura General En esta sección se presenta la arquitectura lógica de la Plataforma ESB Adaptativa, detallando cada uno de los componentes que la conforman. La Plataforma ESB Adaptiva está compuesta por los siguientes componentes: ESB Adaptativo: está basado en componentes internos de JBoss ESB y en otros componentes diseñados específicamente para posibilitar el monitoreo y las adaptaciones en el ESB, de forma dinámica, automática y en tiempo de ejecución. Motor de Adaptación y Monitoreo: este componente está diseñado con el objetivo de brindar soporte a la toma de decisiones de adaptación y monitoreo en la plataforma, notificando al ESB Adaptativo en aquellos casos que considere necesario. Consola de Administración: este componente está diseñado para la administración y el monitoreo de la Plataforma ESB Adaptativa, con el objetivo principal de configurar y visualizar los Servicios Virtuales registrados. La Figura 28 presenta la arquitectura general de la plataforma, donde se puede visualizar cada uno de sus componentes, sus principales interacciones y los flujos de información más destacados. Además, se distingue entre los nuevos componentes de la plataforma y aquellos componentes internos de JBoss ESB que fueron personalizados

49 Figura 28 - Componentes de la Plataforma ESB Adaptativa. La arquitectura propuesta está determinada principalmente por los siguientes requerimientos: Los procesos de adaptación no deben deteriorar la performance del sistema. La plataforma debe contar con puntos de extensión que permitan agregar fácilmente nuevas funcionalidades a las ya implementadas. La plataforma debe permitir la ejecución distribuida de cada uno de sus principales componentes, permitiendo que la misma posea alta disponibilidad y escalabilidad. Configurar y administrar fácilmente cada uno de los servicios virtuales registrados en la plataforma. Al igual que en [1], los principales componentes de la plataforma son el ESB Adaptativo (compuesto por Gateway de Adaptación, Servicios ESB, Administrador de Adaptación, Administrador de Monitoreo, Administrador de Requerimientos de Servicios y Mecanismos de Adaptación y Monitoreo) y el Motor de Adaptación y Monitoreo. En el marco de este proyecto se decidió añadir a esta arquitectura un nuevo componente denominado Consola de Administración que se detalla en la Sección

50 El ESB Adaptativo es el principal componente en esta arquitectura, y es en donde se aplican composiciones de servicios que se denominan flujos de adaptación, los cuales se seleccionan en tiempo de ejecución para cada uno de los servicios registrados en la plataforma. Paralelamente, dicho componente permite monitorear propiedades acerca de la calidad, saturación y el contrato de los servicios virtuales. 4.3 Principales Componentes En las siguientes sub-secciones se describen los principales componentes de la Plataforma ESB Adaptativa, detallando las responsabilidades definidas en [1] para cada uno de ellos, y destacando aquellos componentes de JBoss ESB que permitieron su implementación. Adicionalmente, se presentan todas aquellas funcionalidades que no fueron consideradas en [1] pero están disponibles en la plataforma implementada Servicios ESB Como se especifica en [1], existen dos tipos de Servicios ESB en la plataforma, los Servicios Virtuales y los Servicios de Adaptación. Cada Servicio Virtual se encarga de acceder a un Web Service externo de acuerdo al patrón Servicio Proxy Simple detallado en la Sección Por otro lado, los Servicios de Adaptación aplican mecanismos de adaptación (como por ejemplo trasformaciones y ruteos) que permiten realizar acciones de adaptación en el ESB. La Figura 29 presenta gráficamente los distintos Servicios ESB con los que cuenta la Plataforma ESB Adaptativa. Figura 29 - Servicios ESB de la Plataforma ESB Adaptativa. En cuanto a la implementación de este componente, se utilizó la forma estándar de definir servicios en JBoss ESB, que consisten en especificar una serie de acciones que se encargan de procesar los mensajes de manera secuencial

51 Servicios de Adaptación Estos servicios utilizan los mecanismos de adaptación para poder realizar las distintas acciones de adaptación que se contemplan en la plataforma. JBoss ESB soporta de forma nativa varios de los mecanismos de adaptación descriptos en la Sección 2.5.2, salvo excepciones como el cache y el retardador de mensajes. Sin embargo, se realizaron modificaciones sobre la gran mayoría de dichos mecanismos, con el fin de obtener los datos de cada mensaje de forma dinámica a partir de su itinerario adjunto, permitiendo que cada mecanismo pueda variar su comportamiento en tiempo de ejecución. En la Tabla 8 se presentan los servicios básicos con los que cuenta la plataforma implementada, para los cuales se detalla su nombre, descripción y el mecanismo utilizado en su acción de adaptación. Nombre Descripción Mecanismo TRN RUT LST UNI CCH RET Servicio encargado de aplicar la transformación que se encuentra en el itinerario del mensaje. Servicio encargado de realizar el ruteo de un mensaje según cierta lógica que se encuentra adjunta al mensaje. Servicio encargado de distribuir un mensaje a un conjunto de servicios. Servicio encargado de unificar las respuestas entre los servicios que distribuye el LST. Servicio encargado de retornar respuestas previamente almacenadas. Servicio encargado de retardar la entrega de un mensaje por cierto período de tiempo. Transformación Ruteo intermediario Lista de destinatarios Unificador de respuestas Cache Retardador Tabla 8 - Servicios de Adaptación base de la plataforma. En la plataforma implementada se manejan dos acciones de adaptación por servicio, la primera acción es la encargada de realizar la adaptación, mientras que la segunda es la encargada de guiar el mensaje según el patrón Ruteo Basado en Itinerario. A modo de ejemplo, la Figura 30 muestra como está estructurado el servicio TRN, donde se visualiza que el servicio está compuesto por dos acciones. La primera, es la encargada de realizar la adaptación, en este caso una transformación, mientras que la segunda dirige el mensaje hacia el próximo servicio, tal como lo especifica el itinerario adjunto al mensaje

52 Figura 30 - Configuración del servicio TRN en JBoss ESB Servicios Virtuales Para poder implementar Servicios Virtuales es necesario disponer de algún mecanismo que posibilite consumir Web Services externos y además permita re-publicarlos. El producto JBoss ESB brinda distintos conectores tanto para consumir Web Services externos como para exponerlos, tales como SOAPProcessor, SOAPClient y SOAPProxy. En particular, la acción SOAPProxy permite consumir un Web Service externo y re-publicarlo de manera interna en JBoss ESB, por lo que se decidió utilizarla para implementar los Servicios Virtuales de la Plataforma ESB Adaptativa. A modo de ejemplo, la Figura 31 presenta el archivo de configuración que permite implementar un servicio virtual en JBoss ESB, utilizando la acción SOAPProxy. Figura 31 - Implementación de un Servicio Virtual utilizando SOAPProxy. En el ejemplo presentado se define un Servicio Virtual que se identifica con la categoría egov y el nombre BPSWSProxy. El servicio definido realiza la invocación a un Web Service externo que se encuentra publicado donde lo específica el WSDL determinado por la propiedad wsdl. Tal como se describió en la Sección , el transporte InVM es el que se utiliza desde la Plataforma ESB Adaptativa para invocar a este servicio. Esto es posible ya que el servicio está definido con InVM Scope

53 GLOBAL y ejecuta en la misma JVM. Además, esta configuración permite que los servicios virtuales se encuentren en diferentes proyectos ESB Mecanismos de Adaptación Como se especifica en [1], los Mecanismos de Adaptación (transformaciones, ruteo, etc.) permiten aplicar acciones de adaptación sobre los mensajes interceptados en el ESB Adaptativo, colaborando con el objetivo principal de la plataforma de generar adaptaciones dinámicas, automáticas y en tiempo de ejecución. Estos mecanismos se implementan en la plataforma utilizando las acciones genéricas brindadas por JBoss ESB, las cuales poseen un método encargado de procesar cada mensaje que llega al servicio donde fue definida dicha acción. Es en este método donde se define toda la lógica necesaria para realizar las adaptaciones sobre los mensajes. La Tabla 9 presenta los mecanismos con los que cuenta la plataforma implementada, para los cuales se detallan sus características y/o propiedades adicionales. Nombre del Mecanismo Característica/Propiedad Adicional Transformaciones Lógica de transformación Ruteo intermediario Lógica de ruteo Servicios ESB destino Lista de destinatarios Servicios ESB destinos Unificador de respuestas Condición de Completitud (mejor respuesta) Algoritmo de Agregación Cache Máximo tiempo de almacenamiento Retardador Tiempo de retardo Tabla 9 - Características y/o propiedades de los mecanismo de adaptación. El producto JBoss ESB brinda acciones que permiten implementar de manera directa transformaciones, ruteos, lista de destinatarios y unificador de respuesta. Sin embargo, estas acciones no permiten en tiempo de ejecución variar sus características y propiedades. Por esta razón, se debieron implementar nuevas acciones que permitan obtener en tiempo de ejecución la información adjunta que posee cada mensaje. Adicionalmente, se crearon dos nuevas acciones que permiten implementar el mecanismo de cache y el retardador de mensajes, ya que JBoss ESB no provee soporte nativo para estas funcionalidades. Cada una de los mecanismos implementados en la plataforma se detalla en la Sección 5.1, presentando en aquellos casos que corresponda, las acciones de JBoss ESB en la cual se basó la implementación

54 4.3.3 Mecanismos de Monitoreo Los Mecanismos de Monitoreo son componentes relevantes para la Plataforma ESB Adaptativa, ya que implementan funcionalidades de monitoreo que se encargan de obtener información de los distintos Servicios Virtuales de la plataforma. Concretamente, la plataforma implementada cuenta con dos tipos de mecanismos de monitoreo: monitoreo de las invocaciones a servicios virtuales, y monitoreo de los contratos de los Web Services externos. Estos mecanismos pueden obtener por ejemplo, el tiempo de respuesta, la cantidad de invocaciones y datos relevantes del contrato de un servicio. Si en algún momento se desea incorporar nuevos mecanismos de monitoreo, las opciones de extensibilidad de la plataforma permiten integrarlos. Las implementaciones de estos mecanismos se basan en simples clases java, que implementan la interfaz IMechanismMonitor definida en la plataforma. Estas clases pueden consumir servicios brindados por agentes externos a la plataforma, los cuales a su vez pueden manejar distintos protocolos para la comunicación, como por ejemplo, HTTP, JMX y JMS, entre otros. La comunicación entre el mecanismo y el servicio externo debe ser resuelta por el propio mecanismo, utilizando las funcionalidades brindadas por JBoss ESB y Java. La Figura 32 presenta gráficamente cómo un mecanismo de monitoreo interactúa con servicios externos a la plataforma, utilizando diferentes protocolos para la comunicación. Figura 32 - Invocación a agentes de monitoreo externos. JBoss ESB posee mecanismos de monitoreo nativos que exponen su información a través de MBeans, los cuales facilitaron la implementación de los mecanismos encargados de monitorear las invocaciones a los Servicios Virtuales. Sin embargo, fue necesario realizar una implementación específica que permita monitorear los contratos de los Web Services externos, ya que el producto no ofrece ninguna funcionalidad específica para este cometido. En la Sección 5.2 se presentan cada uno de los mecanismos de monitoreo implementados, detallando para cada uno de ellos la forma en que monitorean la información Administrador de Adaptación El Administrador de Adaptación, es el componente encargado de gestionar los flujos definidos en las directivas de adaptación de cada Servicio Virtual. Como se especifica en [1], este componente recibe los distintos flujos de adaptación generados por el Motor de Adaptación y Monitoreo, y los alberga durante

55 su tiempo de vida. Paralelamente, cada vez que el Gateway lo solicite, el Administrador de Adaptación le retorna cuál es el flujo de adaptación actual para un determinado servicio. Concretamente, en la plataforma implementada, la comunicación entre el Administrador de Adaptación y el Gateway de Adaptación se realiza mediante la simple interacción de clases Java, pues ambos componentes se encuentran en el ESB Adaptativo. Sin embargo, la comunicación entre el Administrador de Adaptación y el Motor de Adaptación y Monitoreo es un poco más compleja, ya que se utiliza el protocolo de mensajería JMX 13 para el envío de las distintas directivas de adaptación. La implementación de este componente se basa en un HashMap en memoria, el cual asocia identificadores de servicios virtuales con directivas de adaptación. El HashMap guarda en memoria las directivas de adaptación de cada uno de los servicios virtuales. Por lo tanto, a partir del identificador de un servicio virtual es posible obtener rápidamente su directiva de adaptación. A medida que el Motor de Adaptación y Monitoreo genera nuevas directivas de adaptación para un servicio, utiliza la interfaz Java MBean para registrarlas en el ESB Adaptativo. El Administrador de Adaptación almacena para cada servicio la última directiva de adaptación registrada, y cada vez que el Gateway solicita el flujo de adaptación actual de un servicio, este componente verifica si el servicio posee un flujo de adaptación vigente, y en este caso, el flujo es enviado directamente al Gateway. Si el servicio no tiene definido ningún flujo, o el flujo de adaptación actual ya expiró, el Administrador de Adaptación le envía al Gateway un flujo que contiene únicamente el servicio virtual que se desea invocar. En la Figura 33 se ejemplifican las interacciones mencionadas anteriormente. Figura 33 - Interacciones del Administrador de Adaptación. Como funcionalidad adicional de la plataforma implementada, este componente guarda información histórica acerca de los distintos flujos de adaptación que se aplicaron para cada uno de los Servicios Virtuales. Estos datos son útiles para la Consola de Administración, la cual obtiene la información utilizando mensajería JMX y luego la presenta de forma gráfica

56 4.3.5 Administrador de Monitoreo El Administrador de Monitoreo es otro componente de gran relevancia para la plataforma. Se encarga de obtener los valores monitoreados y a partir de ellos, calcular las propiedades que luego envía al Motor de Adaptación y Monitoreo. Las principales responsabilidades identificadas en [1] para este componente son: interactuar con los mecanismos de monitoreo para obtener los datos monitoreados. calcular los valores de las distintas propiedades de la plataforma a partir de los datos monitoreados. enviar al Motor de Adaptación y Monitoreo los valores calculados para las diferentes propiedades monitoreadas. El Administrador de Monitoreo fue desarrollado en el componente ESB Adaptativo como un hilo Java, que cada cierto intervalo de tiempo (configurable) obtiene la lista de servicios virtuales registrados en la plataforma, e invoca a cada uno de los Mecanismos de Monitoreo, para obtener los valores monitoreados de cada servicio. Utilizando dichos datos, calcula y actualiza el valor de las propiedades monitoreadas, las que luego envía al Motor de Adaptación y Monitoreo, utilizando la interfaz Java MBean provista para este fin. La Figura 34 presenta las interacciones que realiza este administrador. Figura 34 - Interacciones del Administrador de Monitoreo. En la Sección 5.3 se detallan los distintos estados con los que cuenta Administrador de Monitoreo y la forma en que se traslada de un estado a otro. La Sección describe las propiedades de monitoreo que fueron implementadas, entre las que se encuentran, el tiempo de respuesta promedio, la cantidad de invocaciones por unidad de tiempo, la cantidad de fallas y los cambios en el contrato de un servicio Administrador de Requerimientos de Servicios El Administrador de Requerimientos de Servicios es el responsable de gestionar todos los requerimientos de los servicios virtuales registrados en la Plataforma ESB Adaptativa. Como se describe en [1], estos requerimientos junto con la información que monitorea la plataforma, permiten detectar aquellas situaciones que generan nuevos requerimientos de adaptación

57 En la plataforma implementada, los requerimientos de los servicios se pueden especificar en base a las propiedades monitoreadas y a sus metadatos. Concretamente, estos requerimientos pueden ser de dos tipos, los simples, que tienen la forma propiedad operador valor, donde se hace referencia al valor de uno de los metadatos de los servicios registrados en la plataforma, y los complejos, que tienen la forma propiedades - objeto, donde las propiedades contienen el conjunto de todas las Propiedades Monitoreadas y el objeto es una instancia de una clase Java que determina si el requerimiento del servicio se cumple o no. La Tabla 10 presenta ejemplos de requerimientos de servicios simples que pueden especificarse para el servicio virtual SRV-3. El primer requerimiento especifica el tiempo de respuesta promedio que no debe sobrepasar este servicio, que en este caso debe ser menor a 1000 ms. Por otra parte, el segundo requerimiento determina que dicho servicio no debe ser invocado más de 100 veces por un período de tiempo (configurable). Requerimiento Servicio Propiedad Operador Valor 1 SRV-3 Tiempo respuesta promedio < 1000ms 2 SRV-3 Cantidad de invocaciones <= 100 Tabla 10 - Ejemplo de Requerimientos de Servicios. Los Requerimientos de Servicio complejos, como el requerimiento de cambio de contrato, se evalúan utilizando clases Java instanciadas e invocadas mediante Java Reflection. Una vez definidos los requerimientos de los servicios virtuales, el Motor de Adaptación y Monitoreo puede solicitar, mediante la utilización de la interfaz Java MBean provista, que este administrador evalúe qué requerimientos no se satisfacen para un determinado servicio. Que un servicio satisfaga un requerimiento, es determinado por las condiciones definidas en cada requerimiento de servicio y por su metadata, la que el Administrador obtiene consultando al Registro de Servicios. En la Figura 35 se describen cada una de las interacciones que posee este administrador, detallando para cada una de ellas el tipo de comunicación. Figura 35 - Interacciones del Administrador de Requerimientos de Servicios

58 En la Sección 5.4 se detalla cómo son registrados los Requerimientos de Servicios (complejos y simples) y cómo éstos son evaluados en tiempo de ejecución Gateway de Adaptación Según lo especificado en [1], este componente debe ser capaz de interceptar todos aquellos mensajes que llegan al ESB y pretenden invocar un servicio virtual. Además de interceptar los mensajes, este componente debe interactuar con el Administrador de Adaptación, para corroborar la existencia de algún flujo de adaptación. Para cada flujo de adaptación vigente, el Gateway realizará dos acciones, una que se encarga de adjuntar el flujo al mensaje y otra que dirige el mensaje hacia el primer servicio del flujo de adaptación. Cabe mencionar que la implementación de este componente utiliza la propiedad wsa:to del estándar WS-Addresing [23], para determinar a que servicio virtual se pretende invocar. En cuanto al producto JBoss ESB, existen varias acciones que permiten implementar de forma nativa el Gateway de Adaptación, como por ejemplo, HTTP-Gateway, JBR-Gateway y UDP-Gateway. En el contexto de este proyecto, se decidió realizar dos implementaciones de este componente utilizando una misma acción, lo cual garantiza que el procesamiento de las dos implementaciones sea idéntico. Para realizar estas implementaciones se utilizaron los componentes HTTP-Gateway y JBR-Gateway de JBoss ESB. En lo que respecta a la implementación que utiliza el listener HTTP-Gateway, se definió un patrón de URL que garantiza un único punto de acceso a la Plataforma ESB Adaptativa, mientras que en la implementación que utiliza el listener JBR-Gateway recibe y procesa las peticiones en un puerto preestablecido. En la Sección 5.5 se brindan más detalles de ambas implementaciones, donde se presenta la configuración particular de cada gateway Registro de Servicios y Configuración Como se detalla en [1], el Registro de Servicios tiene la responsabilidad de administrar la información de los servicios virtuales que se registran en la Plataforma ESB Adaptativa. Además, este componente se encarga de gestionar las transformaciones, que permiten transformar el contenido de un mensaje desde y hacia el modelo de datos canónico. En la plataforma implementada, este componente permite: registrar servicios, asociar y recuperar metadatos, y registrar los servicios equivalentes de cada servicio virtual. La Figura 36, presenta un esquema general de cómo es almacenada la información de los servicios virtuales de la plataforma

59 Figura 36 - Esquema de persistencia de la información almacenada por el Registro de Servicios. Este registro tiene un papel significativo en la plataforma implementada, ya que la información y capacidades que provee son de suma utilidad para varias de las decisiones que deben tomarse. Por ejemplo, solamente se puede aplicar la estrategia Utilizar Información Almacenada sobre aquellos servicios que sean de datos, y es el Registro de Servicios quien conoce ésta información. El Registro de Servicios es utilizado por dos de los grandes componentes de la Plataforma ESB Adaptativa, el componente ESB Adaptativo y la Consola de Administración. El primero solamente consulta la información almacenada, mientras que el segundo utiliza las funcionalidades del Registro de Servicios para brindar una interfaz gráfica, donde el usuario final puede registrar nuevos servicios virtuales, darlos de baja, editar su información y definir servicios equivalentes. De forma similar al producto JBoss ESB, la plataforma implementada brinda un conjunto de archivos XML que permiten su configuración. En la Sección 5.6 se brindan más detalles de la implementación de este componente Motor de Adaptación y Monitoreo El Motor de Adaptación y Monitoreo se encarga de tomar las decisiones de adaptación y de monitoreo en la plataforma. Las responsabilidades definidas en [1] para este componente son las siguientes: detectar cuándo se debe generar un evento monitoreado para un servicio. decidir cuándo se debe generar un requerimiento de adaptación para un servicio. seleccionar una estrategia de adaptación para abordar un requerimiento de adaptación. crear un flujo de adaptación que implemente la estrategia seleccionada, utilizando los mecanismos de adaptación disponibles en el ESB. notificar al Administrador de Adaptación el nuevo flujo de adaptación para un servicio. El Motor de Adaptación y Monitoreo se encuentra lógicamente fuera del ESB Adaptativo, y en la plataforma implementada está compuesto por tres componentes, Administrador de Eventos, Administrador de Requerimientos de Adaptación y Administrador de Estrategias. La comunicación entre

60 estos componentes se realiza mediante interacciones de clases Java, mientras que la comunicación con la plataforma ESB Adaptativa se realiza utilizando las interfaces Java MBean provistas. En las siguientes sub-secciones se describen cada uno de los componentes antes mencionados, y en la sección 5.7 se brindan más detalles de la implementación de cada uno Administrador de Eventos El Administrador de Eventos, es responsable de obtener los requerimientos de servicios que no están siendo satisfechos, consultando para ello al Administrador de Requerimientos. Cuando un requerimiento de servicio no se satisface, este componente dispara un Evento Monitoreado, el cual genera un nuevo Requerimiento de Adaptación. La Tabla 11 presenta y describe cada uno de los Eventos Monitoreados que pueden ser detectados en la configuración base de la plataforma implementada. Evento Monitoreado degradación-tiempo-respuesta degradación-respuestas-exitosas saturación-servicio cambio-contrato Descripción Detecta cuándo un servicio virtual supera el umbral preestablecido para su tiempo de respuesta. Detecta cuándo un servicio virtual supera el umbral preestablecido para la cantidad de fallas en sus respuestas. Detecta cuándo un servicio virtual supera la máxima cantidad de peticiones que puede procesar por período de tiempo. Detecta cuándo se produce un cambio en el documento WSDL al que accede un determinado servicio. Tabla 11 - Eventos Monitoreados por la plataforma Administrador de Requerimientos de Adaptación Este componente es el encargado de generar los nuevos Requerimientos de Adaptación a partir de los Eventos Monitoreados que dispara la plataforma. La Tabla 12, presenta y describe cada uno de los Requerimientos de Adaptación que se pueden generar en la configuración base de la plataforma implementada

61 Requerimiento de Adaptación disminuir-tiempo-respuesta aumentar-respuestas-exitosas disminuir-solicitudes manejar-cambio-contrato Descripción Representa la necesidad de disminuir el tiempo de respuesta de un servicio. Representa la necesidad de aumentar el porcentaje de respuestas exitosas de un servicio. Representa la necesidad de disminuir el número de solicitudes que recibe un servicio. Representa la necesidad de manejar el cambio de contrato de un Web Service. Tabla 12 - Requerimientos de Adaptación de la configuración base de la plataforma Administrador de Estrategias Este componente gestiona las distintas estrategias que permiten abordar los Requerimientos de Adaptación de la plataforma. El Administrador de Estrategias utiliza los servicios de adaptación del ESB para construir flujos que implementen las distintas Estrategias de Adaptación. En la Tabla 13 se describen las estrategias con las que cuenta la configuración base de la plataforma implementada, las cuales permiten abordar los Requerimientos de Adaptación que genera el Administrador de Requerimientos de Adaptación. Estrategia de Adaptación invocar-servicio-equivalente utilizar-información-almacenada distribuir-solicitud-equivalentes balancear-carga diferir-pedidos modificar-solicitud-respuesta Descripción Se invoca un servicio equivalente del servicio virtual para el cual que se detectó un requerimiento de adaptación. Se utiliza información previamente almacenada del servicio virtual para el cual se detectó un requerimiento de adaptación. Se distribuye la solicitud a un conjunto de servicios equivalentes del servicio virtual que generó el requerimiento de adaptación. Se balancea la carga de solicitudes entre varios servicios equivalentes al servicio virtual que requiere una adaptación. Se posterga el envío de la solicitud al servicio virtual para el cual se detectó el requerimiento de adaptación. Se modifica la solicitud o respuesta del servicio para el cual se detectó el requerimiento de adaptación. Tabla 13 - Estrategias de la configuración base de la plataforma. En este administrador se encapsula toda la lógica necesaria para implementar las estrategias básicas de adaptación, lo que facilita una futura extensión del Motor de Adaptación y Monitoreo. Además, se

62 dispone de un componente capaz de producir estrategias elementales que pueden combinarse para formar estrategias más complejas Consola de Administración La Consola de Administración es el componente que facilita la configuración de la plataforma mediante una interfaz gráfica. Además, permite el control y análisis de los procesos de adaptación que se generan para cada servicio. Este componente está totalmente desacoplado del ESB Adaptativo y del Motor de Adaptación y Monitoreo, lo que posibilita una comunicación bien definida mediante interfaces. La comunicación entre los principales componentes de la plataforma y la Consola de Administración se realiza a través de interfaces de servicios Java MBeans. Las principales funcionalidades de este componente en la plataforma implementada son: definir y configurar los Servicios Virtuales de la plataforma. analizar en tiempo real los procesos de adaptación que se generan en la plataforma y almacenar un histórico de los mismos. configurar cada uno de los componentes de la plataforma. La implementación de este componente web está basada en JSF y en un conjunto de componentes brindados por el framework Primefaces 15. Las principales funcionalidades con las que cuenta este componente fueron agrupadas en distintas categorías. Por una parte se agrupan aquellas funcionalidades que facilitan la gestión de los Servicios Virtuales, y por otra parte, aquellas que permiten tanto la configuración del Motor de Adaptación y Monitoreo, como la del ESB Adaptativo. En la Sección 5.8 se detallan cada una de las funcionalidades implementadas para este componente. 4.4 Interacción entre componentes En esta sección se describen las principales interacciones que se dan en tiempo de ejecución, entre los componentes de la Plataforma ESB Adaptativa, haciendo especial énfasis en la interacción entre los componentes ESB Adaptativo y el Motor de Adaptación y Monitoreo Envío de Propiedades Monitoreadas al Motor de Adaptación y Monitoreo Como se mencionó en la Sección 0, el Administrador de Monitoreo tiene como responsabilidad, calcular los valores de las propiedades que monitorea la plataforma y enviarlos al Motor de Adaptación y Monitoreo. Para esto, debe interactuar con los distintos mecanismos de monitoreo, los cuales pueden comunicarse con los servicios nativos brindados por JBoss ESB o con otros tipos de servicios, con el fin

63 de obtener información acerca de los Servicios Virtuales. Dicha información será utilizada para generar las propiedades monitoreadas. La Figura 37, presenta un diagrama de secuencia que especifica las interacciones necesarias para calcular y enviar, al Motor de Adaptación y Monitoreo, los valores de las propiedades monitoreadas para un servicio de la plataforma. Este diagrama se basa en las interacciones propuestas en [1], pero instanciadas sobre JBoss ESB. Figura 37 - Envío de Valores de Propiedades Monitoreadas. En este caso, el Administrador de Monitoreo interactúa con un Mecanismo de Monitoreo para obtener los datos recabados por el mismo. Este mecanismo se pude comunicar con un servicio nativo de JBoss ESB o implementar su propia lógica de monitoreo, tal es el caso del monitoreo de cambio de contrato, donde no existe interacción con los mecanismos brindados por el ESB. Una vez que el mecanismo retorna sus datos, el Administrador de Monitoreo los almacena, para luego calcular el valor de una propiedad, por ejemplo, el tiempo de respuesta promedio (en los últimos 60 segundos) de un servicio. Finalmente, la propiedad monitoreada es enviada hacia el Motor de Adaptación y Monitoreo para su posterior procesamiento. El envío de esta propiedad se realiza a través de la interfaz Java MBean expuesta por el Motor de Adaptación y Monitoreo. Como variante a esta secuencia, el Administrador de Monitoreo puede tener que interactuar con más de un Mecanismo de Monitoreo para calcular el valor de una propiedad

64 4.4.2 Mecanismo de Monitoreo para Cambio de Contrato Los cambios de contratos son detectados mediante un Mecanismo de Monitoreo diseñado específicamente para la Plataforma ESB Adaptativa, el cual permite controlar los cambios en los contratos de los Web Services externos. Para esto, el Administrador de Monitoreo debe inicialmente interactuar con el Mecanismo de Monitoreo, enviándole toda la información del servicio que se desea monitorear. Esta información es utilizada por el mecanismo para obtener la ubicación del WSDL del servicio externo. Luego de obtener la ubicación donde se encuentra publicado el WSDL externo, el mecanismo de monitoreo se responsabiliza de obtener su información y almacenarla. A partir de este momento, el mecanismo compara la última información del contrato del servicio con la información previamente almacenada. Si se encuentra algún tipo de diferencia entre los contratos, ya sea a nivel de operaciones o parámetros, el mecanismo se encarga de almacenar esta información como la última información monitoreada, y además descarta la información anterior. En caso que no se detecten diferencias, permanece almacenada la información del monitoreo recabada anteriormente. Cabe mencionar, que al existir diferencias en la comparación de los contratos, se genera una propiedad de monitoreo, cuyo contenido es la diferencia detectada entre los contratos comparados. En caso de no tener acceso al WSDL del servicio externo, la propiedad monitoreada para el cambio de contrato no queda definida, y por ende no se produce un requerimiento de adaptación asociado a un cambio de contrato. La Figura 38 presenta un diagrama de secuencia que especifica las interacciones realizadas por el Mecanismo de Monitoreo de Cambio de Contrato. Figura 38 - Interacciones del mecanismo de monitoreo de cambio de contrato

65 4.4.3 Envío de Directivas de Adaptación Los cambios en el valor de una propiedad monitoreada, pueden ocasionar que se generen nuevos requerimientos de adaptación para un servicio, ante lo cual la plataforma debe responder con una directiva de adaptación para abordarlo. En la Figura 39 se presentan las interacciones que realiza el Motor de Adaptación y Monitoreo cuando recibe las propiedades monitoreadas desde el Administrador de Monitoreo. En caso que el motor detecte un nuevo requerimiento de adaptación, deberá interactuar con los diferentes componentes de la plataforma, para finalmente generar una nueva directiva de adaptación y enviarla al Administrador de Adaptación. Figura 39 - Envío de directivas de adaptación. El Administrador de Monitoreo envía el valor de una propiedad monitoreada al Motor de Adaptación y Monitoreo, por ejemplo, el tiempo de respuesta promedio de un servicio. El motor recibe este valor e interactúa con el Administrador de Requerimientos de Servicios para obtener aquellos requerimientos que no están siendo satisfechos. A partir de la información recibida, el motor decide si se está ante una situación (evento monitoreado) que pueda generar un requerimiento de adaptación. Si se detecta un evento monitoreado, por ejemplo, el tiempo de respuesta promedio es mayor al que se establece en los requerimientos de un servicio, se puede generar un nuevo requerimiento de adaptación (dependiendo del contexto, estrategias registradas y los metadatos del servicio). En caso que se genere un nuevo requerimiento de adaptación, el Motor de Adaptación y Monitoreo puede necesitar interactuar con el Registro de Servicios para seleccionar e implementar una estrategia de adaptación. Una vez seleccionada e implementada la estrategia a través de un flujo de adaptación, ésta se envía como nueva directiva de adaptación, pudiéndose especificar además una fecha de expiración. Las directivas de adaptación en la Plataforma ESB Adaptativa tienen el siguiente formato id de servicio - flujo de adaptación - fecha de expiración

66 Como variante a la interacción anterior, el motor puede generar un requerimiento de adaptación para el cual no exista una estrategia de adaptación que lo aborde. En este caso el motor se encarga de notificar esta situación y finalizar sus interacciones Adaptación en el ESB Cuando el Administrador de Adaptación recibe una nueva directiva de adaptación para un servicio, la almacena, y todas las subsiguientes invocaciones al servicio aplicarán la directiva almacenada hasta que su tiempo de vigencia expire o sea reemplazada por una nueva. En la Figura 40, se presenta cómo se desarrolla una invocación a un Servicio Virtual, para el cual existe una directiva de adaptación vigente en el Administrador de Monitoreo. Figura 40 - Adaptación en el ESB. En una primera instancia, la Aplicación Cliente envía una petición al ESB Adaptativo para invocar al servicio SRV-1. El ESB intercepta dicha petición y la redirige al Gateway de Adaptación, el cual obtiene desde el Administrador de Adaptación la directiva vigente para el servicio que se desea invocar. En caso de que no exista una directiva de adaptación vigente para el servicio invocado, se retorna directamente el Servicio Virtual. Luego que el Administrador de Adaptación retorne la directiva, el Gateway de Adaptación se encarga de adjuntarla al mensaje, para que posteriormente sea procesada según el patrón de Ruteo Basado en Itinerario. Finalmente, el Gateway de Adaptación redirige el mensaje hacia el primer nodo del flujo contenido en la directiva de adaptación del servicio invocado. El flujo de adaptación de la Figura 40, consiste en invocar secuencialmente a los servicios de RET y SRV- 1. El servicio RET procesa el mensaje y avanza el flujo al próximo nodo, aplicando cierto retardo antes de redirigir el mensaje hacia el próximo servicio. Luego que el mensaje llega al servicio SRV-1, éste invoca a un Web Service externo y retorna su respuesta hacia la Aplicación Cliente que realizó la petición

67 Como variante al flujo anterior, puede ocurrir que la respuesta retornada por el Web Service tenga que ser transformada antes de redigirla hacia la Aplicación Cliente. Este caso es común en un contexto donde se utilizan servicios equivalentes, para los cuales se deben aplicar transformaciones tanto a las peticiones realizadas por el cliente, como a las respuestas obtenidas desde los Web Services externos Procesamiento del Flujo de Adaptación Como se describe en la Sección 4.4.4, cuando existe una directiva de adaptación vigente para un servicio, el Gateway de Adaptación se encarga de adjuntar un flujo de adaptación a todos los mensajes que pretendan invocarlo. A modo de ejemplo, la Figura 41 presenta cómo se procesa un mensaje a través de un flujo de adaptación, que consiste en balancear la carga (RBAL) entre dos servicios equivalentes (SRV-2 y SRV-3). Figura 41 - Procesamiento del Flujo de Adaptación. Como se observa en la Figura anterior, el mensaje posee un flujo de adaptación adjunto a través del cual debe ser procesado (1), cada paso de procesamiento (RBAL, SRV-2, SRV-3) se encarga de avanzar una posición en dicho flujo, para que posteriormente la acción del itinerario envíe el mensaje al próximo destino, de esta manera la Plataforma ESB Adaptativa conoce cuáles son los próximos pasos del mensaje y es capaz de rutearlos. Cabe aclarar, que los pasos de procesamiento SRV-2 y SRV-3 son los encargados de comunicarse con los Web Services externos, y dichos procesamientos se realizan de forma sincrónica. Una vez obtenida la respuesta del Web Service externo (que puede ser almacenada para su posterior utilización) se avanza una posición en el flujo de adaptación. Una vez que el flujo no posea mas pasos (6), el mensaje es ruteado por el ESB a la Aplicación Cliente que corresponda Interacción de la Consola de Administración Como se mencionó en la Sección , la Consola de Administración tiene como responsabilidad facilitar la configuración y la administración de la plataforma. Para esto, debe interactuar con distintos

68 componentes de la plataforma, con el fin de obtener información acerca de los servicios y presentarla de forma gráfica al usuario. A modo de ejemplo, la Figura 42 presenta las interacciones que realiza la Consola de Administración para obtener y persistir los datos de configuración (metadatos, transformaciones, etc.) de un servicio registrado. Figura 42 - Interacción para la modificación de un Servicio Virtual. En primer lugar, la Consola de Administración se comunica con el sub-componente Registros de Servicios y Configuración del ESB Adaptativo, solicitando toda la información disponible acerca de un Servicio Virtual. Esta información contiene los metadatos de servicio, como por ejemplo, nombre, categoría y endpoint del Web Service externo, entre otros. En segundo lugar, en caso de que el servicio tenga definidas transformaciones canónicas, la consola deberá interactuar nuevamente con el Registro de Servicios, con el fin de obtener los archivos correspondientes a las transformaciones. Estas transformaciones son utilizadas para trasladar el modelo de datos de este servicio desde y hacia el modelo de datos canónico. Finalmente, en caso de que se realice alguna modificación de los datos del servicio, la consola deberá enviar los datos que fueron modificados, para que posteriormente el registro persista los cambios realizados. 4.5 Extensibilidad La plataforma ESB Adaptativa consta de tres grandes componentes denominados, ESB Adaptativo, Motor de Adaptación y Monitoreo y Consola de Administración, cada uno de estos componentes se encuentran organizados a su vez en sub-componentes. Este diseño basado en componentes y sub

69 componentes permite fácilmente la reutilización de las funcionalidades ya existentes, para el desarrollo de nuevas funcionalidades que den soporte a nuevos requerimientos. Adicionalmente a lo mencionado, los sub-componentes más importantes de la plataforma cuentan con puntos de extensibilidad nativos, lo que permite un gran nivel de flexibilidad. Estas extensiones pueden ser realizadas mediante el registro de nuevos servicios o funcionalidades, configurando adecuadamente los archivos de configuración pertinentes. En las siguientes sub-secciones se presentan los principales puntos de extensibilidad con los que cuenta la Plataforma ESB Adaptativa Extensibilidad a nivel de componentes Como se detalla en la Sección 4.5.1, los principales componentes de la plataforma (ESB Adaptativo, Motor de Adaptación y Monitoreo, Consola de Administración) se intercomunican a través de interfaces Java MBeans, lo que posibilita el cambio de los distintos componentes por otras implementaciones, así como también la posibilidad de desplegar cada uno de ellos en diferentes servidores físicos o virtuales. La extensibilidad a nivel de componentes está dada por las distintas interfaces que exponen cada uno de ellos. En la Sección se describen algunas de las operaciones presentes en la interfaz que expone el componente ESB Adaptativo para su administración Extensibilidad a nivel de sub-componentes La extensibilidad a nivel de sub-componentes está dada mediante la configuración de archivos XML, los cuales registran funcionalidades, que son cargadas en tiempo de despliegue, y que pueden ser actualizadas desde la Consola de Administración en tiempo de ejecución. En particular, los componentes ESB Adaptativo y Motor de Adaptación y Monitoreo, cuentan con archivos de configuración XML que permiten fácilmente definir o extender cada una de sus funcionalidades. La extensibilidad a nivel de sub-componentes, puede estar dada por clases Java que se instancian en tiempo de ejecución utilizando Reflection 16, o mediante archivos de configuración, que pueden especificar por ejemplo, nombres de nuevos servicios y condiciones para sus requerimientos. En las sub-secciones siguientes se detalla el nivel de extensibilidad del ESB Adaptativo y el Motor de Adaptación y Monitoreo, que son los dos principales componentes de la plataforma Extensibilidad para los componentes del ESB Adaptativo Los puntos de extensibilidad y los respectivos archivos de configuración de este componente son los siguientes:

70 Mecanismos de monitoreo: El archivo de configuración jboss-adaptative-monitormechanism.xml permite definir nuevos mecanismos de monitoreo, que posibilitan extender el conjunto de los mecanismos brindados por la plataforma. Propiedades monitoreadas: En el archivo jboss-adaptative-properties.xml, se localizan las diferentes propiedades que se monitorean en la plataforma, y es posible agregar nuevas propiedades que permitan abordar nuevos requerimientos. Requerimientos de servicios: En el archivo jboss-adaptative-service-requirements.xml, se definen los requerimientos de servicios considerados por la plataforma, permitiendo definir en este archivo nuevos requerimientos que posibilitan extender los ya existentes. Configuración general: En el archivo jboss-adaptative-config.xml, se pueden modificar propiedades como: nombre de clase que implementa el comparador de WSDL, directorio donde se localizan los archivos para trasformaciones y directorio donde se guardan los contratos de los servicios registrados en la plataforma, entre otros Extensibilidad para los componentes del Motor de Adaptación y Monitoreo Los puntos de extensibilidad y los respectivos archivos de configuración de este componente se detallan a continuación: Eventos monitoreados: Los eventos que son disparados por la plataforma se definen en el archivo jboss-adaptative-events.xml, donde se pueden especificar nuevos eventos para que la plataforma los considere, y en base a ellos, genere nuevos requerimientos de adaptación. Requerimientos de adaptación: En el archivo jboss-adaptative-adaptation-requirements.xml se pueden definir nuevos requerimientos de adaptación que serán generados por el Motor de Adaptación y Monitoreo, a partir de los eventos que son disparados por la plataforma. Estrategias de adaptación El archivo jboss-adaptative-strategies.xml permite especificar nuevas estrategias de adaptación, que posibiliten abordar los distintos requerimientos de adaptación que se generan en la plataforma Interfaz de Administración del componente ESB Adaptativo A modo de ejemplo, la Figura 43 presenta las principales operaciones de la interfaz expuesta por el ESB Adaptativo para la administración de los servicios virtuales. En particular, se detallan las operaciones que permiten obtener los servicios de la plataforma, registrar nuevos servicios y almacenar metadata para un determinado servicio virtual. Esta interfaz es la que hace posible la interacción entre el ESB Adaptativo y los componentes Consola de Administración y Motor de Adaptación y Monitoreo, permitiendo el desacoplamiento de los principales componentes de la plataforma

71 Figura 43 - Interfaz EsbAdmServicesMBean. 4.6 Limitaciones y mejoras En esta sección se presentan las limitaciones y las posibles mejoras que se detectaron en cada uno de los componentes de la plataforma. En general, estas limitaciones y mejoras fueron discutidas en la etapa de diseño, decidiendo dejarlas fuera del alcance del proyecto, dado sus tiempos acotados. En las siguientes sub-secciones se presentan las limitaciones y/o mejoras para cada uno de los grandes componentes de la plataforma, detallando en algunos casos el trabajo adicional que estos implicarían. Limitaciones y mejoras para el componente ESB Adaptativo Actualmente, el ESB Adaptativo considera un intervalo de tiempo fijo para la obtención y cálculo de los valores de cada uno de los mecanismos de monitoreo, para posteriormente calcular las propiedades monitoreadas a partir de dichos valores. La naturaleza de estos mecanismos de monitoreo y de las propiedades monitoreadas pueden ser muy diversas, lo cual determina que algunas propiedades sean más sensibles al paso del tiempo y deban tener un intervalo de actualización reducido, así como también existirán otros casos donde el tiempo de procesamiento es elevado, y por tal motivo se deberán configurar intervalos de tiempo más extensos. Por dichos motivos, se concluye que establecer tiempos individuales para los intervalos de cálculo de propiedades y mecanismos, sería una mejora significativa en el ESB Adaptativo. Actualmente el sistema maneja un único hilo para la ejecución de los mecanismos de monitoreo y el cálculo de las propiedades monitoreadas. El cambio propuesto implica mantener distintos hilos de ejecución para cada uno de los mecanismos, y así poder controlar de forma individual sus intervalos de ejecución

72 Limitaciones y mejoras para el componente Motor de Adaptación y Monitoreo El Motor de Adaptación y Monitoreo encapsula la lógica necesaria para procesar la información que recibe del ESB Adaptativo y evaluar qué estrategia de adaptación se debe utilizar para cada servicio. Una de las mejoras a efectuar en este componente, es la reutilización de esta lógica para dar soporte a múltiples ESB Adaptativos. Implementar esta mejora en el sistema no implica grandes esfuerzos, dado que se cuenta con archivos de configuración, donde se establecen los distintos canales de comunicación utilizados, por lo que solamente se deberá extender esta funcionalidad para poder registrar más de un ESB Adaptativo. Otra de las opciones detectadas para mejorar este componente está directamente relacionada con la toma de sus decisiones. Actualmente, cuando existe más de una estrategia de adaptación para abordar un determinado requerimiento, el motor toma una decisión aleatoria para escoger cuál estrategia aplicar. La toma de este tipo de decisiones podría mejorarse notoriamente si se considerara información histórica de los servicios, o algún algoritmo de aprendizaje automático como una red neuronal, que detecte patrones comunes en el conjunto de servicios registrados en la plataforma. Limitaciones y mejoras del componente Consola de Administración Dado que la Consola de Administración consume los servicios expuestos por el resto de los componentes de la plataforma, toda nueva funcionalidad que se desee incorporar deberá ser primero implementada y expuesta por algún otro componente, para luego consumirla y exponerla de forma gráfica al usuario. A pesar de que la Consola de Administración permite la recarga en tiempo de ejecución de todos los archivos de configuración, éstos no pueden ser editados desde la interfaz gráfica, lo que es una gran limitante para una administración amigable de la plataforma. La implementación de esta nueva funcionalidad implicaría que cada uno de los componentes exponga en su interfaz, métodos que permitan la edición de cada uno de sus archivos de configuración. Además, la Consola de Administración debería proveer gráficamente una vista que simplifique la edición de las distintas configuraciones. Otro conjunto interesante de funcionalidades para integrar a la Consola de Administración, son las que permitan generar y administrar estadísticas de la plataforma, como por ejemplo almacenar información del servicio con más adaptaciones, la cantidad de estrategias utilizadas para cada servicio, estrategias más eficaces y estrategias más utilizadas, entre otras. Esto permitiría visualizar en distintos gráficos la evolución de las adaptaciones de cada uno de los servicios. Una implementación acotada de estas funcionalidades, es posible con las interfaces que actualmente exponen los distintos componentes, las cuales permiten obtener el histórico de los flujos de adaptación de los servicios. Por lo tanto, solo restaría implementar en la consola, aquellas funcionalidades que permitan obtener, almacenar y desplegar la información

73 5 Detalles de Implementación En esta sección se presenta detalladamente la implementación de los componentes más relevantes de la plataforma, describiendo también aquellos componentes que pueden ser reutilizados en otros proyectos que utilicen JBoss ESB. Además, se comentan los principales problemas encontrados durante la implementación de la Plataforma ESB Adaptativa. 5.1 Mecanismos de Adaptación Los mecanismos de adaptación implementados en la plataforma base son los descriptos en la Sección 4.3.2, los cuales se encargan de realizar las acciones de adaptación en el ESB. Específicamente, se implementaron mecanismos de adaptación que obtienen dinámicamente la información del itinerario de cada mensaje, y se basan fuertemente en los mecanismos de adaptación provistos por JBoss ESB. En la Tabla 14 se presentan cada uno de los mecanismos de adaptación implementados, describiendo para cada uno de ellos, la acción del producto en la cual se basa. Mecanismo Acción JBoss ESB Acción Personalizada Transformación org.jboss.soa.esb.actions.transformation.xslt. XsltAction org.fing.edu.uy.esbadp.action.transform. TranformAction Ruteo org.jboss.soa.esb.actions.staticrouter org.fing.edu.uy.esbadp.action.routing. RoutingAction Invocación Servicio Virtual Lista de Destinatarios Balanceo org.jboss.soa.esb.actions.syncserviceinvoker org.jboss.soa.esb.client. ServiceInvoker org.jboss.soa.esb.client. ServiceInvoker y org.jboss.soa.esb.actions.staticrouter org.fing.edu.uy.esbadp.action.sync. SyncAction org.fing.edu.uy.esbadp.action.list. ListAction org.fing.edu.uy.esbadp.action.randombalance. RandomBalanceAction Unificador org.jboss.soa.esb.actions. Aggregator org.fing.edu.uy.esbadp.action.aggregator. Aggregator Cache No existe acción en JBoss ESB org.fing.edu.uy.esbadp.action.cache. CacheLoadAction Retardador No existe acción en JBoss ESB org.fing.edu.uy.esbadp.action.delayer. DelayerAction Tabla 14 - Acciones base de JBoss ESB. En algunos de los mecanismos implementados, el trabajo consistió en tomar el código fuente de las acciones brindadas por JBoss ESB, y a partir del mismo crear nuevas acciones que permitan obtener las propiedades de cada mecanismo desde el itinerario del mensaje, y no de la especificación del servicio definido en el archivo jboss-esb.xml, tal como lo realizan la acciones nativas del producto. En cuanto a la implementación de los mecanismos lista de destinatarios y unificador de respuestas, se realizaron implementaciones particulares. Para la lista de destinatarios, se realizan copias del mensaje original, para luego distribuir cada una de esas copias al servicio correspondiente, agregándole a cada

74 una de ellas un identificador único. Este identificador será utilizado posteriormente por el unificador de respuestas, para determinar a qué mensaje pertenece una determinada respuesta. Con respecto al envió de los mensajes, éstos se realizan utilizando la funcionalidad deliverasync, brindada por el componente Service Invoker de JBoss. En cuanto al unificador de respuestas, se realizan personalizaciones para que esta acción retorne la primera respuesta obtenida para un identificador dado, y descarte el resto. Esta implementación se basó fuertemente en la acción Aggregator de JBoss ESB. Por otra parte, la implementación del balanceador de carga se basa fuertemente en la cantidad de servicios a los que puede enviar una solicitud, y en base a dicha cantidad selecciona uno de forma aleatoria, para que posteriormente el itinerario dirija el mensaje hacia el servicio seleccionado. Finalmente, la implementación de los mecanismos de adaptación cache e itinerario se describen con detenimiento en la Sección Mecanismos de Monitoreo Como se mencionó en la Sección 0, la Plataforma ESB Adaptativa monitorea la información de las invocaciones a los servicios virtuales y la de los contratos de los Web Services externos. Con respecto al monitoreo de invocaciones a servicios virtuales, JBoss ESB registra diversa información para cada uno de ellos, como por ejemplo el tiempo de respuesta y el éxito de sus invocaciones, entre otros. Esta información es utilizada posteriormente por los mecanismos que monitorean las invocaciones a los servicios virtuales para calcular los valores monitoreados. Por otra parte, el monitoreo de los contratos de los servicios se encarga de detectar cambios en los WSDLs de los servicios externos, los cuales son accedidos por los servicios virtuales registrados en la plataforma Mecanismos de monitoreo de invocaciones a Servicios Virtuales Estos mecanismos de monitoreo contribuyen a la detección de eventos monitoreados por parte de la plataforma, como lo son: la degradación del tiempo de respuesta, la degradación de respuestas exitosas y la saturación de los servicios. A continuación, se describe la implementación de aquellos mecanismos de monitoreo que obtienen información acerca de los servicios virtuales. Monitoreo de invocaciones exitosas JBoss ESB monitorea la cantidad de invocaciones exitosas de cada uno de sus servicios y expone ésta información a través de Java MBeans, que pueden ser accedidos desde cualquier cliente que soporte el protocolo de mensajería JMX. Concretamente, este mecanismo de monitoreo obtiene su información desde el MBean MessageCounter, el cual posee un atributo denominado messages successfully processed count, que retorna la cantidad de invocaciones exitosas para un servicio virtual. Monitoreo de invocaciones con fallas JBoss ESB monitorea de forma nativa la cantidad de fallas que produce cada uno de sus servicios, y expone esta información a través de Java MBeans. En particular, la implementación de este mecanismo,

75 obtiene su información del atributo messages failed count brindado por el MBean MessageCounter de JBoss ESB. Monitoreo del tiempo de respuesta JBoss ESB expone de forma nativa, información del tiempo de respuesta de cada uno de sus servicios. Al igual que en los mecanismos anteriores, la información de este mecanismo es obtenida a partir del atributo overall service time processed del MBean MessageCounter. Como se describe anteriormente, todos los mecanismos de monitoreo de servicios virtuales utilizan los atributos brindados por el MBean MessageCounter, lo cual permitió implementar fácilmente estos mecanismos, sin tener la necesidad de crear nuevos servicios que recaben información de cada servicio virtual Mecanismo de monitoreo de contratos de Web Services externos Este mecanismo de monitoreo permite detectar cambios en los contratos de los servicios externos, y por lo tanto, puede contribuir a generar requerimientos de adaptación para manejar los distintos cambios que se producen en los contratos de los servicios. En cuanto a la implementación, este mecanismo no consume ninguna de las funcionalidades brindadas por JBoss ESB, ya que el producto no realiza ningún tipo de seguimiento sobre los contratos de los servicios a los que accede. Sin embargo, la implementación de esta funcionalidad se basó en la idea presentada en [22], donde se desarrolló una herramienta capaz de comparar documentos WSDL. En particular, la implementación realizada utiliza las funcionalidades brindadas por la biblioteca EasyWSDL [23], que permite manipular fácilmente los documentos WSDL, tanto para las publicaciones DOCUMENT 17 como para las RPC. Cuando el Administrador de Monitoreo invoca a este mecanismo para que chequee el contrato de un servicio, éste se encarga de examinar si existe almacenada en la plataforma alguna versión del WSDL de dicho servicio, para posteriormente proseguir a la comparación de los WSDLs. De no existir una versión previa del WSDL, el mecanismo se encarga de almacenarla en la plataforma y comunicarle al administrador que no existen cambios en el contrato del servicio. En caso que exista un documento previo y el mecanismo detecte algún tipo de diferencia, éste actualiza el contenido del documento WSDL almacenado en la plataforma y le retorna al administrador las diferencias detectadas. La Figura 44 presenta cómo este mecanismo almacena los contratos de los servicios en la plataforma. Para cada uno de los WSDL de los servicios externos, se genera un archivo XML con el identificador del servicio virtual que lo accede, además de los esquemas auxiliares que utiliza el propio documento WSDL

76 Figura 44 - Estructura para el almacenamiento de los contratos de los servicios. Cabe mencionar, que para soportar el tipo de publicación DOCUMENT y RPC se debieron crear dos versiones del comparador, ya que la forma en que éstos organizan la información es muy diferente. La Tabla 15 detalla el comportamiento de este mecanismo frente a los distintos cambios que pueden ocurrir en el contrato de un servicio. Cambio Agregar operación. Renombrar operación. Quitar operación. Modificar MEP de operación. Agregar Parámetro. Renombrar Parámetro. Cambiar Opcionalidad Parámetro. Cambiar Orden Parámetros. Quitar Parámetro. Soportado. No afecta comportamiento. Observaciones Solamente se detecta este cambio si los parámetros de entrada y de salida de la nueva operación y de la antigua son idénticos, tanto en sus nombres como en sus tipos de datos. Cabe aclarar, que también se valida que la antigua operación no siga existiendo en el nuevo WSDL, ya que en este caso el sistema interpretará que existe una nueva operación en el contrato del servicio. No soportado. No es posible manejarlo. No soportado. Soportado siempre y cuando el nuevo parámetro admita un valor por defecto. El sistema interpretará la existencia de un nuevo parámetro, cuando no se elimine un parámetro y se agregue otro con el mismo tipo de dato y en la misma posición. Soportado. El sistema interpretará un renombre de parámetro cuando en el nuevo WSDL exista un parámetro que no existía en el WSDL antiguo, y además sus tipos de los datos y sus posiciones en ambos WSDL sean iguales. No soportado. No soportado. Soportado. Tabla 15 - Cambios en los contratos de los servicios soportados por la plataforma. La información recabada por este mecanismo es utilizada por la estrategia encargada de manejar los cambios de contrato de los servicios, que a partir de dicha información genera transformaciones XSLT, permitiendo seguir invocando a un servicio que sufrió cambios en su contrato

77 5.3 Administrador de Monitoreo Como se menciona en la Sección 0, este componente se encarga de calcular el valor de las distintas propiedades a partir de los valores obtenidos por los mecanismos de monitoreo. El Administrador de Monitoreo permanece dormido por cierto período de tiempo (configurable), y cada vez que ejecuta, procesa los mecanismos monitoreados para cada uno de los servicios registrados, los cuales se utilizan para calcular los valores de las distintas propiedades. Finalmente, este componente envía dichas propiedades al Motor de Administración y Monitoreo, y se vuelve a dormir. La Figura 45 presenta una pequeña máquina de estado que muestra el flujo de acciones de este administrador. Figura 45 - Estados del Administrador de Monitoreo Propiedades monitoreadas La plataforma implementa un conjunto de Propiedades, y además brinda la posibilidad de extender este conjunto como se detalla en la Sección Una Propiedad Monitoreada se define a partir de una clase Java que implementa la interfaz IAdpPropertie.java, la cual contiene un único método, que es invocado por el Administrador de Monitoreo cada vez que se requiera calcular el valor de dicha propiedad. El método definido en la interfaz recibe la lista de los valores obtenidos por los mecanismos de monitoreo, junto con la información del servicio para el cual se requiere calcular las propiedades monitoreadas. Este método, tiene la responsabilidad de retornar el objeto que representa la propiedad calculada, permitiendo implementar cualquier lógica para el cálculo de una propiedad. El valor de estas propiedades se calcula a partir de la información recabada por los distintos mecanismos de monitoreo. En algunos casos, el valor de una propiedad depende directamente de un mecanismo monitoreo concreto, por ejemplo, la propiedad tiempo promedio de respuesta, se calcula fácilmente según la información monitoreada por el mecanismo Monitoreo de Tiempo de Respuesta. En otros casos, como por ejemplo, la propiedad cantidad de invocaciones, el cálculo se realiza a partir de la

78 información de varios mecanismos de monitoreo. La cantidad de invocaciones de un servicio se calcula como la suma de la cantidad de invocaciones exitosas, más la cantidad de invocaciones con falla, datos que son obtenidos por los mecanismos Monitoreo de invocaciones exitosas y Monitoreo de invocaciones con fallas respectivamente. La Tabla 16 describe las propiedades implementadas por la plataforma y los mecanismos que utilizan. Descripción Mecanismos utilizados Forma de cálculo Cantidad de invocaciones por unidad de tiempo. Invocaciones exitosas. Invocaciones con fallas. Inv. exitosas + Inv. con fallas Porcentaje de respuestas exitosas Invocaciones exitosas. Invocaciones con fallas. Inv. exitosas * 100 / (Inv. exitosas + Inv. con fallas) Tiempo de respuesta promedio T. de respuesta total Invocaciones exitosas. Invocaciones con fallas. T. de respuesta total / (Inv. exitosas + Inv. con fallas) Diferencias detectadas en el WSDL Cambio de contrato. Diferencias ( wsdl1, wsdl2) Tabla 16 - Propiedades implementadas en la plataforma. 5.4 Administrador de Requerimientos de Servicios Según lo mencionado en la Sección 4.3.6, el Administrador de Requerimientos de Servicios gestiona toda la información referente a los requerimientos de los servicios. A su vez, este administrador expone una interfaz Java MBean, que permite obtener los requerimientos que no se satisfacen de cada servicio virtual registrado en la plataforma. En la plataforma implementada, existen dos tipos de requerimientos de servicios, los simples y los complejos. Los requerimientos simples son evaluados por el Evaluador de Requerimientos Simples, el cual implementa toda la lógica que permite evaluar las condiciones definidas entre el valor de una determinada propiedad y la metadata de un servicio. A modo ejemplo, la Figura 46 detalla cómo definir un Requerimiento de Servicio simple, donde se especifica una determinada cota (responsetimelimit) para el tiempo promedio de la respuesta de los servicios. Figura 46 - Requerimiento de Servicio Simple

79 Cada servicio registrado en la plataforma debe tener definido en su metadata un valor que especifique el tiempo límite de sus respuestas, el cual puede tomar diferentes valores dependiendo de cada servicio. En el ejemplo anterior, el requerimiento de servicio no se satisface si la propiedad que especifica el tiempo promedio de respuesta, supera el valor de tiempo límite del servicio. Por otra parte, cuando el requerimiento de servicio es de tipo complejo, se debe especificar el nombre canónico de la clase Java que se encarga de evaluar si el requerimiento se satisface, en este caso el Administrador de Requerimientos de Servicios instancia dicha clase mediante Java Reflection y le delega la responsabilidad de calcular si el requerimiento se satisface o no. En la Figura 47 se muestra un ejemplo de cómo definir un Requerimiento de Servicio complejo, el cual determina si existen diferencias entre el contrato almacenado de un servicio y su documento WSDL actual. Figura 47 - Requerimiento de Servicio Complejo. En este caso, el requerimiento de servicio no se satisface si la propiedad que monitorea el contrato de un servicio notifica algún cambio. Luego que este administrador culmina la evaluación de los requerimientos de un servicio, retorna el conjunto de requerimientos que no se satisfacen al Motor de Adaptación y Monitoreo. 5.5 Gateway de Adaptación Como se menciona en la sección 4.3.7, en este proyecto se decidió realizar dos implementaciones de este componente, una utilizando el listener HTTP-Gateway y otra utilizando JBR-Gateway. Cabe mencionar que ambas implementaciones utilizan la acción GatewayAction implementada en la plataforma, la cual se encarga de interactuar con el Administrador de Adaptación y adjuntar los flujos de adaptación en los mensajes. La Figura 48, presenta la implementación del Gateway de Adaptación basada en el listener HTTP- Gateway, donde se visualiza que el action pipeline consta de una única acción denominada GatewayAction. Por otra parte, se puede ver que el listener Http definido posee un patrón de URL, el cual es utilizado por el servidor de aplicación para dirigir las peticiones que concuerden con el contexto /http/* hacia la acción GatewayAction

80 Figura 48 - Implementación del Gateway de Adaptación basada en HTTP-Gateway. A continuación, la Figura 49 presenta la segunda implementación del Gateway de Adaptación, la cual se basa en el listener JBR-Gateway de JBoss ESB. Figura 49 - Implementación del Gateway de Adaptación basada en JBR-Gateway. En este caso, el servicio consta de un único listener y de una única acción dentro del action pipeline. El listener definido, está compuesto por un jbr-provider que utiliza el protocolo HTTP y atiende las peticiones en el puerto 9999, mientras que la acción de adaptación es la misma que se utiliza en la implementación basada en HTTP-Gateway. 5.6 Registro de Servicios y Configuración El Registro de Servicios y Configuración encapsula toda la lógica que permite agregar, eliminar y modificar la información de los servicios virtuales y de sus relaciones. Además, permite cargar los archivos de configuración de la plataforma, posibilitando por ejemplo, activar el registro de históricos de las adaptaciones que se realizan sobre los servicios virtuales. La implementación de este registro permite modificar sus mecanismos de persistencia sin afectar a los componentes que utilizan sus funcionalidades Registro de servicios El Registro de Servicios implementado permite gestionar las altas, bajas y modificaciones de los servicios virtuales. Esta gestión se puede realizar utilizando la Consola de Administración, o bien invocando directamente las interfaces Java MBean que expone la plataforma

81 La información de los servicios virtuales y de sus relaciones, es persistida en una base de datos relacional, utilizando el mismo DataSource de los archivos de configuración de JBoss ESB (jbossesbproperties.xml), el cual permite seleccionar entre varios motores de base de datos. En la Figura 50, se detalla el modelo de datos utilizado para la persistencia de los servicios, las relaciones de equivalencia y la metadata de los servicios. Figura 50 - Modelo de datos ESB Adaptativo. La tabla SERVICE persiste información referente a los servicios virtuales de la Plataforma ESB Adaptativa. Cada registro de esta tabla posee los siguientes atributos: service_id: identificador único del servicio virtual, utilizado internamente por la plataforma. name: nombre con el que se definió el servicio virtual en el proyecto ESB que lo publica. category_name: categoría con la que se definió el servicio virtual en el proyecto ESB que lo publica. endpoint: url del endpoint del servicio original al cual el servicio virtual accede. esb_proyect_ref: nombre del proyecto ESB que publica al servicio virtual. La tabla METADATA se encarga de persistir la metadata de los servicios virtuales de la plataforma. Los atributos que componen esta tabla son las siguientes: service_id: identificador del servicio al cual se asocia la metadata. meta_key: clave que identifica la metadata. meta_value: representación en cadena de caracteres de la metadata. Por último, la tabla SERVICE_EQUIV persiste la relación de equivalencia de los servicios virtuales. Los atributos que componen esta tabla son las siguientes: service_id: identificador del servicio al que se le asocia el equivalente. equiv_id: identificador del servicio equivalente

82 Los archivos que definen las transformaciones desde y hacia el modelo de datos canónico son persistidos directamente en disco, según la estructura de directorios detallada en la Figura 51. Los nombres de estos archivos tienen la siguiente nomenclatura, para los correspondientes a trasformaciones hacia el modelo de datos canónico, se utiliza el identificador del servicio y el sufijo _To, mientras que para los correspondientes a transformaciones hacia el modelo de datos particular, se utiliza el identificador del servicio y el sufijo _From. Figura 51 - Estructura para el almacenamiento de transformaciones canónicas Archivos de configuración y definición. Como se menciona en la Sección 4.3.8, la plataforma maneja una gran cantidad de archivos de definición, que permiten especificar los distintos puntos de extensibilidad. Estos archivos se cargan en tiempo de despliegue y pueden ser recargados en tiempo de ejecución. La plataforma cuenta además con archivos de propiedades, que permiten configurar otros aspectos, como por ejemplo, las URLs de las interfaces Java MBeans. Estos archivos son cargados al iniciar la aplicación y es necesario reiniciar el servidor para que los cambios surtan efecto. En la Tabla 17 y Tabla 18 se describen cada una de las propiedades mencionadas anteriormente. Nombre Descripción Archivo SleepTimeThreadAdmMonitor CompareWSDLImpl MotorMonitorURL MotorMonitorObjectName PathWSDLStore Intervalo en segundos del cálculo de las propiedades monitoreadas por el Administrador de Monitoreo Nombre canónico de la clase Java que implementa el comparador de WSDL Url del servicio MBean expuesto por el Motor de Adaptación y Monitoreo. Nombre del servicio MBean expuesto por el Motor de Adaptación y Monitoreo. Ruta relativa a la instalación de JBoss ESB donde son persistidos los WSDL utilizados por el comparador. jboss-adaptative-config.xml jboss-adaptative-config.xml jboss-adaptative-config.xml jboss-adaptative-config.xml jboss-adaptative-config.xml PathXSLTStore Ruta relativa a la instalación de JBoss ESB donde son persistidos los archivos XSLT para las transformaciones desde y hacia el modelo de datos canónico. Tabla 17 - Propiedades de configuración para el ESB Adaptativo. jboss-adaptative-config.xml

83 Nombre Descripción Archivo jmx.service.url.esbadp Url del servicio MBean expuesto por el ESB Adaptativo. config.properties jmx.service.name.esbadp Nombre del servicio MBean expuesto por el ESB Adaptativo. config.properties motor.time.expiration.strategy motor.historic.flag Tiempo de vida por defecto para una estrategia de adaptación (en milisegundos). Habilita el registro del histórico de las estrategias de adaptación utilizadas para cada servicio. config.properties config.properties motor.historic.count Cantidad máxima de flujos de adaptación almacenados por servicio. config.properties Tabla 18 - Propiedades de configuración para el Motor de Administración y Monitoreo Histórico de Adaptaciones La implementación del Histórico de Adaptaciones permite almacenar los últimos flujos de adaptación que fueron procesados por la plataforma, los cuales se pueden observar gráficamente desde la Consola de Administración. El registro de esta información histórica genera un overhead al final de cada ciclo de adaptación, y produce un gran volumen de información. Por esta razón, se mantiene en memoria una lista circular FIFO, con los flujos procesados para cada servicio, permitiendo almacenar sus últimos n flujos de adaptación, correspondientes a sus últimas n invocaciones. El valor de n es parte de la configuración de la plataforma, siendo su valor por defecto 10. Adicionalmente, existe la opción de deshabilitar esta funcionalidad para aquellos ambientes donde no se requiera analizar información histórica, o se tengan otros mecanismos para hacerlo. 5.7 Motor de Adaptación y Monitoreo Como se describe en la Sección 4.3.9, el Motor de Adaptación y Monitoreo debe ser capaz de recibir las propiedades monitoreadas por el ESB Adaptativo, enviar directivas de adaptación al Administrador de Adaptación y brindar mecanismos que permitan tomar decisiones de adaptación. En la plataforma implementada, cada vez que el ESB Adaptativo notifica que existen nuevas propiedades monitoreadas para un servicio, el Motor de Adaptación y Monitoreo crea un nuevo hilo de ejecución, que se encarga de procesar la información recibida, para luego generar nuevas directivas de adaptación en caso que considere necesario. La Figura 52 detalla los estados por los que transitan los hilos creados por el Motor de Adaptación y Monitoreo

84 Figura 52 - Estados y transiciones de los hilos creados por del Motor de Adaptación y Monitoreo. El Motor de Adaptación y Monitoreo implementa la lógica que permite decidir qué directiva de adaptación se utiliza en aquellos escenarios donde exista más de un requerimiento de adaptación, o más de una estrategia que aborde un mismo requerimiento. La implementación actual decide de forma aleatoria qué estrategia utilizar en ese tipo de escenarios. Sin embargo, existen casos concretos, como el cambio de contrato, donde se deben combinar directivas de adaptación. La lógica implementada para combinar estas directivas de adaptación, puede ser reutilizada en la implementación de un motor más inteligente, que genere flujos de adaptación más complejos utilizando las funcionalidades ya implementadas. La Figura 53, presenta un ejemplo donde se combinan las estrategias que permiten diferir los pedidos de un servicio que se encuentra saturado y que además sufrió cambios en su contrato

85 Figura 53 - Combinación de estrategias. En las siguientes sub-secciones se describen cada uno de los sub-componentes que conforman el Motor de Adaptación y Monitoreo Administrador de Eventos Este administrador es el encargado de la gestión de los Eventos Monitoreados en la Plataforma ESB Adaptativa. Las condiciones para detectar un Evento Monitoreado dependen en gran medida de cada evento, y éstas se definen en el archivo de configuración jboss-adaptative-events.xml. A su vez, en este archivo se especifican los requerimientos de servicio que no se deben satisfacer para que un determinado evento sea disparado. A modo de ejemplo, la Figura 54 presenta cómo se define el evento Degradación del Tiempo de Respuesta en la plataforma implementada. En dicha figura se observa el nombre que identifica al evento, y aquellos requerimientos de servicios que cuando no se satisfacen, provocan que este evento sea disparado. Figura 54 - Ejemplo de configuración de un Evento Monitoreado. Se debe tener en cuenta, que los nombres de requerimientos de servicios definidos en el archivo jbossadaptative-events.xml, deben coincidir con los que fueron definidos previamente en el archivo jbossadaptative-service-requirements.xml, los cuales son utilizados por el Administrador de Requerimientos

86 de Servicios para realizar la evaluación de los requerimientos de los servicios registrados en la plataforma Administrador de Requerimientos de Adaptación Este administrador es el encargado de gestionar los Requerimientos de Adaptación de la plataforma implementada, los cuales se generan a partir de los distintos Eventos Monitoreados. A modo de ejemplo, la Figura 55 detalla cómo definir un Requerimiento de Adaptación para disminuir el número de solicitudes que recibe un determinado servicio. En este caso, el Requerimiento de Adaptación se genera luego de que la plataforma detecta un evento de saturación de servicio. Figura 55 - Requerimiento de adaptación para una saturación de servicio. En el marco de este proyecto se decidió realizar una asociación uno a uno entre los Eventos Monitoreados y los Requerimientos de Adaptación que éstos generan. En particular, los eventos degradación-tiempo-respuesta, degradación-respuestas-exitosas, saturación-servicio y cambio-contrato generan los requerimientos de adaptación disminuir-tiempo-respuesta, aumentar-respuestas-exitosas, disminuir-solicitudes y manejar-cambio-contrato respectivamente Administrador de Estrategias de Adaptación. Este administrador gestiona las estrategias de adaptación de la plataforma implementada, las cuales permiten hacer frente a los distintos requerimientos de adaptación. Las condiciones que determinan si una estrategia es aplicable a un determinado requerimiento de adaptación, se definen en el archivo de configuración jboss-adaptative-strategies.xml. A modo de ejemplo, la Figura 56 presenta una especificación de la estrategia que utiliza información almacenada, que puede ser utilizada tanto para bajar los tiempos de respuesta (downresponsetime), como para aumentar la cantidad de respuestas exitosas (upsuccessfullresponsecount). Figura 56 - Estrategia que utiliza información almacenada

87 Cada nueva estrategia que se desarrolle en la plataforma debe implementar la interfaz IAdpStrategy, la cual define un único método (getadptree), que es utilizado por el Motor de Adaptación y Monitoreo para generar la directiva de adaptación correspondiente a un determinado servicio. Consecuentemente, esta interfaz permite que el Motor de Adaptación y Monitoreo se abstraiga de las implementaciones concretas de cada una de las estrategias de la plataforma. La Figura 57, presenta el diagrama de clases donde se especifican cada una las de estrategias implementadas en el marco de este proyecto. Figura 57 - Diagrama de clases de las estrategias implementadas. 5.8 Consola de Administración El objetivo de esta sección es presentar las funcionalidades con las que cuenta la Consola de Administración, la cual está orientada a facilitar la administración, configuración y el monitoreo de la Plataforma ESB Adaptativa Servicios Virtuales Estas funcionalidades permiten realizar la gestión de los servicios virtuales registrados en la plataforma, permitiendo de forma gráfica definir para cada uno de ellos su metadata, sus servicios equivalentes y especificar las transformaciones que permiten trasladar su modelo de datos desde y hacia el modelo de datos canónico. Adicionalmente, la consola cuenta con funcionalidades de monitoreo en tiempo real de las adaptaciones que se generan en la plataforma, como por ejemplo, el monitoreo del flujo de adaptación vigente, y el historial de las distintas adaptaciones aplicadas sobre un determinado servicio. A continuación se detallan las funcionalidades de la consola referentes a los servicios virtuales. alta, baja, modificación y visualización de los servicios virtuales registrados en la plataforma

88 alta y baja de transformaciones desde y hacia el modelo de datos canónico. configuración de la metadata de cada servicio virtual. visualización de la directiva de adaptación para cada uno de los servicios registrados. visualización del histórico de flujos de adaptación procesados para cada servicio. La Figura 58 presenta cómo se visualizan los servicios virtuales registrados en la plataforma, detallando en cada uno de ellos su identificador, nombre, categoría, etc. Figura 58 - Registro de Servicios Virtuales Configuración del ESB Adaptativo y del Motor de Adaptación y Monitoreo En este grupo, se ubican aquellas funcionalidades que permiten visualizar el contenido de los diferentes archivos de configuración del ESB Adaptativo y del Motor de Adaptación y Monitoreo, así como también la funcionalidad que posibilita recargarlos. Todos los archivos de configuración descriptos en la Sección , cuentan con una vista asociada en la Consola de Administración. A modo de ejemplo, la Figura 59 presenta la configuración de los Requerimientos de Servicios de la plataforma

89 Figura 59 - Requerimientos de Servicios. 5.9 Componentes ESB Reutilizables En esta sección se presentan detalladamente dos de los componentes de la plataforma que pueden ser reutilizados en otros contextos, ya que resuelven problemas recurrentes de una forma genérica. En la Sección se detalla la implementación y reutilización del Ruteo Basado en Itinerario mientras que en la Sección se presenta el mecanismo de adaptación que utiliza información almacenada (Cache) Ruteo Basado en Itinerario El ruteo basado en itinerario, determina en tiempo de ejecución el destino del mensaje en base a un itinerario contenido en el propio mensaje. Dicho itinerario, especifica el siguiente servicio al cual se debe rutear el mensaje, pudiendo ser actualizado en cada uno de los servicios por los que transita. Para brindar soporte al ruteo basado en itinerario, se definió una interfaz denominada AdpFlowInterface, que permite abstraer la implementación concreta de cada uno de los mecanismos de adaptación. Cada mecanismo de la plataforma debe implementar dicha interfaz, la cual define tres métodos: obtener el nombre del servicio, obtener la categoría del servicio y una representación de sus propiedades en formato plano. A su vez, cada una de estas implementaciones posee características y/o propiedades adicionales, que dependen en gran medida de cada mecanismo de adaptación. Por ejemplo, el mecanismo de retardo, posee un atributo que especifica el tiempo de postergación en la entrega de un mensaje. En la Figura 60 se presenta el diagrama de clases de las diferentes implementaciones realizadas sobre la interfaz AdpFlowInterface, detallando para cada una de ellas sus atributos adicionales

90 Figura 60 - Implementaciones de la interfaz AdpFlowInterface. El Itinerario implementado se basa en una estructura de grafo, cuyos nodos son implementaciones concretas de la interfaz AdpFlowInterface, que en la plataforma implementada representan los distintos Servicios ESB de los Flujos de Adaptación. Cuando un nuevo mensaje llega al Gateway de Adaptación, éste se encarga de redirigirlo al primer servicio definido en el itinerario, y el servicio que recibe el mensaje tiene la responsabilidad de procesarlo y redirigirlo nuevamente hacia el próximo servicio del flujo, o directamente retornar una respuesta en caso de ser el último nodo. La plataforma implementa la acción ItineraryAction que abstrae este proceso, redirigiendo un mensaje hacia el siguiente Servicio ESB definido en su flujo. La implementación del ruteo basado en itinerario puede ser reutilizada para procesar cualquier itinerario que sea representable como un grafo de servicios, el cual contenga en cada uno de sus nodos una implementación de la Interfaz AdpFlowInterface. Cabe recordar que los servicios involucrados en el itinerario de un mensaje, deben contener la acción ItineraryAction como la última acción de su pipeline Cache Cache es el nombre utilizado en el contexto de este proyecto para hacer referencia al mecanismo que permite utilizar información previamente almacenada, el cual es capaz de generar una respuesta sin la necesidad de invocar directamente a un servicio. Se recuerda que este mecanismo de adaptación solo es aplicable sobre servicios de datos. Si un servicio efectúa una operación de negocio que altere alguna información (por ejemplo, efectuar un pago), es necesario invocarlo directamente y no es factible la utilización de este mecanismo. La implementación de este componente fue desarrollada utilizando la librería EHCache 18, que permite configurar el tamaño del máximo de cache (en disco y memoria), el tiempo de vida, el tiempo de

91 inactividad y otras propiedades. Adicionalmente, el Cache implementado cuenta con mecanismos para obtener información estadística en tiempo de ejecución, como por ejemplo, el tamaño actual del cache, la cantidad de cache hits y la de chache miss. En la plataforma implementada, es posible configurar estos valores mediante archivos de configuración, y además consultarlos en tiempo de ejecución utilizando el protocolo JMX. La implementación de este Cache tiene en consideración el requerimiento de disminución de los tiempos de respuesta, y por tal motivo se tomaron las siguientes decisiones: Crear un Cache por servicio, con el fin de acelerar las búsquedas de la información almacenada. Generar un Hash a partir del Body del mensaje SOAP de entrada, lo que permite disminuir el tiempo de acceso al Cache, al evitar acceder a las etiquetas de un XML. Permitir la configuración por servicio de los tiempos de vida, el tamaño del cache, entre otras propiedades. Para almacenar la respuesta de un servicio virtual, se debe extraer el Body de un mensaje SOAP correspondiente a una solicitud y utilizarlo para generar un Hash MD5 19, y por otra parte, se debe obtener el identificador del servicio que se pretende invocar. Luego el sub-componente Cache Manager se encarga de asociar la respuesta del servicio virtual identificado con el Hash MD5 calculado. Por lo tanto, a partir de un identificador de servicio virtual y de un valor de Hash MD5, es posible obtener una respuesta previamente almacenada como se detalla en la Figura 61. Figura 61 - Acceso al Cache de un servicio. Este componente puede ser fácilmente reutilizado en otros contextos que requieran un Cache para mensajes SOAP. Para reutilizarlo solamente es necesario agregar las dependencias 20 (ehcache-core, ehcache-terracotta, slf4j-jdk14) requeridas por la biblioteca EHCache

92 5.10 Problemas Encontrados En esta sección se detallan las diferentes problemáticas presentadas en la etapa de implementación de la Plataforma ESB Adaptativa, donde se menciona cuál fue el enfoque tomado en este proyecto para mitigar cada uno de los problemas encontrados Atributo soapaction en Servicios Virtuales equivalentes Uno de los problemas encontrados al momento de realizar invocaciones a servicios equivalentes, se debe al atributo soapaction del Header HTTP. Para este atributo no es posible definir un valor con la información disponible en la plataforma, ya que no se cuenta con ninguna relación entre las acciones de los servicios equivalentes. Para mitigar este problema se decidió reemplazar el atributo soapaction de la petición HTTP por la acción vacía, obligando de esta forma a que el servicio obtenga la acción a invocar desde el Body del propio mensaje SOAP. Otro enfoque que se puede tomar para solucionar esta problemática, es que la plataforma se encargue de almacenar información extra de sus servicios virtuales equivalentes, permitiendo relacionar así las acciones equivalentes entre ellos Service Invoker sincrónico La invocación a servicios virtuales de forma sincrónica fue otro de los problemas enfrentados durante la implementación de la plataforma, ya que luego de invocar a estos servicios es necesario almacenar las respuestas que son utilizadas por el mecanismo de cache. El problema de la invocación a estos servicios se presentaba al realizar invocaciones sincrónicas, donde el control de la ejecución no era retornado correctamente, no pudiéndose así almacenar su respuesta. Para resolver este inconveniente se debió recurrir al código fuente de la acción SynServiceInvoker de JBoss ESB, investigando cómo cargar el contexto para los llamados a los servicios, mediante las propiedades FaultTo y ReplyTo de la clase Call. Para esto se debió cargar correctamente un contexto que posibilite retornar el control al propio servicio que realiza la invocación, permitiendo así transferir temporalmente el control de la ejecución desde el servicio que realiza la invocación al que se desea invocar, y cuando éste último finalice su ejecución, retorne el control al servicio que realizó la invocación Incremento de los hilos de ejecución Otro de los problemas enfrentados en la implementación de la plataforma se debió a una mala utilización de los conectores JMX, ya que por cada invocación que se realiza utilizando este protocolo, se crea un nuevo hilo de ejecución en el servidor, el cual se encarga de procesar la solicitud realizada. A su vez, estos hilos solamente son destruidos cuando el servicio que realiza la solicitud cierra la conexión establecida. El problema enfrentado en el marco de este proyecto, se daba después de cierto tiempo de iniciado el servidor, el cual comenzaba a desplegar errores como OutOfMemoryError: unable to create new native thread, debido a la cantidad de hilos que poseía activos y que ya no se utilizaban. Estos hilos consumían recursos innecesarios, ya que nunca eran liberados e impedían la creación de nuevos hilos, debido a que se alcanzaba la máxima cantidad de hilos activos. Analizando el problema con herramientas como

93 VisualVM, se observó que el mismo era causado por no cerrar las conexiones establecidas a través de las comunicaciones JMX Problemas de performance con el servicio DeadLetter de JBoss ESB La utilización del servicio DeadLetterService en el mecanismo de adaptación Unificador de Respuestas, provocó grandes problemas de performance, ya que por cada invocación que se realiza sobre una lista de servicios equivalentes, solamente se retorna el primer mensaje recibido, almacenando en dicho servicio el resto de los mensajes no entregados. Debido a que JBoss ESB utiliza una base de datos HSQLDB 21 como mecanismo de persistencia por defecto, cuando esta base toma un tamaño cercano a los 300MB su performance se ve degradada, ya que es una base diseñada para ambientes de desarrollo y no para almacenar grades volúmenes de datos. Por esta razón, se decidió que el Unificador de Respuestas descarte los mensajes que no son entregados, en vez de enviarlos al DeadLetterService, pues en un corto período de tiempo la estrategia Distribuir Solicitud a Servicios Equivalentes genera una gran cantidad de mensajes descartados Comparador de documentos WSDL La implementación del comparador de documentos WSDL debió afrontar la problemática del tipo de style que se utiliza en el SOAPBinding de la publicación de cada servicio. El style puede ser de dos tipos: DOCUMENT o RPC. Debido al tiempo acotado de este proyecto, se decidió que el comparador soporte únicamente comparar documentos WSDL que contengan el mismo style de publicación. Para inspeccionar cada uno de los archivos se utilizó la API brindada por la biblioteca Easy WSDL [23], la cual permite abstraerse en gran parte del tipo de documento y de la versión de WSDL (1.2 o 2.0). Otro problema encontrado y que quedó fuera del alcance de este proyecto, es la posibilidad de detectar cuando un parámetro es opcional y cuando deja de serlo. Para esto se puede inspeccionar el documento WSDL y obtener para cada parámetro su valor mínimo de ocurrencia (min-occur), o utilizar algún tipo de documentación adicional que indique su opcionalidad

94 - 94 -

95 6 Caso de Estudio y Pruebas Realizadas En este capítulo se presenta un caso de estudio basado en el contexto de Gobierno Electrónico, en el cual se realizan las pruebas de la plataforma. Dichas pruebas permiten validar la mejora de los atributos de calidad de los servicios, y además, evaluar el overhead generado por las acciones de adaptación de la plataforma. En la Sección 6.1 se describe un contexto reducido de Gobierno Electrónico, en la Sección 6.2 se presentan las pruebas a las que fue sometida la implementación de la plataforma, y finalmente, en la Sección 6.3 se presentan las conclusiones del capítulo. 6.1 Caso de Estudio: Gobierno Electrónico En esta sección se presenta el caso de estudio de Gobierno Electrónico que proporciona un marco conceptual para ejemplificar las distintas estrategias de adaptación presentadas en la Sección Hoy en día, muchas instituciones del gobierno deben solicitar a los ciudadanos información que otras instituciones del Estado ya poseen, agregando procesos y tiempos innecesarios, además, dentro del propio Estado, muchas veces es necesario contar con información de diferentes organismos para tomar algún tipo de decisión. Con el fin de evitar estos inconvenientes, muchos países han utilizado tecnologías de la información para avanzar en el desarrollo de lo que se denomina Gobierno Electrónico. El desarrollo del Gobierno Electrónico es una actividad permanente, que en forma iterativa incrementa y perfecciona los servicios que brinda a los ciudadanos y al propio Estado. En consecuencia, es un ambiente en el que la evolución tecnológica y la escalabilidad obtienen gran importancia, ya que tanto los ciudadanos como los diferentes organismos del Estado son usuarios de esta plataforma. Frente a esta realidad, las arquitecturas SOA son adecuadas ya que permiten la interoperabilidad entre los organismos, así como también la reutilización y aprovechamiento de los recursos con los que cuenta el Estado. [24] En nuestro país, la Plataforma de Gobierno Electrónico (PGE) que ha implementado la Agencia para el Desarrollo del Gobierno de Gestión Electrónica y la Sociedad de la Información y del Conocimiento (AGESIC), permite y facilita la integración de los servicios ofrecidos por los organismos, proporcionando el contexto tecnológico y legal que la regula. Para esto, la PGE brinda mecanismos que apuntan a simplificar la integración entre los organismos del Estado y a mejorar la utilización de sus recursos. En particular, estos mecanismos proveen la infraestructura base que permiten la implementación de una SOA a nivel del Estado, la cual se apoya en la tecnología de Web Services. Los organismos proveen entonces sus funcionalidades de negocio a través de servicios que son descriptos, publicados, descubiertos, invocados y combinados de forma independiente a la plataforma tecnológica en la que fueron implementados. [24]

96 La Figura 62 permite visualizar las características generales de la Plataforma de Gobierno Electrónico. Figura 62 - Plataforma de Gobierno Electrónico. Extraída de [1]. La PGE se aplica sobre un contexto caracterizado por una alta distribución y heterogeneidad entre los organismos, la distribución está dada por la interacción de muchas entidades y la heterogeneidad se da tanto a nivel tecnológico como de recursos. La plataforma se basa en una arquitectura SOA, la cual cuenta con un sistema de control de acceso, un sistema de gestión de metadatos y una plataforma de middleware. Estos componentes facilitan la provisión, búsqueda e invocación de los Web Services que son brindados por los organismos, así como la interoperabilidad e interacción segura entre los mismos. Los organismos pueden utilizar esta plataforma tanto para publicar y descubrir servicios, como para utilizar las diferentes capacidades de mediación que permiten desacoplar clientes y servicios [24]. Consecuentemente, la PGE resulta un marco adecuado para realizar acciones de adaptación. El componente de middleware de la PGE cuenta con mecanismos para facilitar el desarrollo, despliegue e integración de servicios y aplicaciones. Además, está integrado con tecnología ESB, por lo que resulta un escenario interesante para ejemplificar las estrategias de adaptación descriptas en la Sección Entidades y Modelo de Datos Canónico En el marco de este proyecto, se modelan los principales conceptos presentes en el contexto de Gobierno Electrónico, donde se destaca la gran cantidad de información que deben administrar los distintos organismos, tanto de empresas como de ciudadanos. Por esta razón, y con el fin de realizar

97 pruebas que permitan verificar el correcto desempeño de las estrategias de adaptación, se resolvió modelar un conjunto reducido de entidades. Estas entidades son: Empresa y Persona. La Tabla 19 presenta el modelo de datos canónico definido para las empresas y personas de la realidad modelada, detallando cada uno de sus atributos y sus posibles valores. Persona Valores Posibles Empresa Valores Posibles Primer Nombre (.*) RUT (\d{13}) Segundo Nombre (.*) Ciudad (.*) Apellido Paterno (.*) Departamento (.*) Apellido Materno (.*) Dirección (.*) Firma (.*) Cant. Empleados (\d*) Sexo (M F) DGI al día (S N) C.I (\d.\d\d\d.\d\d\d-\d) BPS al día (S N) Tabla 19 - Modelo de datos canónico Definir este modelo de datos canónico en la plataforma permite por ejemplo, especificar una representación común de cada entidad para todos los organismos Servicios En el contexto de este caso de estudio, se consideran tres funcionalidades que utilizan las entidades antes mencionadas, con el fin de ejemplificar el uso del modelo de datos canónico entre los distintos organismos. Las funcionalidades seleccionadas son: Registro de Empresa: esta funcionalidad permite emular el registro de una nueva empresa dada su información correspondiente. Obtener Información de Empresa: esta funcionalidad permite obtener la información referente a una empresa dado el RUT correspondiente. Obtener Información de Persona: esta funcionalidad permite obtener la información referente a un ciudadano a partir de su cédula de identidad. Para consumir las funcionalidades especificadas anteriormente, se implementaron los siguientes Web Services: BPSWS, DGIWS y DNICWS. Los Web Services BPSWS y DGIWS brindan las tres funcionalidades descriptas anteriormente, mientras que DNICWS brinda únicamente la funcionalidad de obtener información referente a una persona. Cabe destacar, que los servicios BPSWS y DGIWS son equivalentes, ya que estos brindan las mismas funcionalidades, independientemente de sus representaciones de datos particulares. A su vez, el servicio DNICWS tiene como equivalentes a los demás servicios, pero esta relación no se cumple a la inversa, ya que el servicio DNICWS no posee las funcionalidades de Registro de Empresa ni Obtener Información de Empresa. La Figura 62 presenta la relación de equivalencia mencionada anteriormente

98 Figura 63 - Relación de equivalencia entre los servicios del caso de estudio Cabe destacar, que al igual que el modelo de datos canónico se definió un modelo canónico de servicios, que permite resolver posibles diferencias en los contratos de cada servicio, e invocar Web Services funcionalmente equivalentes, independientemente de sus implementaciones. La Tabla 20 presenta el modelo canónico de servicios considerado, detallando los nombres de las operaciones, sus parámetros y el formato de los mismos. Operación Parámetros Formato registrarnuevaempresa Entidad Empresa Canónico obtenerinfoempresa RUT (\d{13}) obtenerpersona C.I (\d.\d\d\d.\d\d\d-\d) Tabla 20 - Modelo canónico de servicios Escenario de prueba En esta sección se presenta el contexto reducido de la PGE, el cual permite evaluar las estrategias de adaptación propuestas. A continuación se listan los organismos que componen el contexto simplificado: BPS - Banco de Previsión Social DGI - Dirección General Impositiva DNIC - Dirección Nacional de Identificación Civil Estos organismos administran información referente a empresas y personas, pero no todos representan de la misma forma los datos de dichas entidades, por lo que no existe una representación única ni de empresas, ni de personas. Debido a esto, es necesario considerar un modelo de datos canónico, que permita describir la información de empresas y personas, independientemente de las distintas representaciones particulares de cada organismo. A continuación, la Figura 64 presenta el escenario en el cual se llevaron a cabo las pruebas sobre la Plataforma ESB Adaptativa. En dicho escenario se pueden observar los tres servicios virtuales implementados, que acceden a los servicios externos brindados por los organismos que componen el contexto reducido de la PGE. Además, se observa el modelo de datos canónicos considerado, a través de la utilización de este modelo se pueden realizar invocaciones a servicios equivalentes, ya que todos los servicios definidos poseen transformaciones que pueden transformar cada modelo particular hacia el canónico y viceversa

99 Figura 64 - Escenario de prueba Invocación a Servicio Equivalente Una de las estrategias de adaptación que se aplican en el caso de estudio es Invocación a Servicio Equivalente. En esta sección se describe lo que implicaría esta estrategia en este contexto. Supongamos que una aplicación cliente desea invocar la funcionalidad obtenerpersona del organismo BPS a través de la plataforma, y en ésta existe una directiva de adaptación vigente que invoca al servicio equivalente DNICWS. En una primera instancia, la plataforma debe transformar la representación de la solicitud original hacia el modelo canónico, en donde se transforman los parámetros correspondientes a la cédula de identidad del modelo particular de BPS hacia el modelo canónico. Una vez que la solicitud está representada en el modelo canónico de entidades, es necesario realizar una transformación hacia al modelo particular del organismo DNIC. En este último caso, la trasformación desde el modelo canónico hacia el modelo particular de DNIC debe por un lado, trasformar los parámetros que representan la cédula de identidad, modificándolos al formato particular definido por DNIC, y por el otro, renombrar la operación del modelo canónico hacia su correspondiente operación en el modelo particular. De forma análoga, se debe transformar la representación de la respuesta del servicio DNIC hacia el modelo particular de BPS, primero transformándola al modelo canónico, para luego llevarla al modelo particular de BPS. A continuación, en la Figura 65 se describen las sucesivas transformaciones que se aplican sobre el mensaje original del escenario descripto anteriormente, detallando cada uno de los pasos realizados. Las transformaciones definidas son trasformaciones XSL [25], que son la forma estándar de transformar documentos en formato XML. Inicialmente, en el paso 1 se muestra el mensaje original con el cual se realiza la petición desde la aplicación cliente hacia la Plataforma ESB Adaptativa. A continuación, se modifican los parámetros del mensaje original para transformarlos a la representación de la funcionalidad obtener información de persona del servicio canónico, tal como se observa en el paso 2 de la Figura 65. Luego, se transforma el mensaje desde el modelo canónico hacia el modelo particular de DNIC, paso 2 a 3, donde se modifica el nombre de la operación y el formato de sus parámetros. En este momento, el mensaje está preparado

100 para realizar una invocación a la funcionalidad obtener información persona, brindada por un servicio virtual que accede a los servicios del organismo DNIC. Figura 65 - Transformación desde el modelo particular de BPS hacia el modelo de DNIC. Al obtener la respuesta del servicio virtual invocado, se deben aplicar nuevamente transformaciones, que permitan transformar la respuesta obtenida al modelo particular del organismo BPS, ya que la petición original realizada por la aplicación cliente fue sobre dicho servicio, esperando recibir la respuesta en la representación particular de BPS. Estas transformaciones se realizan de manera análoga a las descriptas para invocar un servicio virtual equivalente: primero se transforma la respuesta desde el modelo particular de DNIC hacia el modelo canónico, luego se la transforma al modelo particular de BPS. 6.2 Pruebas Realizadas En esta sección, se describen las pruebas a las que fue sometida la Plataforma ESB Adaptativa, detallando en cada una de ellas los resultados obtenidos. Dichas pruebas están enfocadas en validar la mejora de los atributos de calidad tenidos en cuenta en la solución planteada, mediante el uso de flujos de adaptación, así como también evaluar el overhead generado por la plataforma en el procesamiento de cada petición. En forma paralela a las pruebas antes mencionadas, se analizó el consumo de recursos que realiza la plataforma, con el fin de validar que ésta pueda ser utilizada en un contexto real, y que no sufra memory leaks, cpu bursts prolongados o problemas de concurrencia

101 Para la simulación de las invocaciones a los servicios registrados en la plataforma, se utilizó la herramienta SoapUI v , mientras que para el monitoreo de los recursos consumidos se utilizó la herramienta VisualVM v Las pruebas se realizaron en una PC de escritorio sobre un hardware con 4GB de RAM y un procesador con doble núcleo de 3.2Ghz. La Plataforma ESB Adaptativa y los Servicios Virtuales utilizados para realizar las pruebas se despliegan en el mismo servidor de aplicaciones (JBoss 6), el cual se localiza en una máquina virtual (Virtual Box v4.1.16) que prioriza los procesos Java que son ejecutados en dicha máquina Prueba sobre atributos de calidad Esta prueba, consiste en verificar que la implementación de la plataforma mejora los atributos de calidad de los servicios virtuales, en un contexto simplificado de Gobierno Electrónico. El servicio utilizado para estas pruebas es aquel que representa el organismo DNIC, definido en la Sección 6.1.1, el cual cuenta con una sola operación y dos servicios equivalentes, BPSWS y DGIWS. En esta prueba se registran los tiempos de respuesta y el porcentaje de respuestas exitosas para cada invocación realizada sobre dicho servicio, con el fin de cuantificar los resultados obtenidos y evaluar los atributos de calidad mencionados en la Sección Se configuran las siguientes propiedades para armar un escenario en donde los servicios equivalentes de DNICWS poseen un menor tiempo de respuesta, lo que permite evaluar si las invocaciones a servicios equivalentes logran mejorar los atributos de calidad: El tiempo de respuesta de este servicio se incrementa aleatoriamente en el entorno de 800ms y 1200ms, para permitir que sus servicios virtuales equivalentes posean un menor tiempo de respuesta. El 10% de los pedidos que se realizan retornan un error, simulando un problema en el nodo que expone este servicio. Este servicio puede procesar como máximo 1500 peticiones por minuto, sobrepasando este límite, el servicio deja de responder. Para el servicio virtual registrado en la plataforma que accede al servicio DNICWS, se define la siguiente metadata: Tiempo de respuesta máximo: 250ms. Porcentaje de tolerancia a invocaciones no exitosas : 0% Tiempo de espera para la estrategia de retardo: 100ms. Cantidad máxima de invocaciones que puede procesar el servicio: 800/min. El tiempo de vida de las estrategias generadas por la plataforma es de 200s

102 La Figura 66 presenta de forma gráfica la configuración antes mencionada. Figura 66 - Configuración de los servicios externos a la plataforma. Cabe destacar que para los servicios virtuales que acceden a los Web Services BPSWS y DGIWS, se deshabilitan las estrategias de adaptación generadas por la Plataforma ESB Adaptativa. Otro punto a resaltar, es el tiempo de respuesta que poseen estos servicios, el cual no supera los 50ms. En esta prueba se invoca al método obtenerinformacionpersona del servicio DNICWS, para el cual aproximadamente un 10% de sus solicitudes son idénticas, lo que permite verificar el correcto funcionamiento del cache implementado. Para obtener una medida de la eficacia de la plataforma, se realizaron dos tipos de invocaciones sobre los servicios virtuales, una invocación directa sobre dichos servicios, y otra a través de la Plataforma ESB Adaptativa, esta última con todas sus funcionalidades activas (Mecanismos de Monitoreo, Estrategias de Adaptación, etc.). En la Tabla 21 se muestran los resultados obtenidos de las invocaciones al servicio DNIC, utilizando un pool máximo de 60 hilos de ejecución durante un período de 15 min, es decir que en dicho período se obtienen como máximo 60 invocaciones concurrentes al servicio. Tipo de Invocación Cant. invocaciones procesadas Tiempo respuesta promedio (ms) Errores Invocaciones exitosas Invocación directa % Invocación a través del ESB Adaptativo % Tabla 21 - Datos obtenidos en la prueba de atributos de calidad Los resultados presentados anteriormente permiten observar claramente la mejora de la cantidad de invocaciones exitosas, así como también la disminución de los tiempos de respuesta promedio, mejorando así la degradación de calidad del servicio. Adicionalmente, se observa un gran incremento de las peticiones procesadas, esto se debe a que al invocar a través la plataforma se utilizan los

103 mecanismos de cache y servicios equivalentes, que permiten responder las solicitudes con mayor rapidez. En la Tabla 22 se presentan los porcentajes de invocaciones realizadas sobre cada uno de los servicios considerados en esta prueba, incluyendo además, el gran beneficio de la utilización del mecanismo de cache. Como se puede observar, solamente un 57% de la invocaciones realizadas, son procesadas por el propio servicio DNIC, mientras que el 43%, se distribuye entre sus servicios equivalentes y el mecanismo de cache, lo cual permite evitar la saturación de dicho servicio. Servicio Cantidad total de pedidos Porcentaje del total BPSWS % DGIWS % DNICWS % Cache % Tabla 22 - Porcentaje de invocaciones por servicio Prueba de cambios de contrato En esta prueba se realizan cambios de contrato sobre ciertas operaciones del servicio BPSWS, para luego invocar dicho servicio a través de la plataforma, como si el mismo no hubiera sufrido ningún tipo de cambio. Esta prueba permite evaluar que se monitoreen los cambios de contrato del servicio y se generen las transformaciones necesarias, las cuales permitan accederlo de forma trasparente desde la perspectiva del cliente que realiza la invocación. Se debe tener en cuenta que en esta prueba, no se puede realizar una comparativa entre la invocación directa al servicio virtual y la invocación a través de la plataforma, ya que la invocación directa retorna una excepción en la mayoría de los casos, debido al cambio de contrato realizado. La Tabla 23 detalla los resultados obtenidos de las invocaciones realizadas para cada uno de los cambios de contrato de esta prueba. Cambio realizado Descripción Detectado Invocación Agregar Operación Se agrega la operación nuevaoper. Si Exitosa Agregar Parámetro Renombrar operación Renombrar Parámetro Eliminar Parámetro Se agrega el parámetro nuevoparam al método obtenerinfoempresa. Se renombra el nombre de la operación registroempresa a registroempresanueva. Se renombra el nombre del parámetro miles a mil del método obtenerpersona. Se elimina el parámetro digitoverificacion del método obtenerpersona. Si Si Si Si Exitosa Exitosa Exitosa Exitosa Tabla 23 - Resultados obtenidos para los cambios de contrato

104 Según los resultados presentados anteriormente, la plataforma detecta correctamente los cambios de contratos soportados por la misma, permitiendo continuar invocando el servicio virtual de forma transparente, sin alterar considerablemente sus tiempos de respuesta Prueba de overhead en las invocaciones Esta prueba, permite cuantificar el overhead generado por la plataforma para cada una de las estrategias implementadas. La comparación se realiza en base a los datos obtenidos de 1200 invocaciones sobre el servicio DNIC, registrando para cada una de las estrategias utilizadas, sus tiempos de procesamiento, los cuales son utilizados para realizar una comparativa con la invocación directa al servicio virtual. A continuación, la Tabla 24 presenta los valores obtenidos en la prueba realizada. Estrategias Max (ms) Min (ms) Promedio (ms) OverHead (ms) Invocación Directa No posee Sin estrategia Cache No posee Retardo (100ms) Cambio de Contrato Servicio Equivalente Lista de Destinatarios Balanceo de Carga Tabla 24 - Resumen del overhead generado por las estrategias Los datos obtenidos reflejan valores muy aceptables para los tiempos de procesamiento de las estrategias implementadas, siendo en la mayoría de los casos inferiores a 200ms. Para la estrategia de invocación a una lista de servicios equivalentes, el procesamiento de las transformaciones desde y hacia el modelo de datos canónicos genera un aumento considerable en el tiempo de procesamiento, además del tiempo requerido para la copia de los distintos mensajes. Cabe resaltar, que la mayor parte del tiempo de procesamiento se debe a dicha copia, ya que su implementación en JBoss ESB no es eficiente. Esta copia no se puede evitar, pues en la estrategia de lista de destinatarios cada uno de los servicios destino debe recibir una copia del mensaje original, no siendo posible que éstos compartan el mismo espacio de memoria Consumo de recursos por parte de la plataforma Junto con las pruebas anteriormente descriptas, se realizaron monitoreos acerca de la utilización de recursos por parte de la Plataforma ESB Adaptativa, permitiendo evaluar el desempeño de la misma cuando es sometida a una carga de procesamiento considerable. En este monitoreo, se evalúa el uso de recursos como la memoria, los hilos de ejecución y la utilización de la CPU, para cada una de las estrategias implementadas. En la Figura 67 se presenta un esbozo gráfico de la utilización de la CPU por intervalo de tiempo, detallando para cada caso relevante, las estrategias utilizadas. En el intervalo 1 de dicha Figura, se localizan las estrategias de retardo, cache e invocación a servicios equivalentes, además de la invocación

105 sincrónica al propio servicio. En este intervalo el uso de la CPU es normal, no superando el 40%. En el intervalo 2, se localiza la estrategia de invocación a lista de destinatarios, en la cual se puede observar un incremento considerable del uso de la CPU, debido a la gran utilización de transformaciones por parte de esta estrategia y a la copia de los mensajes. Finalmente, en el intervalo 3, el uso de la CPU vuelve a ser normal, no sobrepasando el 30%, dado por el poco procesamiento de transformaciones de la estrategia balanceo de carga. Figura 67 - Consumo de CPU. La Figura 68 presenta el gráfico de la utilización de memoria por intervalo de tiempo, detallando al igual que en la Figura 67, aquellos intervalos relevantes. Cabe resaltar, que la utilización de este recurso se realiza de manera eficiente, no teniendo por ejemplo memory leaks 24, lo cual se puede apreciar en la forma de cierra del gráfico presentado. Los picos más altos de consumo de memoria se producen con la estrategia de invocación a lista de destinatarios, obteniendo en algunos casos valores cercanos a los 480MB. Finalmente, se puede apreciar que el consumo en el inicio de la prueba y en el final de la misma, son bastante similares, exceptuando aquellos objetos que son creados por la plataforma y no son liberados, ya que son utilizados para aumentar la performance de la plataforma. Por ejemplo, los flujos de adaptación de cada servicio. 24 Memory leaks: es un error de software que ocurre cuando un bloque de memoria reservada no es liberada en un programa de computación

106 Figura 68 - Consumo de Memoria RAM. Finalmente, la Figura 69 presenta la cantidad de hilos que son creados en el contexto de esta prueba, donde se aprecian dos grandes intervalos, uno al comienzo de la prueba y otro cuando comienza la estrategia de lista de destinatarios. Este último intervalo aumenta la cantidad de hilos que utiliza la plataforma, debido a que por cada invocación realizada, la estrategia lista de destinatarios invoca a todos sus servicios equivalentes, procesando varias transformaciones y creando nuevos hilos que permitan llamar los servicios equivalente de forma paralela. Notar que la cantidad de hilos creados no disminuye, esto es debido a que el servidor JBoss ESB mantiene estos hilos en estado IDLE por un determinado período de tiempo. Figura 69 - Consumo de hilos de ejecución. 6.3 Conclusiones En ese capítulo se presentó el contexto reducido de Gobierno Electrónico en el cual fueron detalladas las pruebas realizadas sobre la Plataforma ESB Adaptativa. Dichas pruebas demuestran que la plataforma con esta implementación permite mejorar los atributos de calidad de un servicio, en todos los escenarios que fueron desarrollados, utilizando todas las estrategias implementadas, y los servicios equivalentes disponibles. En aquellos casos donde sea posible utilizar la estrategia de información almacenada, se obtienen mejores tiempos de respuesta, porcentaje de repuestas exitosas y cantidad de invocaciones procesadas

107 por segundo, esta última está relacionada directamente con la baja significativa de los tiempos de respuesta. Con respecto al escenario de cambio de contrato, la plataforma en pocos segundos permite que las invocaciones al servicio sean exitosas, lo cual en este contexto representa una gran mejora. Esta mejora está dada porque los clientes que consumen dicho servicio pueden demorar horas, o días en actualizar sus contratos, lo que deja inaccesible al servicio durante un gran período de tiempo. Por otra parte, el consumo de recursos que realiza la plataforma es el esperado, para el cual se observa un gran consumo de CPU cuando se utilizan transformaciones XSLT y copias de mensajes. Estos inconvenientes pueden ser mejorados con un hardware más acorde a la situación y una implementación más eficiente para la copia de mensajes. A su vez, la estrategia de lista de destinatarios es la que mayor consumo de recursos realiza, por lo cual su implementación puede ser mejorada en trabajos futuros. Si bien las pruebas se pudieron realizar satisfactoriamente, estas no fueron realizadas sobre un contexto real, lo que no garantiza el correcto desempeño de la plataforma en cualquier contexto

108

109 7 Conclusiones del Trabajo En este capítulo se presentan las conclusiones del trabajo realizado. En la Sección 7.1 se presenta un resumen del trabajo y sus principales contribuciones, y en la Sección 7.2 se comentan posibles trabajos a futuro. 7.1 Resumen y Contribuciones Este proyecto consistió en la implementación de una plataforma adaptativa, tomando como base un producto ESB existente, extendiendo sus funcionalidades para aplicar acciones de adaptación en sistemas orientados a servicios. Además, se desarrollaron pruebas sobre un contexto reducido de Gobierno Electrónico, que demuestran que la plataforma implementada contribuye a la mejora de los atributos de calidad de los servicios, agregando poco overhead al procesamiento de sus acciones de adaptación. En una primera etapa del proyecto se analizaron diferentes productos ESB existentes en el mercado, con el fin de seleccionar el producto que contara con las mejores cualidades de acuerdo al contexto de este proyecto. Este análisis permitió seleccionar a JBoss ESB como el producto base para la implementación de la plataforma, debido a su buena documentación y a su amplio conjunto de capacidades de mediación. El análisis permitió comprobar además que los ESB analizados presentan gran nivel funcional, pero no poseen un nivel de documentación acorde a sus capacidades de mediación. Luego, tomando como base el producto JBoss ESB se implementó una plataforma que permite abordar necesidades de adaptación que surgen por la degradación de la calidad de servicio, la saturación de servicios y cambios en los contratos de servicios. Adicionalmente a los objetivos planteados, se implementó un Motor de Administración y Monitoreo funcional, que es capaz de tomar decisiones esenciales de adaptación y de monitoreo, determinando los pilares para un desarrollo futuro de un motor más complejo. Dada la necesidad de facilitar la administración y configuración de la Plataforma ESB Adaptativa, se implementó una consola de administración que permite de forma gráfica, configurar, administrar y monitorear los distintos aspectos de la plataforma. Por último, se quiere resaltar que la implementación de la plataforma fue realizada desde un principio teniendo en cuenta un alto nivel de extensibilidad, lo que permite incorporar fácilmente nuevas funcionalidades. Finalmente, para validar el funcionamiento de la plataforma se diseñó un escenario de prueba basado en el contexto de Gobierno Electrónico. Si bien las pruebas realizadas fueron acotadas y no representaron un escenario de producción real, demostraron que la plataforma con la implementación realizada mejora los atributos de calidad de los servicios. Esto se debe a que el overhead agregado por los mecanismos internos de la plataforma es insignificante en relación a las mejoras que se generan. Además, se concluye que las estrategias implementadas permiten abordar eficazmente las necesidades de adaptación consideradas en el diseño de la plataforma

110 Como conclusión general, el trabajo realizado demuestra que la implementación de una plataforma adaptativa es viable para sistemas basados en Web Services, siguiendo las ideas propuestas en Plataforma ESB Adaptativa para Sistemas Basados en Servicios y utilizando las capacidades de mediación brindadas por JBoss ESB. Como principales contribuciones del proyecto se destacan: Implementación de una plataforma adaptativa que permite realizar adaptaciones de forma dinámica, automática y en tiempo de ejecución, basándose en la propuesta Plataforma ESB Adaptativa para Sistemas Basados en Servicios. Implementación de mecanismos de adaptación y de monitoreo concretos, que permiten abordar necesidades de adaptación que surgen por la degradación en la calidad de los servicios, la saturación y los cambios en los contratos de los servicios. Diseño e implementación de componentes para la plataforma JBoss ESB, que pueden ser reutilizados en otros proyectos de igual dominio. En particular, se implementaron los mecanismos de adaptación Ruteo Basado en Itinerario y Cache. Desarrollo de las principales funcionalidades de los distintos componentes del Motor de Adaptación y Monitoreo, que implementan decisiones esenciales de adaptación según los distintos datos monitoreados. La implementación de este motor está totalmente desacoplada de los demás componentes que conforman la plataforma. 7.2 Trabajo a Futuro Durante el transcurso de este proyecto se identificaron funcionalidades y aspectos de la solución que podrían ser mejorados, pero debido a los tiempos acotados para este trabajo estas ideas no fueron desarrolladas, por lo que se presentan como líneas de trabajo a futuro Extender las comunicaciones JMX Actualmente, la comunicación entre los principales componentes de la plataforma se realiza utilizando el protocolo de mensajería JMX, lo que implica que todos los componentes de la plataforma deban estar implementados en Java. Se propone como línea de trabajo a futuro, extender dichas comunicaciones a un nivel más distribuido, utilizando HTTP o Web Services. Esto permitiría, por ejemplo, tener el ESB Adaptativo, el Motor de Adaptación y Monitoreo y la Consola de Administración implementados en distintas plataformas, y además, poder acceder a ellos remotamente a través de internet. Para implementar esta extensión, se podría por ejemplo, utilizar el protocolo WS-Management 25, o algún conector SOAP para JMX como MX4J 26. [26]

111 7.2.2 Directivas Administradas por el usuario En la solución desarrollada, el usuario puede consultar la directiva de adaptación que se aplica a un determinado servicio, pero no pude modificarla. Se plantea como una línea de trabajo a futuro la posibilidad de extender la plataforma, implementando las funcionalidades requeridas para que el usuario final pueda alterar las directivas de adaptación de un servicio, permitiendo tanto cancelar, crear y modificar directivas, como alterar sus tiempos de vida Estadísticas de las directivas procesadas Las estadísticas de los servicios virtuales son datos relevantes para ajustar la configuración de la plataforma y analizar su correcto funcionamiento, también pueden servir como entrada para el Motor de Adaptación y Monitoreo, colaborando en la elección de una directiva de adaptación más eficiente para un determinado servicio. En la plataforma implementada se almacena un registro histórico de las directivas de adaptación de cada servicio virtual. Se podría agrupar dicho histórico con la información de las propiedades monitoreadas, la metadata de los servicios y sus tiempos de respuesta, y mostrar gráficamente toda esta información en la Consola de Administración, permitiendo así visualizar el funcionamiento de la plataforma. Además, toda la información podría ser utilizada para mejorar las decisiones de adaptación que realiza el Motor de Administración y Monitoreo Manejar el vencimiento de las Directivas de Adaptación La plataforma adaptativa solo mantiene una directiva de adaptación por servicio, lo que implica que cuando una directiva expira, existe un tiempo donde un servicio puede requerir una nueva adaptación que la plataforma aún no detectó. Las pruebas realizadas detectaron que estos casos degradan rápidamente los atributos de calidad de la plataforma, por lo que sería interesante incorporar alguna nueva funcionalidad que permita manejar el vencimiento de las directivas de adaptación. La mejora planteada puede ser implementada en el Motor de Adaptación y Monitoreo, quien debería forzar que una directiva de adaptación sea sustituida antes de su vencimiento. Otra opción es extender el ESB Adaptativo para que soporte más de una directiva de adaptación por servicio Motor de adaptación Multi-ESB-Adaptativo Como se menciona en la Sección 4.3.9, el Motor de Adaptación y Monitoreo tiene la responsabilidad de implementar la lógica que permite tomar decisiones respecto a la estrategias que se aplican sobre los servicios virtuales. Dicha lógica puede ser reutilizada si el Motor de Adaptación y Monitoreo es extendido para trabajar con varios ESB Adaptativos. Se plantea la posibilidad de extender la implementación actual de la plataforma, permitiendo registrar varios ESB Adaptativos y brindar mecanismos que permitan conocer sus servicios de adaptación

112 7.2.6 Mejorar la selección de la directiva de Adaptación Para aquellos casos en los que un servicio posee varios requerimientos no satisfechos, o existen varias estrategias de adaptación para un mismo requerimiento, la implementación actual del Motor de Adaptación y Monitoreo selecciona de forma aleatoria una de las distintas estrategias que se pueden utilizar. La implementación de un motor de decisión basado en heurísticas y/o conocimientos históricos, permitiría generar directivas de adaptación más eficaces, dado que las decisiones tomadas de esta forma contemplarían tanto las directivas generadas para un servicio específico, como las generadas para el resto de los servicios registrados en la plataforma Mecanismos de alerta Actualmente la plataforma cuenta con información que posibilita una implementación de mensajes de alerta. Se podría implementar por ejemplo, alertas que notifiquen la presencia de patrones de degradación de los servicios, permitiendo detectar problemas antes que sea necesario realizar acciones de adaptación. Además, las alertas podrían ser detectadas y enviadas de forma automática a los administradores de los servicios Metadata de los servicios definida en intervalos de tiempo En la implementación actual de la plataforma se supone que los servicios registrados mantienen sus requerimientos incambiados durante un período de tiempo prolongado. Dada la realidad actual de los planes elásticos de Cloud Computing, como lo es el servicio Amazon Elastic Compute Cloud 27, los requerimientos de cada servicio podrían llegar a variar considerablemente según las horas o los días. Se propone como línea de trabajo a futuro, el diseño y la implementación de mecanismos que permitan definir metadata para intervalos de meses, días u horas, y de esta manera lograr que la plataforma adaptativa detecte de forma más eficaz los requerimientos de cada servicio Mecanismos de monitoreo con tiempos independientes Como se plantea en la Sección 5.3, la plataforma actual tiene la limitante de calcular todas las propiedades cada un intervalo de tiempo fijo, esto supone que los mecanismos de monitoreo son igualmente sensibles al paso del tiempo, lo que no siempre se corresponde con la realidad. Para definir distintos intervalos de monitoreo y de cálculo de propiedades, se deben tener en cuenta aspectos que actualmente la plataforma no contempla. Se deberían incorporar funcionalidades que permitan que el ESB-Adaptativo y el Motor de Adaptación y Monitoreo manejen conjuntos parciales de las propiedades monitoreadas, lo que implicaría un gran cambio sobre la plataforma implementada, siendo una línea de trabajo a futuro muy interesante

113 Definir equivalencias a nivel de Operaciones Actualmente la plataforma permite definir relaciones de equivalencia únicamente a nivel de servicios, donde un servicio es equivalente a otro solamente si existe una relación de equivalencia entre cada una sus operaciones. Se propone como línea de trabajo a futuro, mejorar la definición de equivalencia para poder soportar equivalencia a nivel de operaciones, lo que implicaría definir para cada operación de un servicio, otra operación que pueda ser invocada de manera equivalente. De esta forma se lograría tener un conjunto mayor de operaciones equivalentes, que permitirían maximizar la eficacia de las estrategias que utilizan invocaciones a servicios equivalentes Mejorar el comparador de WSDL El mecanismo desarrollado para comparar documentos WSDL y detectar los cambios en los contratos de los servicios, solamente detecta un conjunto reducido de las posibles alteraciones que puede sufrir el contrato de un servicio. Se plantea como línea de trabajo a futuro extender la implementación actual de este comparador, con el propósito de soportar aquellos casos que no son contemplados actualmente, como por ejemplo, el reordenamiento de los parámetros de una operación y el cambio en la opcionalidad de un parámetro

114

115 8 Referencias [1] González, Ing. Laura, «Plataforma ESB Adaptativa para Sistemas Basados en Servicios,» Montevideo, Agosto, [2] accenture, «Arquitectura Orientada a Servicios (SOA),» [En línea]. Available: [3] Martin Darío Amagro, Jesús Enrique Londoño, Julían Andrés Zapata, «Service oriented architecture in the enterprise architecture field,» Revista de Avances en Sistemas e Informático, vol. 7, pp , [4] Chappell, David, «Enterprise Service Bus,» de Enterprise Service Bus: Theory in Practice, [5] Krzysztof Zielinski and Tomasz Szydlo and Robert Szymacha and Jacek Kosinski and Joanna Kosinska and Marcin Jarzab, «Adaptive SOA Solution Stack,» IEEE T. Services Computing, pp , [6] W3C, «Web Services Architecture,» [En línea]. Available: [Último acceso: Mayo 2012]. [7] W3C, «Web Services Description Language (WSDL) Version 2.0 SOAP 1.1 Binding,» [En línea]. Available: [Último acceso: Mayo 2012]. [8] W3C, «SOAP Specifications,» [En línea]. Available: [Último acceso: Mayo 2012]. [9] OASIS, «UDDI Version 3.0.2,» [En línea]. Available: [Último acceso: Mayo 2012]. [10] Papazoglou, Michael, and Willem-Jan Heuvel, Service oriented architectures: approaches, technologies and research issues, The VLDB Journal 16: , [11] IBM, «Patterns: Implementing an SOA Using an Enterprise Service Bus,» [En línea]. Available: [Último acceso: Mayo 2012]. [12] G. H. a. B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions., Addison-Wesley Professional, [13] IBM, [En línea]. Available: [Último acceso: Noviembre 2012]. [14] IBM, «Cache mediation pattern specification: an overview,» [En línea]. Available: [Último acceso: Junio 2012]. [15] DZone, «Java Management Extensions,» [En línea]. Available: [16] The YAWL Foundation, «YAWL Manuals,» [En línea]. Available: [Último acceso: Junio 2012]

116 [17] CENATIC, «ASPECTOS TECNOLÓGICOS,» [En línea]. Available: [Último acceso: Junio 2012]. [18] «11 Of Best Opensource ESB Tools,» [En línea]. Available: [Último acceso: Junio 2012]. [19] DZone, «Top Open Source ESB Projects,» [En línea]. Available: [Último acceso: Junio 2012]. [20] O. Alliance, «The OSGi Architecture,» [En línea]. Available: [Último acceso: Septiembre 2012]. [21] Community, JBoss, «Programmers Guide,» [En línea]. Available: [Último acceso: Junio 2012]. [22] SOA Membrane, «Open Source SOA & Integration,» [En línea]. Available: [Último acceso: Noviembre 2012]. [23] OW2 Consortium, «EasyWSDL Toolbox,» [En línea]. Available: [Último acceso: Junio 2012]. [24] AGESIC, «Plataforma de EGob,» [En línea]. Available: [Último acceso: Octubre 2012]. [25] W3C, «The Extensible Stylesheet Language Family,» [En línea]. Available: [Último acceso: Octubre 2012]. [26] UserException, «Monitorizando componentes usando JMX,» [En línea]. Available: [Último acceso: Noviembre 2012]. [27] Apache, «Apache Synapse,» [En línea]. Available: [Último acceso: Mayo 2012]. [28] «ServiceMix,» [En línea]. [Último acceso: Mayo 2012]. [29] ServiceMix, «ServiceMix,» [En línea]. Available: [Último acceso: Mayo 2012]. [30] RedHat, «JBOSS ENTERPRISE SOA PLATFORM,» [En línea]. Available: [Último acceso: Mayo 2012]. [31] JBoss, «JBoss ESB,» [En línea]. Available: [Último acceso: Mayo 2012]. [32] OpenESB Community, «Open ESB,» [En línea]. Available: [Último acceso: Junio 2012]. [33] OpenESB, «Open ESB Architecture,» [En línea]. Available: [Último acceso: Junio 2012]. [34] MuleSoft, «What is Mule ESB?,» [En línea]. Available:

117 [Último acceso: Mayo 2012]. [35] W3C, «W3C XML Schema,» [En línea]. Available: [Último acceso: ]. [36] AS3 Studio, «Adaptaive SOA Approach,» [En línea]. Available: Studio/?q=ASOAapproach. [Último acceso: Agosto 2012]. [37] W3C, «Web Services Addressing (WS-Addressing),» [En línea]. Available: [Último acceso: Octubre 2012]

118

119 Apéndice 1. Estrategias de Adaptación En este apéndice se detallan todas las estrategias de adaptación presentadas en la Sección 2.5.4, las cuales permiten abordar la degradación en la calidad de los servicios, la saturación de servicios y los cambios en los contratos de los servicios. Invocar Servicio Equivalente Esta estrategia consiste en invocar un servicio equivalente para un Servicio Virtual que requiera una necesidad de adaptación. Concretamente, esta estrategia permite abordar las siguientes necesidades de adaptación: Degradación de la calidad: Considerando esta necesidad, se podría mejorar el tiempo de respuesta de un servicio si se invoca un servicio equivalente con menor tiempo de respuesta. También se lograría mejorar el porcentaje de respuestas exitosas si el servicio equivalente así lo permite. Cambio de contrato: Para abordar la necesidad de cambio de contrato de un servicio, esta estrategia permite invocar a un servicio equivalente que preste las mismas funcionalidades del servicio original. El real aporte de esta estrategia se presenta en aquellos casos donde la estrategia Modificar Solicitud y Respuesta no se puede aplicar. En la Figura 70 se muestra un flujo de adaptación que representa la estrategia Invocación a Servicio Equivalente. Dicho flujo está compuesto por servicios de adaptación que utilizan mecanismos de transformaciones. En una primera instancia se aplican dos transformaciones (TRN-1 y TRN-2), que permiten ajustar el mensaje SOAP recibido a la interfaz del servicio equivalente, luego se aplican otras dos transformaciones (TRN-3 y TRN-4), para ajustar el mensaje SOAP de respuesta del servicio equivalente a la interfaz del servicio original. Figura 70 - Implementación de estrategia de invocación a servicio equivalente. Distribuir Solicitud a Servicios Equivalentes Esta estrategia consiste en enviar una solicitud a varios servicios, que sean equivalentes al Servicio Virtual original, para luego responder a la aplicación cliente a partir de la primera respuesta obtenida. En particular, esta estrategia permite abordar la siguiente necesidad de adaptación: Degradación de la calidad: Con respecto a esta necesidad, al invocar a varios servicios equivalentes se tiene más posibilidades de que alguno de ellos tenga un menor tiempo de respuesta que el Servicio Virtual original, por ende los tiempos de respuesta disminuyen. De

120 manera similar, hay más posibilidades de obtener alguna respuesta exitosa si se envía la solicitud a varios servicios equivalentes. La Figura 71 despliega un flujo de adaptación el cual representa una posible estrategia de Distribuir Solicitud a Servicios Equivalentes. Este flujo utiliza los mecanismos de lista de destinatarios, transformaciones y el unificador de respuestas. Figura 71 - Implementación de la estrategia para distribuir solicitudes a servicios virtuales equivalentes. Balancear Carga Esta estrategia permite distribuir uniformemente las diferentes solicitudes a un Servicio Virtual entre sus servicios equivalentes. Con respecto a las necesidades de adaptación, esta estrategia permite abordar la siguiente necesidad: Saturación: Esta estrategia reduce claramente la cantidad de invocaciones que un servicio procesa por período de tiempo, debido a la distribución uniforme que la misma realiza. La Figura 72 muestra un flujo de adaptación que representa esta estrategia. Este flujo utiliza los mecanismos de ruteo intermediario y transformaciones. Figura 72 - Ejemplo de una implementación de la estrategia que balancea la carga. Utilizar Información Almacenada Esta estrategia utiliza información almacenada en invocaciones previas de un servicio, generando una respuesta sin la necesidad de invocar directamente al Servicio Virtual. Específicamente, esta estrategia permite abordar las siguientes necesidades de adaptación:

121 Degradación de la calidad: Con respecto a esta necesidad, disponer de información previamente almacenada, puede ser útil tanto para incrementar las respuestas exitosas de un servicio que no esté siempre disponible, como para disminuir sus tiempos de respuesta. Saturación: Para abordar la saturación de servicios, esta estrategia permite generar una respuesta sin la necesidad de invocar a un Servicio Virtual. Consecuentemente, se reduce la cantidad de invocaciones que llegan a un servicio saturado. Cambio de contrato: Para abordar la necesidad de cambio de contrato de un servicio, esta estrategia permite generar respuestas utilizando información previamente almacenada, sin la necesidad de realizar la invocación a un servicio que modificó su contrato. La Figura 73 presenta un flujo de adaptación que constituye la estrategia Utilizar Información Almacenada para cierto Servicio Virtual. Este flujo utiliza el mecanismo de cache el cual se encargará de retornar directamente una respuesta en caso de poseer información previamente almacenada. Diferir Pedidos Figura 73 - Implementación de estrategia que utiliza información almacenada. Esta estrategia recibe un mensaje y posterga su entrega por un determinado período de tiempo. Concretamente, esta estrategia permite abordar la siguiente necesidad de adaptación: Saturación: Esta estrategia permite reducir el número de solicitudes que recibe un servicio por período de tiempo. La estrategia tiene como objetivo diferir pedidos para que el servicio no procese más solicitudes de las que puede soportar. La Figura 74 muestra el flujo de adaptación que representa a la estrategia encargada de diferir los pedidos a un Servicio Virtual. Figura 74 - Implementación de la estrategia para diferir pedidos

122 Modificar Solicitud y Respuesta Esta estrategia tiene la capacidad de modificar tanto un mensaje de solicitud a un Servicio Virtual, así como también su respuesta. Específicamente, esta estrategia aborda la siguiente necesidad de adaptación: Cambio de contrato: Para abordar esta necesidad, la estrategia permite manipular el mensaje de solicitud/respuesta de un servicio, de forma tal que se pueda seguir invocando a las operaciones que sufrieron algún tipo de cambio. La Figura 75 presenta una forma de implementar esta estrategia en el ESB utilizando los mecanismos de ruteo y transformaciones. Figura 75 - Implementación de la estrategia para invocar servicios con cambios de contrato

123 Apéndice 2. Principales Características de los Productos ESB Este apéndice presenta el relevamiento completo de los productos Apache Synapse y Apache ServiceMix, JBoss ESB, OpenESB y Mule ESB, el cual permitió seleccionar el producto ESB más adecuado a las necesidades de este proyecto. Apache Synapse ESB Apache Synapse es un software libre y de código abierto. Es un ESB ligero y de alto rendimiento que proporciona muy buen soporte para manear documentos XML, Web Services y servicios REST, siendo compatible con varios formatos de intercambio de contenido. Adicionalmente, su amplia gama de adaptadores permite comunicar muchas aplicaciones a través de diversos protocolos de la capa de transporte. [27] Características brindadas Es un ESB que soporta la mayoría de las funcionalidades de los modelos de ESB teóricos. Es sencillo de configurar y de utilizar, además la calidad de su documentación es buena comparada con otros ESB Open Source. Provee soporte a HTTP/S, Mail (POP3, IMAP, SMTP), JMS, TCP, UDP, VFS, SMS, XMPP and FIX. También soporta transformación de mensajes (XSLT, Scripting). Dispone de ruteos dinámicos a través de XPath o a través de expresiones regulares, donde un mensaje puede tener un destino diferente según su estructura. Posee un balanceador de carga, el cual es configurable según distintos algoritmos de balanceo. Las funciones de monitoreo de este ESB se delegan a los logs del sistema. Sin embargo, existen herramientas Open Source (como WSO2 Carbon), que lo convierten en una herramienta gráfica que brinda facilidades de monitoreo. Permite implementar fácilmente un gateway de aplicación a partir de uno de sus componentes nativos

124 Arquitectura La Figura 76 presenta la arquitectura de los componentes del producto Apache Synapse, detallando sus conectores y protocolos. Service Mix ESB Figura 76 - Arquitectura del producto Apache Synapse. Extraído de [27]. Apache ServiceMix es un contenedor de integración flexible y de código abierto que unifica las características y funcionalidades de Apache ActiveMQ, Camel, CXF, ODE y Karaf en una plataforma de ejecución de gran alcance. ServiceMix está basado en JBI, y tiene el objetivo de permitir que los componentes y servicios se integren de una manera independiente a los proveedores. [28] Características brindadas Es un ESB basado en la especificación JBI. Soporta múltiples protocolos de transporte como por ejemplo JMS, HTTP, FTP, Sistema de ficheros, entre otros. Dispone de una consola web para tareas de administración, además de un IDE gráfico que permite la generación de Proyectos ESB. Posee motor de orquestación de servicios BPEL. Permite transformación de documentos XML a través de XSLT y XSLTComponent. Dispone de ruteo basado en contenido a partir de expresiones XPath sobre mensajes XML normalizados Posee distintas estrategias de almacenamiento de cache

125 Posee motor de orquestación de servicios BPEL. La intercepción de mensajes se puede realizar utilizando SEDA y JMS flows. El producto puede ser integrado de forma nativa con JBoss AS, Apache Geronimo o JOnAS. Arquitectura La Figura 77 presenta la arquitectura del ESB ServiceMix, donde se detallan sus principales componentes. JBoss ESB Figura 77 - Arquitectura del producto ServiceMix. Extraída de [29]. JBoss Enterprise SOA Platform incluye middleware de código abierto para soportar arquitecturas orientadas a servicios (SOA), uno de sus principales productos es JBoss Enterprise Service Bus (ESB), que permite integrar aplicaciones, servicios, operaciones y componentes empresariales en distintos procesos. [30] Características Soporta el estándar JBI. Soporta múltiples protocolos de transporte, como por ejemplo JMS, TCP/IP, y Sistema de ficheros, entre otros. Incluye IDE gráfico para el desarrollo

126 Posee motor de orquestación de servicios BPEL. Transformación de mensajes XML, a través de XSLT y Smooks. Se dispone de una gran variedad de tipos de datos soportados. Posee diferentes tipos de ruteo de mensajes, como por ejemplo, ruteo basado en contenido. Se integra de forma nativa con jbpm y con JBoss AS. Posee muy buena documentación y comunidad activa. Tiene gran variedad de ejemplos de código para la generación de nuevos servicios. Es posible cambiar fácilmente el comportamiento de las acciones predefinidas, como transformaciones y ruteos. Arquitectura La Figura 78 presenta la arquitectura de JBoss ESB, la cual que se basa en los principios de SOA y hace hincapié en un enfoque gradual para la implementación de una infraestructura SOI (Service Oriented Infrastructure). [31] Open ESB Figura 78 - Arquitectura de JBoss ESB. Extraído de [31]. OpenESB es un ESB basado en la especificación JBI, iniciado por Sun Microsystems, y que permite integrar fácilmente aplicaciones empresariales y servicios como aplicaciones con bajo acoplamiento

127 Esto ESB permite desarrollar de manera fluida y rápida aplicaciones compuestas, con todas las ventajas de la Arquitectura Orientada a Servicios. [32] Características brindadas Basado en el estándar JBI. Soporta múltiples protocolos de transporte, como JMS, HTTP, SOAP, REST, FTP, y Sistema de ficheros, entre otros. Incluye IDE gráfico y una consola de administración web. Motor de orquestación de servicios BPEL. Transformación de datos XML a través de XSLT y TransformXL. Dispone de ruteo de mensajes basado en contenido. Se integra de manera nativa con Glassfish y/o con JBoss AS. Arquitectura La Figura 79 presenta los principales componentes arquitectónicos que son relevantes para la integración de OpenESB con Glassfish. Figura 79 - Arquitectura de Open ESB. Extraído de [33]

128 Mule ESB Mule ESB está implementado en Java y permite integrar sistemas de forma sencilla, independientemente de las diferentes tecnologías y aplicaciones. Mule fue diseñado para integrarse fácilmente con servidores de aplicación o ejecutar como un servidor standalone. Se integra con numerosos framework, como por ejemplo spring, además soporta una gran cantidad de conectores de capa de transporte. [34] Características brindadas Soporta múltiples protocolos de transporte como por ejemplo JMS, HTTP, , FTP, etc. Incluye IDE gráfico para el desarrollo de aplicaciones. Soporta transformación de datos XML, utilizando transformaciones XSLT. Ruteo de mensajes basado en contenido, a través de Xpath y JXPath. Permite comunicación síncrona y asíncrona. Manejo de mensajería utilizando request y response. Brinda soporte a J2EE, como por ejemplo JBI, JMS, EJB, JCA, JTA, Servlet. Amplitud de conectividad (más de 60 tecnologías). Tolerancia a fallos a través de la gestión de excepciones. Opciones de seguridad, brindando funcionalidades de autenticación y autorización. Facilidad para realizar pruebas unitarias a través de la biblioteca JUnit. Es el ESB Open Source más utilizado

129 Arquitectura A continuación, la Figura 80 presenta la arquitectura general del producto Mule ESB, detallando sus principales componentes, los cuales hacen posible su integración con varios servidores de aplicaciones. Figura 80 - Arquitectura de Mule ESB. Extraído de [34]

130

131 Apéndice 3. Estructura Física de la Plataforma En este apéndice se detalla cómo está estructurada la implementación de la Plataforma ESB Adaptativa, presentando cada uno de los proyectos Java que la componen. La plataforma implementada está distribuida en cuatro proyectos Java, Jboss-ESB-Adaptative (ESB Adaptativo), Jboss-ESB-Adaptative-Admin (Consola de Administración), Jboss-ESB-Adaptative- MotorMonitor (Motor de Administración y Monitoreo) y un cuarto proyecto común a los anteriores, que contiene las interfaces y el código compartido, denominado Jboss-ESB-Adaptative-Core. La Figura 81 muestra de forma gráfica la estructura de cada uno de los proyectos y sus principales paquetes. Figura 81 - Proyectos java de la plataforma implementada

132

133 Apéndice 4. Opciones de Extensibilidad de la Plataforma Este apéndice presenta ejemplos prácticos de dos de las opciones de extensibilidad de la plataforma implementada. Primeramente se detallan los pasos que permiten crear y registrar una nueva Estrategia de Adaptación, luego se presenta cómo crear un nuevo Requerimiento de Adaptación. Implementación de una nueva Estrategia de Adaptación Para implementar nuevas Estrategias de Adaptación, se debe generar un proyecto Jar que permita ser desplegado en el mismo ClassLoader que el Motor de Adaptación y Monitoreo. Dicho proyecto debe tener como dependencia el proyecto JBoss-ESB-Adaptative-Core, el cual contiene todas las interfaces y utilidades necesarias para extender la plataforma. Las estrategias de adaptación son desarrolladas utilizando clases Java que deben implementar la interfaz IAdpStrategy. Esta interfaz contiene un solo método denominado getadptree, que el Motor de Adaptación y Monitoreo invoca cuando se requiere utilizar una estrategia de adaptación. Dicho método recibe la información de un servicio virtual, una lista de sus servicios equivalentes y el conjunto de todas las propiedades monitoreadas en la plataforma, y retorna un flujo de adaptación del tipo GenericTreeNode<AdpFlowInterface>. La Figura 82 presenta el código utilizado para implementar la estrategia encargada de diferir los pedidos de un servicio virtual. Figura 82 - Implementación de la estrategia encargada de diferir los pedidos

134 Cada estrategia registrada en la plataforma se carga en tiempo de ejecución utilizando Reflection, y cada vez que se requiere invocarla se crea una nueva instancia. Por lo tanto, la incorporación de una nueva estrategia está libre a la creatividad del desarrollador, siendo posible utilizar cualquier mecanismo de adaptación en su implementación. Registro de las Estrategias de Adaptación El registro de las Estrategias de Adaptación se realiza mediante el archivo de configuración jbossadaptative-strategies.xml. Para registrar una estrategia se debe indicar tanto la clase Java que la implementa, como la lista de los requerimientos de adaptación que la estrategia puede abordar. La definición de una lista de requerimientos donde la estrategia se puede aplicar, no determina que una estrategia se pueda instanciar en todos los casos de un requerimiento, ya que esto se determina en tiempo de ejecución según la metadata de cada servicio, los servicios equivalentes y las propiedades monitoreadas por la plataforma. La estructura del archivo XML que permite registrar nuevas estrategias de adaptación se detalla en la Figura 83. Figura 83 - Registro de estrategias de adaptación. Implementación de un nuevo Requerimiento de Adaptación Complejo. Para definir un nuevo Requerimiento de Adaptación se debe especificar una clase Java que implemente la interfaz IAdpServiceRequirement, de esta forma se tratan de forma genérica todos los requerimientos de adaptación de la plataforma. Dicha interfaz cuenta con un único método denominado needrequiredadp, que recibe toda la metadata definida para un servicio y su lista de las propiedades monitoreadas. El método needrequiredadp tiene la responsabilidad de calcular si el requerimiento de adaptación se cumple o no. La clase implementada debe estar accesible en el mismo ClassLoader en el que se encuentre ESB- Adaptativo, y debe tener como dependencia al proyecto JBoss-ESB-Adaptative-Core. La Figura 84 presenta el código utilizado para implementar el requerimiento de cambio de contrato, definido en la configuración base de la plataforma