EnterpriseServiceBusAdaptativo criterios de evaluacion.pdf

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

- 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.

- 5 -

Contenido 1 Introducción .................................................................................................................................. 7

1.1 Contexto y Motivación ............................................................................................................. 7

1.2 Objetivos ................................................................................................................................. 8

1.3 Aportes del Proyecto ................................................................................................................ 8

1.4 Organización del Documento ................................................................................................. 10

2 Conocimiento Existente ............................................................................................................. 11

2.1 Web Services ......................................................................................................................... 11

2.2 Enterprise Service Bus (ESB) ................................................................................................... 15

2.3 Patrones para Enterprise Service Bus ..................................................................................... 16

2.4 Otras Tecnologías ................................................................................................................... 21

2.5 Plataforma ESB Adaptativa ..................................................................................................... 22

3 Selección del Producto ESB ....................................................................................................... 33

3.1 Productos ESB analizados ....................................................................................................... 33

3.2 Criterios de evaluación. .......................................................................................................... 34

3.3 Evaluación de los Productos ................................................................................................... 36

3.4 Selección del Producto ESB .................................................................................................... 39

3.5 JBoss ESB ............................................................................................................................... 39

4 Solución Propuesta ..................................................................................................................... 47

4.1 Descripción Conceptual .......................................................................................................... 47

4.2 Arquitectura General ............................................................................................................. 48

4.3 Principales Componentes ....................................................................................................... 50

4.4 Interacción entre componentes ............................................................................................. 62

4.5 Extensibilidad ......................................................................................................................... 68

4.6 Limitaciones y mejoras ........................................................................................................... 71

5 Detalles de Implementación ..................................................................................................... 73

5.1 Mecanismos de Adaptación ................................................................................................... 73

5.2 Mecanismos de Monitoreo .................................................................................................... 74

5.3 Administrador de Monitoreo .................................................................................................. 77

5.4 Administrador de Requerimientos de Servicios ...................................................................... 78

5.5 Gateway de Adaptación ......................................................................................................... 79

5.6 Registro de Servicios y Configuración ..................................................................................... 80

5.7 Motor de Adaptación y Monitoreo ......................................................................................... 83

5.8 Consola de Administración ..................................................................................................... 87

5.9 Componentes ESB Reutilizables .............................................................................................. 89

5.10 Problemas Encontrados ......................................................................................................... 92

6 Caso de Estudio y Pruebas Realizadas ...................................................................................... 95

6.1 Caso de Estudio: Gobierno Electrónico ................................................................................... 95

6.2 Pruebas Realizadas ............................................................................................................... 100

6.3 Conclusiones ........................................................................................................................ 106

- 6 -

7 Conclusiones del Trabajo .........................................................................................................109

7.1 Resumen y Contribuciones ................................................................................................... 109

7.2 Trabajo a Futuro .................................................................................................................. 110

8 Referencias ................................................................................................................................115

Apéndice 1. Estrategias de Adaptación ........................................................................................119

Apéndice 2. Principales Características de los Productos ESB ...................................................123

Apéndice 3. Estructura Física de la Plataforma ...........................................................................131

Apéndice 4. Opciones de Extensibilidad de la Plataforma.........................................................133

- 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 W3C1 y OASIS2, 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.

2.1.1 Web Services Description Language (WSDL)

WSDL [7] es un formato XML para describir servicios de red, como un conjunto de puntos finales (end-

points) 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.

1 http://www.w3.org/

2 http://www.oasis-open.org

http://www.w3.org/

http://www.w3.org/

http://www.w3.org/

http://www.w3.org/

http://www.w3.org/

http://www.w3.org/

http://www.w3.org/

http://www.w3.org/

http://www.oasis-open.org/









- 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.

2.1.2 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.

2.1.2.1 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 namespaces3 que

son usados en el resto del mensaje. Los namespaces son utilizados para garantizar la unicidad de los

3 http://www.w3schools.com/xml/xml_namespaces.asp

http://www.w3schools.com/xml/xml_namespaces.asp

- 14 -

elementos XML y evitar ambigüedades. A modo de ejemplo, la Figura 5 presenta el Envelope de un

mensaje SOAP.

Figura 5 - Envelope de un mensaje SOAP.

2.1.2.2 SOAP Header

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.

Figura 6 - Header de un mensaje SOAP.

2.1.2.3 SOAP Body

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 RPC4 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).

4 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383532

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383532

- 15 -

Figura 7 - Body de un mensaje SOAP.

2.1.3 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 2.2.1 se define el concepto de ESB. En la sección 2.2.2 se detallan algunas de las

características más importantes que poseen los ESB para brindar soporte a arquitecturas SOA.

2.2.1 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 2002. 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 2007.

“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.

2.2.2 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.

Al menos un protocolo de transporte.

Provee transparencia para localizar

servicios y brinda soporte para la

sustitución entre servicios.

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 SOA5. 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.

2.3.1 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.

2.3.1.1 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.

5 www.eaipatterns.com

http://www.eaipatterns.com/





- 18 -

2.3.1.2 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.

2.3.1.3 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.

2.3.2.1 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.

2.3.3 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 -

2.3.3.1 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.

2.3.4 Otras categorías

En esta categoría se localizan aquellos patrones que no fueron detenidamente descriptos en el trabajo

de Hohpe & Woolf’s.

2.3.4.1 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 -

Figura 13 - Patrón Servicio Proxy Simple.

2.3.4.2 Patrón Cache

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.

2.4.1 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]

2.4.2 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.

2.5.1 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 2.3.4.1). 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 2.3.1.2).

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

Servicios ESB destino

Lógica de Ruteo

Unificador de Respuestas

Condición de Completitud

Algoritmo de Agregación

Lista de Destinarios

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].

2.5.2.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.

2.5.2.2 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.

2.5.2.3 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.

2.5.2.4 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].

2.5.2.5 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.

2.5.2.6 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.

2.5.3 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

Representa el fin de un flujo de red YAWL.

Servicio Virtual Representa un Servicio Virtual presente en la

plataforma.

Tarea atómica

Representa una tarea atómica con un único flujo de

entrada y un único flujo de salida.

AND-split

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.

XOR-split 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.

XOR-join 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].

2.5.4 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.

2.5.5 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 2.5.4.

- 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].

3.1.1 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 ESB6 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.

3.1.2 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 ESB7 es su gran variedad de opciones para transformaciones, conectividad y ruteos, los cuales

pueden ser fácilmente reutilizados.

6 http://www.jboss.org/jbossesb

7 http://www.mulesoft.org/

http://www.jboss.org/jbossesb









http://www.mulesoft.org/








- 34 -

3.1.3 Apache Synapse

Apache Synapse8 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.

3.1.4 OpenESB

OpenESB9 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.

3.1.5 Apache ServiceMix

Apache ServiceMix10 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.

8 http://synapse.apache.org

9 http://openesb-dev.org/

10 http://servicemix.apache.org/

http://synapse.apache.org/







http://openesb-dev.org/








http://servicemix.apache.org/








- 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 JBI11.

3.3 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 2012.

3.3.1 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/2012 17/11/2011 06/01/2012 04/01/2010 17/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.

11

http://jcp.org/en/jsr/detail?id=312

http://jcp.org/en/jsr/detail?id=312

- 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.


Ruteo basado en contenido

SI SI SI SI SI

Ruteo basado en itinerario

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



Funcionalidades de monitoreo

JMX Console Mule

Management Console

Plugins disponibles


JMX monitoring Tool, JConsole

Tabla 5 - Comparativa de criterios funcionales.

Darwin PG

Resaltar

Darwin PG

Resaltar

Darwin PG

Resaltar

- 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.


IDE Gráfico SI SI SI SI SI

Servidores Web soportados

JBoss 4.2.3 - 6.1.0.Final

Geronimo,

JBoss, WebLogic,

WebSphere, Tomcat

Tomcat, Full-featured 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

SI SI SI SI SI

Conector transporte de ficheros

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

3.5.2.2.

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 2012.

3.5 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 3.5.1 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 3.5.2 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.

3.5.2 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.

3.5.2.1 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].

3.5.2.2 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.

3.5.2.3 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.

3.5.2.4 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 http://<host>:<puerto>/<.esbname>/http/*.

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 8081. 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 Remoting12 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.

12

https://community.jboss.org/wiki/R31RemoteProtocolSpecification

https://community.jboss.org/wiki/R31RemoteProtocolSpecification

- 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. 20000

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://docs.oasis-open.org/wss/2004/01/oasis-200401http-wss-wssecurity-secext-1.0.xsd

Tabla 7 - Propiedades configurables del JBR Gateway.

3.5.2.5 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.

3.5.2.6 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 -

3.5.2.7 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.

3.5.2.8 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.

3.5.2.9 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.

3.5.2.10 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.

3.5.2.11 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.

http://docs.jboss.org/jbossesb/docs/4.11/manuals/html/Administration_Guide/index.html#message_counter

http://docs.jboss.org/jbossesb/docs/4.11/manuals/html/Administration_Guide/index.html#transformations

http://docs.jboss.org/jbossesb/docs/4.11/manuals/html/Administration_Guide/index.html#dead_letter_service

http://docs.jboss.org/jbossesb/docs/4.11/manuals/html/Administration_Guide/index.html#d0e1150

- 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 4.3.10.

- 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.

4.3.1 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 2.3.4.1. 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 -

4.3.1.1 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 Servicio encargado de aplicar la transformación que se encuentra en el itinerario del mensaje.

Transformación

RUT Servicio encargado de realizar el ruteo de un mensaje según cierta lógica que se encuentra adjunta al mensaje.

Ruteo intermediario

LST Servicio encargado de distribuir un mensaje a un conjunto de servicios.

Lista de destinatarios

UNI Servicio encargado de unificar las respuestas entre los servicios que distribuye el LST.

Unificador de respuestas

CCH Servicio encargado de retornar respuestas previamente almacenadas.

Cache

RET Servicio encargado de retardar la entrega de un mensaje por cierto período de tiempo.

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.

4.3.1.2 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 3.5.2.2, 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.

4.3.2 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.

4.3.4 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 JMX13 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.

13

http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html

http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html

- 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 5.3.1 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.

4.3.6 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.

4.3.7 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.

4.3.8 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.

4.3.9 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.

4.3.9.1 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 Descripción

degradación-tiempo-respuesta Detecta cuándo un servicio virtual supera el umbral preestablecido para su tiempo de respuesta.

degradación-respuestas-exitosas

Detecta cuándo un servicio virtual supera el umbral

preestablecido para la cantidad de fallas en sus

respuestas.

saturación-servicio

Detecta cuándo un servicio virtual supera la máxima

cantidad de peticiones que puede procesar por

período de tiempo.

cambio-contrato

Detecta cuándo se produce un cambio en el

documento WSDL al que accede un determinado

servicio.

Tabla 11 - Eventos Monitoreados por la plataforma.

4.3.9.2 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 Descripción

disminuir-tiempo-respuesta Representa la necesidad de disminuir el tiempo de respuesta de un servicio.

aumentar-respuestas-exitosas Representa la necesidad de aumentar el porcentaje de respuestas exitosas de un servicio.

disminuir-solicitudes Representa la necesidad de disminuir el número de solicitudes que recibe un servicio.

manejar-cambio-contrato 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.

4.3.9.3 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 Descripción

invocar-servicio-equivalente Se invoca un servicio equivalente del servicio virtual para el cual que se detectó un requerimiento de adaptación.

utilizar-información-almacenada Se utiliza información previamente almacenada del servicio virtual para el cual se detectó un requerimiento de adaptación.

distribuir-solicitud-equivalentes Se distribuye la solicitud a un conjunto de servicios equivalentes del servicio virtual que generó el requerimiento de adaptación.

balancear-carga Se balancea la carga de solicitudes entre varios servicios equivalentes al servicio virtual que requiere una adaptación.

diferir-pedidos Se posterga el envío de la solicitud al servicio virtual para el cual se detectó el requerimiento de adaptación.

modificar-solicitud-respuesta 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.

4.3.10 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 2.114 y en un conjunto de componentes

brindados por el framework Primefaces15. 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.

4.4.1 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

14

http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 15

http://www.primefaces.org

http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html

http://www.primefaces.org/

- 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.

4.4.4 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.

4.4.5 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.

4.4.6 Interacción de la Consola de Administración

Como se mencionó en la Sección 4.3.10, 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.

4.5.1 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 4.5.3 se describen algunas de las operaciones presentes en la interfaz que expone el

componente ESB Adaptativo para su administración.

4.5.2 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 Reflection16, 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.

4.5.2.1 Extensibilidad para los componentes del ESB Adaptativo

Los puntos de extensibilidad y los respectivos archivos de configuración de este componente son los siguientes:

16

http://java.sun.com/developer/technicalArticles/ALT/Reflection/

http://java.sun.com/developer/technicalArticles/ALT/Reflection/

- 70 -

Mecanismos de monitoreo: El archivo de configuración jboss-adaptative-monitor-

mechanism.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.

4.5.2.2 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.

4.5.3 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

org.jboss.soa.esb.actions.SyncServiceInvoker org.fing.edu.uy.esbadp.action.sync. SyncAction

Lista de Destinatarios

org.jboss.soa.esb.client. ServiceInvoker org.fing.edu.uy.esbadp.action.list. ListAction

Balanceo org.jboss.soa.esb.client. ServiceInvoker y org.jboss.soa.esb.actions.StaticRouter

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 5.9.

5.2 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.

5.2.1 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.

5.2.2 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

DOCUMENT17 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.

17

http://www.w3.org/TR/wsdl#_soap-b

http://www.w3.org/TR/wsdl#_soap-b

- 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 Observaciones

Agregar operación. Soportado. No afecta comportamiento.

Renombrar operación.

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.

Quitar operación. No soportado. No es posible manejarlo.

Modificar MEP de operación. No soportado.

Agregar Parámetro. 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.

Renombrar Parámetro. 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.

Cambiar Opcionalidad Parámetro. No soportado.

Cambiar Orden Parámetros. No soportado.

Quitar Parámetro. 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.

5.3.1 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 4.5.2.1.

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 con fallas. Inv. exitosas * 100 / (Inv. exitosas + Inv. con fallas)

Tiempo de respuesta promedio T. de respuesta total


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.

5.6.1 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 (jbossesb-

properties.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.

5.6.2 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 Intervalo en segundos del cálculo de las propiedades monitoreadas por el Administrador de Monitoreo

jboss-adaptative-config.xml

CompareWSDLImpl Nombre canónico de la clase Java que implementa el comparador de WSDL


MotorMonitorURL Url del servicio MBean expuesto por el Motor de Adaptación y Monitoreo.


MotorMonitorObjectName Nombre del servicio MBean expuesto por el Motor de Adaptación y Monitoreo.


PathWSDLStore Ruta relativa a la instalación de JBoss ESB donde son persistidos los WSDL utilizados por el comparador.


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.

- 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 Tiempo de vida por defecto para una estrategia de adaptación (en milisegundos).

config.properties

motor.historic.flag Habilita el registro del histórico de las estrategias de adaptación utilizadas para cada servicio.

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.

5.6.3 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.

5.7.1 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 jboss-

adaptative-events.xml, deben coincidir con los que fueron definidos previamente en el archivo jboss-

adaptative-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.

5.7.2 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.

5.7.3 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.

5.8.1 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.

5.8.2 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 4.5.2.1, 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 5.9.1 se detalla la implementación y reutilización del Ruteo Basado en Itinerario mientras

que en la Sección 5.9.2 se presenta el mecanismo de adaptación que utiliza información almacenada

(Cache).

5.9.1 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.

5.9.2 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 EHCache18, que permite

configurar el tamaño del máximo de cache (en disco y memoria), el tiempo de vida, el tiempo de

18

http://ehcache.org/

http://ehcache.org/

- 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 MD519, 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 dependencias20 (ehcache-core,

ehcache-terracotta, slf4j-jdk14) requeridas por la biblioteca EHCache.

19

http://www.ietf.org/rfc/rfc1321.txt 20

http://mvnrepository.com/artifact/net.sf.ehcache/ehcache/2.6.0

http://mvnrepository.com/artifact/net.sf.ehcache/ehcache-core

http://mvnrepository.com/artifact/net.sf.ehcache/ehcache-terracotta

http://mvnrepository.com/artifact/org.slf4j/slf4j-jdk14

http://www.ietf.org/rfc/rfc1321.txt

http://mvnrepository.com/artifact/net.sf.ehcache/ehcache/2.6.0

- 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.

5.10.1 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.

5.10.2 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.

5.10.3 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.

5.10.4 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

HSQLDB21 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.

5.10.5 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.

21

http://hsqldb.org/

http://hsqldb.org/

- 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 2.5.4.

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]

http://es.wikipedia.org/wiki/Tecnolog%C3%ADas_de_la_informaci%C3%B3n

http://es.wikipedia.org/wiki/Tecnolog%C3%ADas_de_la_informaci%C3%B3n

- 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 2.5.4.

6.1.1 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.

6.1.2 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

6.1.3 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.

6.1.4 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 v4.5.122, mientras que para el monitoreo de los recursos consumidos se utilizó la

herramienta VisualVM v1.3.523. 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.

6.2.1 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 2.5.4.

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.

22

http://www.soapui.org/ 23

http://visualvm.java.net/

http://www.soapui.org/

http://visualvm.java.net/

- 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 30569 1013 10351 67%

Invocación a través del

ESB Adaptativo 36380 731 784 90%

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 4777 13%

DGIWS 20701 57%

DNICWS 6370 18%

Cache 4532 12%

Tabla 22 - Porcentaje de invocaciones por servicio

6.2.2 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 Se agrega el parámetro nuevoParam al método

obtenerInfoEmpresa. Si Exitosa

Renombrar operación Se renombra el nombre de la operación registroEmpresa a

registroEmpresaNueva. Si Exitosa

Renombrar Parámetro Se renombra el nombre del parámetro miles a mil del

método obtenerPersona. Si Exitosa

Eliminar Parámetro Se elimina el parámetro digitoVerificacion del método

obtenerPersona. Si 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.

6.2.3 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 110 7 18 No posee

Sin estrategia 124 9 21 3

Cache 10 4 6 No posee

Retardo (100ms) 349 106 121 3

Cambio de Contrato 740 24 179 161

Servicio Equivalente 435 22 94 76

Lista de Destinatarios 1110 70 350 332

Balanceo de Carga 480 25 129 111

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.

6.2.4 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 leaks24, 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.

http://es.wikipedia.org/wiki/Error_de_software

http://es.wikipedia.org/w/index.php?title=Bloque_de_memoria&action=edit&redlink=1

http://es.wikipedia.org/wiki/Software

- 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.

7.2.1 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-Management25, o

algún conector SOAP para JMX como MX4J26. [26]

25

http://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.1.pdf 26

http://mx4j.sourceforge.net/

http://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.1.pdf

http://mx4j.sourceforge.net/

- 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.

7.2.3 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.

7.2.4 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.

7.2.5 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.

7.2.7 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.

7.2.8 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 Cloud27, 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.

7.2.9 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.

27

http://aws.amazon.com/es/ec2/

http://aws.amazon.com/es/ec2/

- 113 -

7.2.10 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.

7.2.11 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, 2011.

[2] accenture, «Arquitectura Orientada a Servicios (SOA),» [En línea]. Available:

http://www.accenture.com/SiteCollectionDocuments/Local_Spain/PDF/SOA.pdf.

[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. 78-82,

2010.

[4] Chappell, David, «Enterprise Service Bus,» de Enterprise Service Bus: Theory in Practice, 2004.

[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. 149-163, 2012.

[6] W3C, «Web Services Architecture,» [En línea]. Available: http://www.w3.org/TR/ws-arch/. [Último

acceso: Mayo 2012].

[7] W3C, «Web Services Description Language (WSDL) Version 2.0 SOAP 1.1 Binding,» [En línea].

Available: http://www.w3.org/TR/wsdl20-soap11-binding/. [Último acceso: Mayo 2012].

[8] W3C, «SOAP Specifications,» [En línea]. Available: http://www.w3.org/TR/soap/. [Último acceso:

Mayo 2012].

[9] OASIS, «UDDI Version 3.0.2,» [En línea]. Available: http://uddi.org/pubs/uddi_v3.htm. [Último

acceso: Mayo 2012].

[10] Papazoglou, Michael, and Willem-Jan Heuvel, Service oriented architectures: approaches,

technologies and research issues, The VLDB Journal 16:389-415, 2007.

[11] IBM, «Patterns: Implementing an SOA Using an Enterprise Service Bus,» [En línea]. Available:

http://www.redbooks.ibm.com/redbooks/pdfs/sg246346.pdf. [Último acceso: Mayo 2012].

[12] G. H. a. B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging

Solutions., Addison-Wesley Professional, 2003.

[13] IBM, [En línea]. Available:

http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-

enterpriseconnectivitypatterns/Enterprise-Connectivity-Patterns-pdf.pdf. [Último acceso:

Noviembre 2012].

[14] IBM, «Cache mediation pattern specification: an overview,» [En línea]. Available:

http://www.ibm.com/developerworks/webservices/library/ws-soa-cachemed/. [Último acceso:

Junio 2012].

[15] DZone, «Java Management Extensions,» [En línea]. Available: http://java.dzone.com/articles/java-

management-extensions.

[16] The YAWL Foundation, «YAWL Manuals,» [En línea]. Available:

http://www.yawlfoundation.org/pages/support/manuals.html. [Último acceso: Junio 2012].

- 116 -

[17] CENATIC, «ASPECTOS TECNOLÓGICOS,» [En línea]. Available:

http://www.cenatic.es/laecsp/page21/page22/page22.html. [Último acceso: Junio 2012].

[18] «11 Of Best Opensource ESB Tools,» [En línea]. Available:

http://www.toolsjournal.com/integrations-articles/item/224-11-of-best-opensource-esb-tools.

[Último acceso: Junio 2012].

[19] DZone, «Top Open Source ESB Projects,» [En línea]. Available:

http://architects.dzone.com/news/top-open-source-esbs. [Último acceso: Junio 2012].

[20] O. Alliance, «The OSGi Architecture,» [En línea]. Available:

http://www.osgi.org/Technology/WhatIsOSGi. [Último acceso: Septiembre 2012].

[21] Community, JBoss, «Programmers Guide,» [En línea]. Available:

http://docs.jboss.org/jbossesb/docs/4.11/manuals/html/Programmers_Guide/index.html. [Último

acceso: Junio 2012].

[22] SOA Membrane, «Open Source SOA & Integration,» [En línea]. Available: http://www.membrane-

soa.org/soa-model-doc/1.2/compare-wsdl-java-api.htm. [Último acceso: Noviembre 2012].

[23] OW2 Consortium, «EasyWSDL Toolbox,» [En línea]. Available: http://easywsdl.ow2.org/index.html.

[Último acceso: Junio 2012].

[24] AGESIC, «Plataforma de EGob,» [En línea]. Available:

http://www.agesic.gub.uy/innovaportal/v/1710/1/agesic. [Último acceso: Octubre 2012].

[25] W3C, «The Extensible Stylesheet Language Family,» [En línea]. Available:

http://www.w3.org/Style/XSL/. [Último acceso: Octubre 2012].

[26] UserException, «Monitorizando componentes usando JMX,» [En línea]. Available:

http://userexception.blogspot.com/2011/11/monitorizando-componentes-usando-jmx.html.

[Último acceso: Noviembre 2012].

[27] Apache, «Apache Synapse,» [En línea]. Available: http://synapse.apache.org/. [Último acceso: Mayo

2012].

[28] http://servicemix.apache.org/, «ServiceMix,» [En línea]. [Último acceso: Mayo 2012].

[29] ServiceMix, «ServiceMix,» [En línea]. Available:

http://docs.huihoo.com/apache/servicemix/home.html. [Último acceso: Mayo 2012].

[30] RedHat, «JBOSS ENTERPRISE SOA PLATFORM,» [En línea]. Available:

http://www.latam.redhat.com/pdf/JBoss_Enterprise_SOA_Platform.pdf. [Último acceso: Mayo

2012].

[31] JBoss, «JBoss ESB,» [En línea]. Available: http://www.jboss.org/jbossesb. [Último acceso: Mayo

2012].

[32] OpenESB Community, «Open ESB,» [En línea]. Available: http://www.open-esb.net/. [Último

acceso: Junio 2012].

[33] OpenESB, «Open ESB Architecture,» [En línea]. Available: http://wiki.open-

esb.java.net/Wiki.jsp?page=Glassfish9.1OpenESBArch. [Último acceso: Junio 2012].

[34] MuleSoft, «What is Mule ESB?,» [En línea]. Available: http://www.mulesoft.org/what-mule-esb.

- 117 -

[Último acceso: Mayo 2012].

[35] W3C, «W3C XML Schema,» [En línea]. Available: http://www.w3.org/XML/Schema. [Último acceso:

05 2012].

[36] AS3 Studio, «Adaptaive SOA Approach,» [En línea]. Available: https://www.soa.edu.pl/AS3-

Studio/?q=ASOAapproach. [Último acceso: Agosto 2012].

[37] W3C, «Web Services Addressing (WS-Addressing),» [En línea]. Available:

http://www.w3.org/Submission/ws-addressing/. [Ú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.

Figura 73 - Implementación de estrategia que utiliza información almacenada.

Diferir Pedidos 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.

Figura 76 - Arquitectura del producto Apache Synapse. Extraído de [27].

Service Mix ESB 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]


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 -


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.

Figura 77 - Arquitectura del producto ServiceMix. Extraída de [29].

JBoss ESB 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, Email y Sistema de ficheros, entre otros.

Incluye IDE gráfico para el desarrollo.

- 126 -


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]

Figura 78 - Arquitectura de JBoss ESB. Extraído de [31].

Open ESB 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]


Basado en el estándar JBI.

Soporta múltiples protocolos de transporte, como JMS, HTTP, SOAP, REST, FTP, Email 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]


Soporta múltiples protocolos de transporte como por ejemplo JMS, HTTP, email, 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 jboss-

adaptative-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.

- 135 -

Figura 84 - Implementación de un requerimiento de adaptación complejo.

Registro de los Requerimientos de Adaptación complejos. El archivo de configuración jboss-adaptative-service-requirements.xml registra todos los requerimientos

de adaptación de la plataforma, siendo posible especificar tanto requerimientos simples como los

complejos. Todos los requerimientos de adaptación se especifican fácilmente como se detalla en la

Sección 5.4.

EnterpriseServiceBusAdaptativo criterios de evaluacion.pdf

Documents

Transcript of EnterpriseServiceBusAdaptativo criterios de evaluacion.pdf