You are on page 1of 135

Instituto de Computacin - Facultad de Ingeniera

Universidad de la Repblica
Montevideo, Uruguay

Implementacin de una
Plataforma ESB Adaptativa
Informe de Proyecto de Grado

Jorge Luis Laborde de los Santos


Mauricio Fenoglio Armand Ugon
Matas Galnares Rodrguez

Supervisor y Orientador: Ing. Laura Gonzlez

12 de Diciembre, 2012

-2-

Resumen
Los sistemas de software orientados a servicios operan en ambientes altamente cambiantes, por lo que
se hace ms frecuente la necesidad de contar con capacidades de adaptacin que permitan afrontar
rpidamente 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 problemtica.
En este proyecto, se realiz una implementacin de una de estas plataformas, la cual se basa en las
capacidades de mediacin de los ESB, para responder a necesidades de adaptacin en una SOA de forma
dinmica, automtica y en tiempo de ejecucin. Dicha implementacin apunt a analizar la factibilidad
tcnica de desarrollar la Plataforma ESB Adaptativa sobre un producto ESB existente, a tener una
plataforma funcional que aplique acciones de adaptacin en sistemas orientados a servicios y que
adems permita validar su correcto funcionamiento y desempeo.
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 anlisis permiti seleccionar a JBoss ESB como el producto base para la implementacin,
debido a su buena documentacin y a su amplio conjunto de capacidades de mediacin.
La plataforma fue diseada e implementada para tener un alto grado de extensibilidad. La
implementacin aprovech varios de los componentes de JBoss ESB y adems 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 Electrnico,
y a partir de l se especificaron pruebas que permitieron evaluar si la plataforma con la implementacin
realizada mejora los atributos de calidad de los servicios. Las pruebas ponen de manifiesto una mejora
en dichos atributos de calidad, permitiendo adems que los problemas de adaptacin sean detectados y
solucionados rpidamente. Por ltimo, se observa que el overhead generado por la plataforma es
despreciable en relacin a las mejoras que se generan.
Palabras claves: arquitectura orientada a servicios, enterprise service bus, web services, mediacin,
adaptacin, monitoreo.

-3-

-4-

Contenido
1

Introduccin .................................................................................................................................. 7
1.1
1.2
1.3
1.4

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


2.1
2.2
2.3
2.4
2.5

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


Enterprise Service Bus (ESB) ................................................................................................... 15
Patrones para Enterprise Service Bus ..................................................................................... 16
Otras Tecnologas................................................................................................................... 21
Plataforma ESB Adaptativa ..................................................................................................... 22

Seleccin del Producto ESB ....................................................................................................... 33


3.1
3.2
3.3
3.4
3.5

Contexto y Motivacin ............................................................................................................. 7


Objetivos ................................................................................................................................. 8
Aportes del Proyecto................................................................................................................ 8
Organizacin del Documento ................................................................................................. 10

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


Criterios de evaluacin. .......................................................................................................... 34
Evaluacin de los Productos ................................................................................................... 36
Seleccin del Producto ESB .................................................................................................... 39
JBoss ESB ............................................................................................................................... 39

Solucin Propuesta..................................................................................................................... 47
4.1
4.2
4.3
4.4
4.5
4.6

Descripcin Conceptual .......................................................................................................... 47


Arquitectura General ............................................................................................................. 48
Principales Componentes ....................................................................................................... 50
Interaccin entre componentes ............................................................................................. 62
Extensibilidad ......................................................................................................................... 68
Limitaciones y mejoras ........................................................................................................... 71
5 Detalles de Implementacin ..................................................................................................... 73
5.1
Mecanismos de Adaptacin ................................................................................................... 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 Adaptacin ......................................................................................................... 79
5.6
Registro de Servicios y Configuracin ..................................................................................... 80
5.7
Motor de Adaptacin y Monitoreo ......................................................................................... 83
5.8
Consola de Administracin ..................................................................................................... 87
5.9
Componentes ESB Reutilizables.............................................................................................. 89
5.10 Problemas Encontrados ......................................................................................................... 92

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


6.1
6.2
6.3

Caso de Estudio: Gobierno Electrnico ................................................................................... 95


Pruebas Realizadas............................................................................................................... 100
Conclusiones ........................................................................................................................ 106

-5-

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


7.1
7.2

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


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

Referencias ................................................................................................................................115

Apndice 1.
Apndice 2.
Apndice 3.
Apndice 4.

Estrategias de Adaptacin ........................................................................................119


Principales Caractersticas de los Productos ESB ...................................................123
Estructura Fsica de la Plataforma ...........................................................................131
Opciones de Extensibilidad de la Plataforma.........................................................133

-6-

1 Introduccin
Este proyecto, posicionado en el rea de Adaptacin de Sistemas Basados en Servicios (SBSs), propone y
lleva a cabo una implementacin de la solucin propuesta en "Plataforma ESB Adaptativa para Sistemas
Basados en Servicios" [1]. Dicha platataforma adaptativa se basa en las capacidades de mediacin
brindadas por los Enterprise Service Bus (ESB), infraestructura base preferida para la implementacin de
una Arquitectura Orientada a Servicios (Service Oriented Architecture, SOA), a fin de abordar
necesidades de adaptacin en los SBSs de forma dinmica, automtica y en tiempo de ejecucin. Este
captulo presenta el contexto y la motivacin del proyecto, los objetivos planteados, los aportes del
proyecto y finalmente la organizacin del resto del documento.

1.1 Contexto y Motivacin


Los sistemas de software actuales operan en ambientes altamente dinmicos por lo que necesitan, cada
vez ms, contar con capacidades de adaptacin que les permitan abordar rpidamente cambios
inesperados, por ejemplo en metas de negocio o entorno de ejecucin. [1]
El concepto de Arquitecturas Orientadas a Servicios nace a mediados de los aos 80, impulsado por las
comunidades que iniciaron el diseo de software a travs de componentes (Programacin Orientada a
Objetos). Este tipo de arquitecturas conceptuales permiten organizar las empresas en trminos de
aplicaciones, servicios y procesos de negocio [2] [3]. A su vez, estas arquitecturas poseen un enfoque
alentador para abordar requerimientos de adaptacin, dado que permiten mejorar la agilidad en el
desarrollo e incrementar la reutilizacin de los servicios, con el consiguiente beneficio de reduccin de
costos y tiempo en los denominados Sistemas Basados en Servicios. Sin embargo, las tecnologas y
mtodos actuales para SOAs no proveen soluciones nativas y completas que aborden requerimientos de
adaptacin, de forma automtica, dinmica y en tiempo de ejecucin [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 implementacin de una SOA. Un ESB proporciona una plataforma de
integracin basada en estndares que combina, mensajera, Web Services, transformacin 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 envindose mensajes a
travs del ESB.
Segn lo mencionado anteriormente, el ESB resulta un lugar ideal para efectuar acciones de adaptacin
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 adaptacin en una SOA, utilizando las capacidades
nativas de los ESBs.

-7-

En particular, en [1] se propone y especifica una plataforma adaptativa basada en las capacidades de
mediacin de los ESBs, la cual permite responder a necesidades de adaptacin en una SOA de forma
dinmica, automtica y en tiempo de ejecucin. Dicha plataforma se basa en patrones de mensajera e
integracin comnmente soportados en los productos ESB, por lo que brinda una solucin genrica y
factible de aplicarse en la mayora de estos productos. En [1] se describe tambin el desarrollo de un
prototipo que permiti evaluar la factibilidad tcnica de la implementacin de algunos de los
componentes de la plataforma propuesta. Sin embargo, este prototipo no constituye una solucin
completa, que permita evaluar, por ejemplo, el correcto funcionamiento y desempeo de la plataforma
adaptativa.

1.2 Objetivos
En el marco de la problemtica descripta anteriormente, el objetivo general de este proyecto es realizar
una implementacin de un ESB Adaptativo a partir de la solucin propuesta en Plataforma ESB
Adaptativa para Sistemas Basados en Servicios [1].
Para esto, se plantean los siguientes objetivos especficos:

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 adems brinde
facilidades que permitan su extensin.

Implementar la Plataforma ESB Adaptativa tomando como base el producto ESB seleccionado.

Implementar una herramienta que facilite la administracin y configuracin de la Plataforma


ESB Adaptativa, y que permita realizar un seguimiento de sus acciones de adaptacin.

Definir un caso de estudio que permita realizar pruebas para validar el correcto funcionamiento
y desempeo 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:

Anlisis de las principales capacidades de los productos ESBs basados en la plataforma Java y
con licencia Open Source, que puede servir como gua para posteriores proyectos que requieran
realizar una comparativa entre distintos ESBs.

-8-

Implementacin de una Plataforma ESB Adaptativa de acuerdo a la propuesta en Plataforma


ESB Adaptativa para Sistemas Basados en Servicios [1]. Dicha implementacin se apoya en el
producto JBoss ESB y en particular en los patrones de mensajera e integracin soportados por
el producto.
La plataforma implementada provee distintas opciones de extensibilidad para sus principales
componentes, que permiten integrar fcilmente nuevos servicios y nuevas funcionalidades. Por
ejemplo, se podran crear nuevos mecanismos de monitoreo, que permitan obtener ms
informacin acerca del funcionamiento de los servicios registrados en la plataforma.

Implementacin de mecanismos de adaptacin 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 adaptacin
que surgen por la degradacin de la calidad de servicio (tiempo de respuesta y porcentaje de
respuestas exitosas), la saturacin de servicios (cantidad de invocaciones por perodo de
tiempo), y cambios en los contratos de servicios.

Diseo e implementacin 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


Adaptacin y Monitoreo, que implementan decisiones bsicas de adaptacin segn los distintos
datos monitoreados. Cabe destacar, que la implementacin de este motor es totalmente
independiente del resto de los componentes de la plataforma, lo que facilita su integracin con
nuevos componentes. Por ejemplo, se podra utilizar la misma implementacin del Motor de
Adaptacin y Monitoreo con una nueva implementacin 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 adaptacin, otro que encapsula
las diferentes estrategias que permiten abordar las necesidades de adaptacin, y finalmente, un
componente que selecciona y aplica las estrategias segn las necesidades de adaptacin
detectadas.

Implementacin de una consola de administracin que facilita administrar, configurar y


monitorear toda la informacin brindada por la Plataforma ESB Adaptativa. En particular, esta
consola presenta de forma grfica los datos de todos los servicios registrados, permitiendo
adems, visualizar las acciones de adaptacin que se realizan en la plataforma.

-9-

Realizacin de pruebas a travs de un caso de estudio, lo que permiti evaluar distintos


aspectos de la plataforma, como por ejemplo, su correcto funcionamiento y desempeo en un
escenario simplificado de Gobierno Electrnico.

1.4 Organizacin del Documento


El resto del documento se organiza de la siguiente manera.
En el Captulo 2, se presenta un resumen del conocimiento existente relevante a la problemtica
abordada en este proyecto.
En el Captulo 3, se presentan los diferentes productos ESB que fueron analizados en el marco de este
proyecto, y se detallan los criterios de evaluacin utilizados para seleccionar el producto ESB ms
adecuado a las necesidades de este trabajo. Adems, se presenta un breve resumen de las
caractersticas tcnicas particulares del producto JBoss ESB, en el cual se basa la Plataforma ESB
Adaptativa implementada.
En el Captulo 4, se presenta la plataforma implementada, para la cual se especifican sus caractersticas
generales, sus componentes y sus principales interacciones. Conjuntamente, en este captulo se
presenta cmo se implementaron los distintos componentes de la Plataforma ESB Adaptativa.
En el Captulo 5, se describe detalladamente la implementacin de los principales componentes de la
Plataforma ESB Adaptativa, destacando aquellos componentes que pueden ser reutilizados en otros
contextos, y comentando algunas de las problemticas presentadas durante la etapa de implementacin
de este proyecto.
En el Captulo 6, se presenta el caso de estudio de Gobierno Electrnico, que proporciona un contexto
para evaluar el desempeo de la plataforma. Adems, se describe cada una de las pruebas a las que fue
sometida la plataforma.
Finalmente, en el Captulo 7, se presentan las conclusiones del proyecto, resumiendo el trabajo
realizado, describiendo sus contribuciones, y comentando posibles trabajos a futuro.

- 10 -

2 Conocimiento Existente
Este captulo presenta los conceptos fundamentales de la problemtica planteada en este proyecto,
estableciendo un marco conceptual que permita una mejor comprensin del documento. En primer
lugar, en la Seccin 2.1 se describen los conceptos generales: tecnologa de Web Services y las
Arquitecturas Orientadas a Servicios. En la Seccin 2.2 se presenta el Enterprise Service Bus (ESB). La
Seccin 2.3 presenta un conjunto de patrones (patterns) asociados a los ESB, los cuales constituyen las
bases fundamentales de la solucin propuesta en este trabajo. En la Seccin 2.4 se describen algunas
tecnologas del lenguaje Java que facilitan la comprensin de este documento. Finalmente, en la Seccin
2.5 se describen las principales caractersticas de la Plataforma ESB Adaptativa propuesta en [1].

2.1 Web Services


Un Web Service es un conjunto de estndares y protocolos. Es utilizado para intercambiar informacin
entre distintos sistemas, brindando interoperabilidad entre mquinas (a travs de una red) y logrando
independizarse de las distintas plataformas. Adems, posee una interfaz pblica bien definida, la cual es
fcilmente procesable. Los mensajes son transportados generalmente sobre el protocolo HTTP y
codificados en lenguaje XML. La interoperabilidad se consigue a partir de estndares 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 tecnolgicamente heterogneas y constituyen la tecnologa preferida para la
implementacin de una SOA.
La tecnologa de Web Services est basada en tres estndares 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 estndares
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 (endpoints) que operan sobre los mensajes que contienen informacin orientada a documentos u orientada
a procedimientos. Los documentos WSDL, se componen de dos grandes partes: una descripcin
abstracta y una descripcin concreta. A modo de ejemplo la Figura 1 presenta grficamente las
descripciones de un WSDL.

1
2

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

- 11 -

Figura 1 - Representacin grfica de las descripciones de un WSDL.

En la descripcin abstracta, se encuentran las caractersticas de la interfaz, independientemente de la


tecnologa, como lo son las Operaciones, el Tipo de Puerto y los Mensajes de Entrada y Salida.
En la descripcin concreta, se encuentran los elementos de Vinculacin (posible tecnologa de
transporte: SOAP, HTTP, etc.), Puerto (direccin fsica para acceder segn 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 operacin hello,
la cual recibe como parmetro un String y retorna como respuesta otro String.

Figura 2 - Descripcin Abstracta WSDL.

- 12 -

Figura 3 - Descripcin Concreta WSDL.

2.1.2 Simple Object Access Protocol (SOAP)


SOAP [8] es un protocolo ligero para el intercambio de informacin en un entorno descentralizado y
distribuido. En la Figura 4 se presenta grficamente 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 seccin 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 sintctica define un documento XML como un mensaje SOAP, la cual debe estar siempre
presente y ser la primera seccin del mensaje. En esta seccin 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

- 13 -

elementos XML y evitar ambigedades. 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 sintctica es opcional y es un mecanismo genrico para extender las caractersticas 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 informacin auxiliar para la autenticacin, 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 sintctica que acta como contenedor de la informacin que se enva al receptor del
mensaje. Debe estar siempre presente en los mensajes SOAP y se ubica a continuacin del Header, si
este ltimo est presente, en caso contrario ser el primer elemento del Envelope.
Tpicamente esta estructura es utilizada para proveer un mecanismo simple de intercambio de
informacin con el receptor del mensaje SOAP. En esta parte del mensaje es donde se encuentran las
invocaciones RPC4 o bien el resultado de la invocacin. A modo de ejemplo, la Figura 7 presenta un
mensaje SOAP que invoca a la operacin sayHello de un determinado servicio, enviando como
parmetro un nombre (name=Test).

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

- 14 -

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
electrnicos y no electrnicos. Un servicio de registro UDDI es un servicio web que gestiona la
informacin 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 seccin describe el Enterprise Service Bus y el rol que ste juega en las Arquitecturas Orientadas a
Servicios. En la seccin 2.2.1 se define el concepto de ESB. En la seccin 2.2.2 se detallan algunas de las
caractersticas ms importantes que poseen los ESB para brindar soporte a arquitecturas SOA.

2.2.1 Definicin de ESB


El concepto de ESB fue descripto por primera vez como una nueva arquitectura que aprovecha las
ventajas de los Web Services, tecnologas middleware, ruteo inteligente y transformaciones por Roy
Schulte, en la publicacin Predicts 2003: Enterprise Service Buses Emerge en Diciembre del 2002. Hoy
en da 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 ms
completas definiciones es la formulada por Mike Papazoglou en 2007.
El ESB es una columna vertebral de mensajera basada en estndares abiertos y diseada para
posibilitar la implementacin, despliegue y administracin de soluciones SOA. Es un conjunto de
capacidades de infraestructura implementadas va tecnologas de middleware que posibilitan una SOA y
alivianan problemas de disparidad entre aplicaciones que se ejecutan en plataformas heterogneas y
usan diversos formatos de datos. [10]
Este tipo de plataformas puede traer ventajas significativas en contextos en los que existan necesidades
de integracin de sistemas. Las ventajas del uso de un ESB se ven con mayor claridad en contextos en
donde dicha integracin se realice en un ambiente heterogneo de aplicaciones que trabajen en

- 15 -

mltiples plataformas. Los ESBs pueden resolver gran parte del proceso de integracin permitiendo
tener un buen control del mismo.

2.2.2 Caractersticas bsicas de un ESB


Un ESB brinda una gran cantidad de caractersticas o funcionalidades para facilitar la implementacin de
una aplicacin orientada a servicios. En general, las caractersticas de los ESBs dan soporte a las
necesidades de las arquitecturas SOA, ya que cuentan con capacidades de conectividad, adaptacin,
ruteo y transformacin de mensajes, flujos de mediacin, mensajera asincrnica y capacidad de
monitoreo para los mensajes que se envan a travs de l.
La Tabla 1 presenta el conjunto de capacidades mnimas que debe poseer un ESB de acuerdo a lo
relevado en [11].
Categora

Comunicacin

Capacidad

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
sustitucin entre servicios.

Integracin entre varios estilos o


adaptadores.
Transformacin entre protocolos.

Brindar soporte para la integracin en


entornos heterogneos y la posibilidad de
sustituir un servicio por otro.

Definicin de interfaces de servicios.


Modelo de mensajes de servicios.
Posibilidad de sustituir la
implementacin de un servicio por otra.

Soporte para los principios de las


arquitecturas SOA, aislando la aplicacin de
las implementaciones concretas de los
protocolos de servicio.

Administracin de las caractersticas.

Un punto de control para el manejo de los


nombres y las direcciones de los servicios.

Integracin

Servicio de interaccin

Direccin y autonoma

Motivo

Tabla 1 - Caractersticas bsicas de un ESB.

2.3 Patrones para Enterprise Service Bus


La integracin de procesos de negocio contina siendo un problema complejo, dado que las aplicaciones
de negocio en general no funcionan aisladas de otros sistemas. Para manejar esta problemtica
frecuente para Arquitectos y Desarrolladores, existen los patrones de integracin (Enterprise Integration
Patterns), que se han convertido en el estndar para describir problemas recurrentes de integracin y
sus posibles soluciones.

- 16 -

El libro Enterprise Integration Patterns [12] de los autores Hohpe & Woolfs junto con su web se han
convertido en lectura obligatoria cuando se trabaja con SOA5. Hohpe y Woolf comparten aos de
experiencias en trabajos de integracin mostrando soluciones a problemas recurrentes en forma de
patrones o recetas agnsticas de tecnologas, lo que permite que sean aplicables en distintos escenarios.
La solucin al problema de implementar un ESB Adaptativo se apoya en distintos patrones de
mensajera, como por ejemplo los identificados por Hohpe y Woolf. A continuacin se describen los
patrones ms relevantes en el contexto de este proyecto, agrupados de acuerdo a la problemtica que
solucionan.

2.3.1 Routing Patterns (Patrones de ruteo)


Esta categora 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 ms 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 continuacin 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 patrn Content Based Router examina el contenido del mensaje y rutea cada mensaje al canal
correspondiente basndose nicamente en su contenido. El ruteo puede estar basado en varios criterios
como, la existencia de un determinado campo o un valor especfico 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 relacin 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.

www.eaipatterns.com

- 17 -

2.3.1.2 Routing Slip (Ruteo Basado en Itinerario)


Como todos los patrones de ruteo, el ruteo basado en itinerario determina dinmicamente el destino de
un mensaje. Lo interesante de este patrn 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 patrn.

Figura 9 - Routing Slip.

2.3.1.3 Scatter-Gather
El patrn Scatter-Gather soluciona la problemtica de brindar la mejor respuesta al cliente cuando se
cuenta con ms de un servicio que puede procesar la misma peticin. Es comn utilizarlo para mejorar
los tiempos de respuesta o la calidad de las mismas, en base a una lista de recursos intercambiables.
Este patrn es la composicin del patrn Broadcast y Aggregator, el primero enva 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 patrn 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.

- 18 -

2.3.2 Endpoint Patterns


Esta categora 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 categora 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 patrn Messaging
Gateway el cual tiene gran importancia en la plataforma.
2.3.2.1 Messaging Gateway
Este patrn permite encapsular el acceso al sistema y es utilizado para aplicar un
operaciones de mediacin comunes a todos los mensajes entrantes y/o salientes al
particularmente til para dar funciones de borde como seguridad, autenticacin
implementndose por nica vez en el Gateway y utilizndose para todos los mensajes
travs del ESB.

conjunto de
ESB. Resulta
y auditora,
que pasan a

Este patrn tambin admite la aplicacin selectiva de los procesos de mediacin, de acuerdo a
propiedades o datos provenientes del propio mensaje. La Figura 11 presenta la idea general de este
patrn, donde el Gateway intercepta los mensajes que se envan a un determinado servicio del ESB.

Figura 11 - Messaging Gateway.

2.3.3 Transformation Patterns


Cuando se integran diferentes aplicaciones a travs de un sistema de mensajera, difcilmente stas
coincidan en un formato de datos comn. Para estos casos existen diferentes patrones de
transformacin de mensajes que permiten adaptar y resolver las diferencias existentes entre los
distintos sistemas a integrar. Dichos patrones permiten agregar (patrn Content Enrichment), eliminar
(patrn Content Filter), o simplemente reorganizar (patrones Normalizer y Canonical Data Model) la
informacin contenida en los mensajes.
A continuacin se describe el patrn Canonical Data Model, el cual es el que ms se adecua a los
requerimientos de integracin de este proyecto.

- 19 -

2.3.3.1 Canonical Data Model


Este patrn permite minimizar la dependencia a un modelo de datos particular, el cual propone disear
un modelo de datos independiente de las aplicaciones. Este modelo permite integrar una nueva
aplicacin simplemente definiendo la transformacin entre su modelo de datos particular y un modelo
de datos cannico, independientemente de la cantidad de aplicaciones que estn interactuando.
Finalmente, la Figura 12 presenta la idea general de este patrn.

Figura 12 - Canonical Data Model.

2.3.4 Otras categoras


En esta categora se localizan aquellos patrones que no fueron detenidamente descriptos en el trabajo
de Hohpe & Woolfs.
2.3.4.1 Servicio Virtual
Los patrones que pertenecen al grupo de Servicios Virtuales describen cmo desacoplar servicios
utilizando niveles de indireccin en un ESB. Visto de otra manera, estos patrones permiten realizar
requerimientos de mediacin (ruteos, transformaciones, conversin 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 versin. [13]
En particular, el patrn Servicio Proxy Simple es el ms 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 travs de un punto controlado
dentro del ESB. La Figura 13 presenta la idea general de este patrn, el cual accede a un Web Service
externo a travs de un Servicio Virtual publicado en el ESB.

- 20 -

Figura 13 - Patrn Servicio Proxy Simple.

2.3.4.2 Patrn Cache


Cuando se utiliza un middleware como canal de comunicacin de mensajes entre los receptores y los
emisores de una aplicacin orientada a servicios, es comn que el rendimiento se vea afectado debido a
la mediacin de los mensajes realizada por el middleware.
El patrn 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 idnticas caractersticas. De esta manera el tiempo de respuesta total se ve
reducido, ya que no es necesario realizar la invocacin al servicio porque se tiene almacenada su
respuesta. En la Figura 14 se presenta un ejemplo de este patrn.

Figura 14 - Patrn Cache.

2.4 Otras Tecnologas


En esta seccin se describen otras tecnologas relevantes para el contexto de este proyecto y que
facilitan la comprensin 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 tecnologa permite
monitorear y gestionar los recursos de una aplicacin de forma remota.

- 21 -

Los usos tpicos de esta API son los siguientes:

Hacer cambios en la configuracin de una aplicacin de forma remota.

Extraccin y acumulacin de datos que permitan un anlisis estadstico de la utilizacin 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 aplicacin. Estos objetos
exponen la informacin manejable de las entidades, en forma de propiedades y operaciones.
Adicionalmente, los MBeans pueden ser cargados o eliminados dinmicamente segn 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 mtodos
dinmicamente, posibilitando construir cdigo flexible, que es ensamblado en tiempo de ejecucin. Es
una caracterstica potente de lenguaje Java, sin la cual protocolos importantes como SOAP y JMX no
seran posibles. A travs de esta API es posible que una aplicacin brinde opciones de extensibilidad,
permitindole al usuario definir nuevas clases que son instanciadas en tiempo de ejecucin por su
nombre cannico.

2.5 Plataforma ESB Adaptativa


En esta seccin se resumen las principales caractersticas 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 adaptacin en una SOA, utilizando las capacidades de mediacin de los ESBs. En
particular, esta plataforma aborda necesidades de adaptacin que surgen debido a la degradacin en la
calidad de los servicios, a la saturacin de servicios y a cambios en los contratos de los servicios.

2.5.1 Descripcin General de la Plataforma ESB Adaptativa


La Plataforma ESB Adaptativa hace frente a necesidades de adaptacin que se pueden generar en una
SOA. Para esto, utiliza las capacidades de mediacin de un ESB y construye flujos de adaptacin que
implementan distintas estrategias de adaptacin. Adicionalmente, la plataforma selecciona y aplica
dichas estrategias de forma automtica, dinmica y en tiempo de ejecucin. Por lo tanto, la plataforma
es capaz de reaccionar automticamente sin ninguna intervencin humana frente a cambios
inesperados, aplicando acciones de adaptacin dinmicas, que se realizan en tiempo de ejecucin y no
requieren de ningn cambio en la implementacin de la plataforma.

- 22 -

En la plataforma propuesta se considera una SOA donde los servicios son provistos a travs de un ESB,
utilizando el patrn de Servicios Virtuales (Seccin 2.3.4.1). La Figura 15 presenta la arquitectura general
del marco considerado.

Figura 15 - Arquitectura General. Extrado de [1].

Los servicios ofrecidos por los proveedores y los Servicios Virtuales estn basados en la tecnologa 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 evala si es necesario realizar
algn tipo de adaptacin. Cuando se considera necesario realizar acciones de adaptacin sobre cierto
Servicio Virtual, se interceptan en el ESB todos aquellos mensajes que pretendan invocarlo, y sobre
estos mensajes se aplica un flujo de adaptacin. Los flujos de adaptacin se construyen de forma
dinmica, automtica y en tiempo de ejecucin, cuando se detecta un requerimiento de adaptacin, y
posteriormente se incluyen en los mensajes interceptados segn el patrn Ruteo Basado en Itinerario
(Seccin 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 adaptacin se
podrn realizar nicamente dentro del ESB. Adems, esta plataforma se basa en las capacidades de
mediacin (transformaciones, ruteo, etc.) del ESB, para efectuar acciones de adaptacin sobre los
mensajes que se intercambian al invocar a los Servicios Virtuales, logrando as una adaptacin 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.

- 23 -

Figura 16 - Ejemplo de Adaptacin. Extrado de [1].

En funcin de los requerimientos definidos para cada uno de los Servicios Virtuales registrados (por
ejemplo, la cantidad mxima de invocaciones de un servicio por periodo de tiempo), la plataforma
puede originar requerimientos de adaptacin (por ejemplo, disminuir las solicitudes de un servicio). Los
requerimientos de adaptacin se generan cuando se detecta algn evento que indique una necesidad de
adaptacin, 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 adaptacin para disminuir sus solicitudes. Al originarse este
requerimiento de adaptacin, 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 adaptacin para construir un flujo que implemente la estrategia seleccionada, para
finalmente aplicarla.

Figura 17 - Esquema General para abordar la saturacin de servicios. Extrado de [1].

- 24 -

2.5.2 Mecanismos de Adaptacin en el ESB


En esta seccin se presentan las principales caractersticas de los mecanismos de adaptacin
considerados por la plataforma. Los Mecanismos refieren a aquellas funcionalidades brindadas por los
ESB (transformacin, ruteo, etc.) que permiten realizar algn tipo de adaptacin dentro del mismo.
En la Tabla 2 se detallan las representaciones grficas y las caractersticas propuestas en [1], para los
mecanismos de adaptacin considerados por la plataforma. En las siguientes sub-secciones se describen
cado uno de estos mecanismos.
Mecanismo

Representacin Grfica

Caractersticas

Tranformacin de Mensajes

Lgica de Transformacin

Cache

Mximo tiempo de vida

Retardador

Tiempo de retardo

Ruteo de Mensajes

Servicios ESB destino


Lgica de Ruteo

Unificador de Respuestas

Condicin de Completitud
Algoritmo de Agregacin

Lista de Destinarios

Servicios ESB destino


Un mensaje de entrada
Varios mensajes salida

Tabla 2 - Representaciones Grficas y Caractersticas de los mecanismos de adaptacin. Extrado de [1].

2.5.2.1 Transformacin de Mensajes


El mecanismo de Transformacin de Mensajes permite modificar los mensajes que se envan a travs del
ESB. El mecanismo recibe un mensaje y devuelve otro transformado de acuerdo a una lgica de
transformacin, 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 adems una lgica de ruteo, la cual es responsable de decidir a qu Servicio ESB se enva cada
mensaje.

- 25 -

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


ejecucin realiza el ruteo a un Servicio ESB.

Ruteo para Balanceo de Carga: Tiene como objetivo distribuir la carga de las distintas solicitudes
a mltiples Servicios ESB.

2.5.2.3 Lista de Destinatarios


El mecanismo Lista de Destinarios tiene la responsabilidad de distribuir un mensaje a mltiples 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]. Adems, es
necesario un algoritmo de agregacin que especifique cmo 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 mximo de vida de las
respuestas almacenadas.
2.5.2.6 Retardador
El mecanismo Retardador recibe un mensaje y posterga su entrega por un determinado perodo de
tiempo. Se debe especificar el tiempo de demora en la entrega del mensaje.

2.5.3 Flujos de Adaptacin en el ESB


Los mecanismos de adaptacin descriptos anteriormente se pueden combinar para formar flujos de
adaptacin. Estos flujos permiten realizar varias operaciones de mediacin sobre los mensajes que se
envan a travs del ESB. Los flujos estn conformados por Servicios ESB, por lo que para utilizar un
mecanismo de adaptacin en un flujo de mediacin, es necesario crear un Servicio ESB que aplique
dicho mecanismo. La Figura 18 muestra un ejemplo de un flujo de adaptacin que es aplicado cuando
una aplicacin cliente invoca a un Web Service a partir del ESB.

- 26 -

Figura 18 - Ejemplo de flujo de adaptacin. Extrado de [1].

YAWL es el lenguaje elegido en [1] para especificar y representar grficamente los flujos de mediacin
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 grficamente los flujos de
adaptacin.
Elemento

Representacin Grfica

Descripcin

Condicin de Entrada

Representa el inicio de un flujo de red YAWL.

Condicin de Salida

Representa el fin de un flujo de red YAWL.


Representa un Servicio Virtual presente en la
plataforma.
Representa una tarea atmica con un nico flujo de
entrada y un nico flujo de salida.
Cuando existe ms de un flujo de salida para la tarea,
el AND-split se utiliza para especificar que se activan
todos los flujos.
Cuando existe ms de un flujo de salida para la tarea,
el XOR-split se utiliza para especificar que nicamente
se activa un flujo.
Cuando existe ms 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.

Servicio Virtual
Tarea atmica

AND-split

XOR-split

XOR-join

Tabla 3 - Representacin grfica de los elementos de un flujo. Extrado de [1].

- 27 -

A modo de ejemplo, la Figura 19 muestra una red YAWL que representa el flujo de adaptacin de la
Figura 18, donde se utilizan Servicios ESB que aplican dos mecanismos de adaptacin (Retardador y
Transformacin de mensajes), para finalmente invocar a un Servicio Virtual.

Figura 19 - Representacin de un flujo de adaptacin con YAWL. Extrado de [1].

2.5.4 Estrategias de Adaptacin


En esta seccin se detallan las estrategias de adaptacin definidas en [1], que son ms relevantes en el
contexto de este proyecto. Concretamente, se presentan estrategias para abordar las siguientes
necesidades:

Degradacin en la calidad de los servicios: En el contexto de la plataforma, la degradacin en la


calidad de servicio refiere a la degradacin de las propiedades de tiempo de respuesta y
porcentaje de respuestas exitosas. La degradacin de la calidad se puede detectar en base a la
informacin de las invocaciones de los servicios y de sus requerimientos.

Saturacin de servicios: En el contexto de la plataforma, la saturacin de servicio refiere a


aquella situacin en la cual un servicio recibe ms invocaciones de las que puede procesar un
determinado periodo de tiempo. Al igual que la degradacin de calidad, la saturacin se detecta
a partir de la informacin 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 modificacin del WSDL de un servicio. Esta necesidad, se puede detectar
tanto monitoreando el contrato del servicio, as como tambin recibiendo una notificacin por
parte del servicio.

A continuacin se describen las estrategias de adaptacin ms relevantes para este proyecto, que
permiten hacer frente a las necesidades de adaptacin presentadas anteriormente. En el Apndice 1, se
describen con ms 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 adaptacin. Concretamente, esta estrategia permite abordar las siguientes necesidades:
Degradacin 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 aplicacin cliente a partir de la primera respuesta obtenida. En
particular, esta estrategia permite abordar la Degradacin de Calidad de un Servicio.

- 28 -

Balancear Carga
Esta estrategia permite distribuir uniformemente las diferentes solicitudes a un Servicio Virtual entre sus
servicios equivalentes. Con respecto a las necesidades de adaptacin, esta estrategia permite abordar la
Saturacin de un Servicio.
Utilizar Informacin Almacenada
Esta estrategia utiliza informacin almacenada en invocaciones previas de un servicio, generando una
respuesta sin la necesidad de invocar directamente al Servicio Virtual. Especficamente, esta estrategia
permite abordar las siguientes necesidades de adaptacin: Degradacin de Calidad, Saturacin de un
Servicio y Cambio de Contrato de un Servicio
Diferir Pedidos
Esta estrategia recibe un mensaje y posterga su entrega por un determinado perodo de tiempo. En los
que refiere a las necesidades de adaptacin, esta estrategia permite abordar la Saturacin 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 tambin su respuesta. Especficamente, esta estrategia aborda la necesidad de adaptacin 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 adaptacin
consideradas en el marco de la plataforma anteriormente descripta.

- 29 -

Figura 20 - Esquema General para abordar las distintas necesidades de adaptacin.

2.5.5 Arquitectura y Esquema General de la Plataforma


La Figura 21 presenta la arquitectura general de la solucin propuesta en [1], en la cual se exhibe un
Motor de Adaptacin y Monitoreo y los componentes internos del ESB que fueron diseados
especficamente para hacer frente a las necesidades de adaptacin (Gateway de Adaptacin, Servicios
de Adaptacin, Administrador de Adaptacin, Administrador de Monitoreo, Administrador de
Capacidades y Administrador de Requerimientos de Servicios). Adems, se visualizan otros
componentes que comnmente estn presentes en un ESB y son relevantes para la plataforma (Registro
de Servicios, Mecanismos de Monitoreo y Mecanismos de Adaptacin), as como tambin las principales
interacciones y flujos de informacin existentes entre los principales componentes.

- 30 -

Figura 21 - Arquitectura General de la Plataforma. Extrado 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 dinmica, automtica y en
tiempo de ejecucin, logrando as abordar las distintas necesidades de adaptacin descriptas en la
Seccin 2.5.4.

- 31 -

- 32 -

3 Seleccin del Producto ESB


En este captulo se analizan las distintas alternativas de productos ESB existentes en el mercado, a fin de
seleccionar el producto ms adecuado para el contexto del proyecto. En la Seccin 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 caractersticas. En la Seccin 3.2 se introducen
distintos criterios de evaluacin de acuerdo a las necesidades del proyecto. La Seccin 3.3 presenta la
evaluacin de los distintos productos ESB considerados, mientras que en la Seccin 3.4 se selecciona el
producto JBoss ESB con el cual se realiza la implementacin de la Plataforma ESB Adaptativa.
Finalmente, en la Seccin 3.5 se presentan las caractersticas particulares con las que cuenta JBoss ESB.

3.1 Productos ESB analizados


La creciente cantidad de sistemas y aplicaciones heterogneas que deben comunicarse entre s de
manera interna dentro de una organizacin, o externa entre distintas organizaciones, genera un gran
desarrollo de los productos de integracin como lo son los ESBs. Hoy en da, las tecnologas Open Source
ofrecen una gran competencia, y en el rea de los productos de integracin, los desarrollados en
tecnologas como Java, estn a la altura de los mejores productos comerciales. [17]
A continuacin se presenta una introduccin 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 documentacin y a la informacin recabada en [18] y [19].

3.1.1 JBoss ESB


Es comn que JBoss cuente con productos maduros en sus versiones de JBoss Application Server y por lo
general estos cuentan con todas las caractersticas de la versin comercial, ya que sta solamente
agrega la posibilidad de acceder a servicios de soporte. El producto JBoss ESB6 no es la excepcin, siendo
un producto de gran madurez que aprovecha las tecnologas ya desarrolladas por la comunidad, como el
motor de reglas de negocio para el ruteo de mensajes basado en contenido. Adems, 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 integracin Open Source ms utilizados por las compaas
alrededor del mundo. Su flexibilidad de configuracin lo hizo muy popular entre las dems alternativas,
siendo posible disear flujos de integracin complejos en pocos minutos. Otra de las caractersticas de
Mule ESB7 es su gran variedad de opciones para transformaciones, conectividad y ruteos, los cuales
pueden ser fcilmente reutilizados.

6
7

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

- 33 -

3.1.3 Apache Synapse


Apache Synapse8 est posicionado como uno de los productos ESB ms livianos del mercado, el cual
cuenta con soporte para las funcionalidades esenciales. A su vez, su utilizacin es simple, debido a su
facilidad de configuracin a partir de archivos XML. Adicionalmente, su diseo se enfoc para tener muy
buena performance, y dadas sus caractersticas, 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 slida integracin con el servidor de
aplicacin GlassFish y el popular IDE Netbeans, el cual brinda soporte para la administracin y desarrollo
de aplicaciones que utilizan OpenESB.
Por ser un producto de Sun (Oracle) tiene muchos adeptos que lo consideran uno de los productos ms
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 opcin de seleccionar dicho producto se vio
comprometida, debido a su poca actividad y documentacin.

3.1.5 Apache ServiceMix


Apache ServiceMix10 se base en OSGi [20] y es una muy buena opcin para la interaccin basada en
estndares XML. Con Apache ServiceMix es muy sencillo integrar nuevos flujos en tiempo de ejecucin,
pudiendo integrar nuevos componentes sin tener la necesidad de reiniciar los dems servicios del
producto. Camel es una distribucin de este ESB, el cual posee un gran soporte para los patrones ESB
descriptos en la Seccin 2.3. Adicionalmente, esta distribucin brinda la posibilidad de ser integrado con
el Framework Spring.
En la siguiente seccin se analiza cada uno de los productos ESB presentados, evaluando sus
caractersticas y brindando una visin objetiva de cada uno de ellos. Adems, en el Apndice 2 se
presenta informacin especfica y detallada de cada uno de estos productos.

3.2 Criterios de evaluacin.


En esta seccin se presentan y analizan las diferentes caractersticas que resultan relevantes en el
contexto de este proyecto. En general, las caractersticas ms anheladas refieren a requerimientos como
usabilidad, confiabilidad y performance. Sin embargo, aunque se consideran las caractersticas
mencionadas, se hace foco en aquellas caractersticas que faciliten una extensin del producto,
valorando por ejemplo la calidad de su documentacin.

http://synapse.apache.org
http://openesb-dev.org/
10
http://servicemix.apache.org/
9

- 34 -

En las siguientes sub-secciones se realiza una comparativa de los distintos productos ESB de acuerdo a
los criterios estratgicos, funcionales y tcnicos presentados en [17], los cuales fueron adaptados y
actualizados para el contexto de este proyecto. A continuacin se describen cada uno de los criterios
mencionados anteriormente.

Los criterios estratgicos 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, utilizacin
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 sern de gran utilidad al momento
de realizar una extensin del producto. En particular, se valorar que el producto provea
mecanismos de adaptacin y monitoreo nativos, los cuales faciliten la implementacin de la
Plataforma ESB Adaptativa.

Los criterios tcnicos abarcan todos aquellos aspectos que refieren a la implementacin de bajo
de nivel, como por ejemplo los protocolos de mensajera disponibles.

Con el fin de comparar cada uno de los productos analizados, se trabaja con cuadros comparativos
donde se listan cada una de las caractersticas deseables y se mencionan sus correspondientes valores.
La gran mayora de los criterios considerados son estndares y muy nemotcnicos. Sin embargo, para
evitar ambigedades se detallan algunos criterios que podran generar confusiones.

Documentacin: Refiere a la calidad de los documentos disponibles, que brindan informacin


relevante acerca del producto, la cual facilita la utilizacin de sus funcionalidades. Adems, se
valora en gran medida toda aquella informacin que facilite una posible extensin 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.

Orquestacin 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 lgica de interaccin. Tiene como objetivo definir la secuencia de
interaccin 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 diseado en la propuesta del ESB adaptativo.

- 35 -

Servicio Virtual: Refiere a aquellas funcionalidades provistas por el ESB, las cuales permiten de
forma nativa implementar los servicios virtuales diseados en la Propuesta Adaptativa.

JBI: Se distingue entre compatibilidad del ESB con el estndar JBI y su implementacin basada
en el mismo. Decimos que el ESB es compatible con JBI cuando el estndar es soportado por el
producto, y en los casos en que la implementacin del producto se bas en JBI, decimos que
est basado en JBI11.

3.3 Evaluacin de los Productos


En las siguientes sub-secciones se detallan las caractersticas mencionadas en la Seccin 3.2 junto con
sus correspondientes valores, agrupadas segn 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 Estratgicos


En la Tabla 4 se visualizan los criterios estratgicos considerados y sus respectivos valores para cada uno
de los productos ESB analizados.
Criterio

JBoss ESB

Mule ESB

Apache Synapse

OpenESB

ServiceMix

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

Documentacin

MUY BUENA

BUENA

REGULAR

ESCASA

BUENA

Actividad en Issue Tracker

SI

SI

SI

NO

SI

Experiencia

SI

NO

NO

NO

NO

Tipo de Licencia

Tabla 4 - Comparativa de criterios estratgicos.

11

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

- 36 -

3.3.2 Criterios Funcionales


La Tabla 5 muestra los criterios funcionales considerados y sus respectivos valores para cada uno de los
productos ESB analizados.
Criterio

JBoss ESB

Mule ESB

Apache Synapse

OpenESB

ServiceMix

Ruteo basado en
contenido

SI

SI

SI

SI

SI

Ruteo basado en
itinerario

NO

NO

NO

NO

NO

Transformaciones

XSLT, Smooks

XSLT

XSLT, Scripting

XSLT,
TransformXL

XSLT,
XSLTComponent

Orquestacin de servicios

SI

SI

SI

SI

SI

Gateway

SI

SI

SI

No se encontr
informacin.

SI

Facilidad para extender


comportamientos

SI

Poca
informacin al
respecto

SI

Poca
informacin al
respecto

Poca informacin al
respecto

Cache

NO

SI

SI

No se encontr
informacin

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
informacin

No se encontr
informacin

No se encontr
informacin

No se encontr
informacin

Funcionalidades de
monitoreo

JMX Console

Mule
Management
Console

Plugins
disponibles

No se encontr
informacin

JMX monitoring
Tool, JConsole

Tabla 5 - Comparativa de criterios funcionales.

- 37 -

3.3.3 Criterios Tcnicos


La Tabla 6 muestra los criterios tcnicos considerados y sus respectivos valores para cada uno de los
productos ESB analizados.
Criterio

JBoss ESB

Mule ESB

Apache Synapse

OpenESB

ServiceMix

SI

SI

SI

SI

SI

JBoss 4.2.3 6.1.0.Final

Geronimo,
JBoss, WebLogic,
WebSphere, Tomcat

Tomcat, Fullfeatured J2EE AS

Glassfish
JBossAS

Apache
Geronimo
JBOSS JonAS

Compatibilidad estndar
JBI

SI

SI

NO

SI

SI

Basado en estndar 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 estndares de
Servicios Web (WS-*)

SI

SI

SI

SI

SI

WS-Security,
WSDL 1.1,
JAX-WS, WSAddressing

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
documentacin
online
disponible

WS-Security

IDE Grfico
Servidores Web
soportados

Estndares soportados

Tabla 6 - Comparativa de criterios tcnicos.

- 38 -

3.4 Seleccin del Producto ESB


En este captulo se realiz un anlisis comparativo de los productos ESB Open Source con mayor difusin
en el mercado. La comparativa se bas en tres niveles: a nivel de criterios estratgicos, a nivel de
funcionalidad brindada por los productos ESB analizados y por ltimo a nivel tcnico. En particular, se
analizaron las funcionalidades brindadas por estos productos ESB que faciliten la implementacin de un
ESB Adaptativo, de acuerdo a los requerimientos de adaptacin de la plataforma.
Con respecto a la implementacin de los componentes requeridos por la Plataforma ESB Adaptativa, se
analizaron posibles implementaciones de los componentes primordiales, segn la documentacin de
cada producto. En particular, se analiz la implementacin de Servicios Virtuales, Gateway de
Adaptacin, Monitoreo de la mensajera 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
implementacin de la plataforma, algunos componentes se pueden implementar de forma ms directa
que otros. Adems, en algunos casos, el costo de implementacin depende en gran medida del producto
ESB especfico que se utilice.
En una primera instancia del proceso de seleccin se descart el producto Open ESB, ya que al momento
de realizada esta investigacin no contaba con una buena documentacin, y presentaba bajos niveles de
actividad. Posteriormente, la investigacin se enfoc en identificar aquellos productos que cuenten con
la mejor documentacin, para la implementacin de los componentes ms crticos de la plataforma
adaptativa. Entre los ms destacados, se encontraban JBoss ESB, Mule ESB y ServiceMix, por lo cual la
ltima decisin qued determinada por la experiencia del grupo en plataformas JBoss.
Finalmente, se decidi seleccionar JBoss ESB como producto base para la implementacin de la
plataforma, destacando la facilidad con la que puede ser extendido, adems de la gran comunidad
activa que posee. Adicionalmente, el producto JBoss ESB brinda un soporte adecuado para implementar
los Servicios Virtuales, Gateway de Adaptacin y la posibilidad de implementar fcilmente el patrn
Ruteo Basado en Itinerario, utilizando el componente Service Invoker que se describe en la Seccin
3.5.2.2.
De aqu en ms, cuando se mencione JBoss ESB nos referiremos a su ltima versin estable (v4.11) a la
fecha de Junio del 2012.

3.5 JBoss ESB


Esta seccin presenta un breve resumen de las caractersticas tcnicas particulares de JBoss ESB, en la
cual se basa la implementacin de la Plataforma ESB Adaptativa. En la sub-seccin 3.5.1 se presenta una
descripcin general de las tecnologas y el framework de la plataforma JBoss Enterprise SOA Platform,
mientras que la sub-seccin 3.5.2 describe cada uno de los componentes de JBoss ESB que fueron
utilizados y extendidos para implementar la Plataforma ESB Adaptativa.

- 39 -

3.5.1 Descripcin 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 tecnologas 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 slida, 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 cdigo abierto.

3.5.2 Componentes de JBoss ESB utilizados en la implementacin


Esta seccin se focaliza en aquellos componentes de JBoss ESB que fueron utilizados y extendidos en la
implementacin de la plataforma, con el objetivo de que la misma tenga la habilidad de generar y
procesar dinmicamente flujos de adaptacin, que permitan satisfacer los requerimientos de los
Servicios Virtuales registrados en la plataforma.
3.5.2.1 Definicin 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 categora 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 descomposicin no solo permite reutilizar los servicios, sino tambin las
acciones implementadas, ya que las mismas se pueden utilizar en mltiples servicios. Paralelamente,
JBoss ESB incluye un conjunto de acciones nativas que proveen funcionalidades de transformacin,
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 configuracin de un servicio JBoss ESB, cuya lista de acciones
est compuesta por una nica accin, la cual tiene la capacidad de escribir en la salida estndar el
mensaje SOAP que se haya enviado al ESB.

- 40 -

Figura 22 - Implementacin de Servicios en JBoss ESB. Extrada de [21].

3.5.2.2 Service Invoker


En la versin 4.2 de JBoss ESB se introduce la funcionalidad de Service Invoker para facilitar la
comunicacin entre servicios, no siendo necesario tener en cuenta detalles de bajo nivel como el
manejo de las fallas de los servicios. Es por esta razn que dicha funcionalidad se convirti en la opcin
recomendada para trabajar con servicios dentro de JBoss ESB.
La interfaz de Service Invoker expone un conjunto de mtodos los cuales permiten invocar sincrnica y
asincrnicamente servicios registrados en la aplicacin, indicando solamente la categora y el nombre
con el cual fueron registrados.
El transporte utilizado para la invocacin de un servicio est determinado por su configuracin y su
mbito de definicin. A continuacin 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 caracterstica que est presente desde la versin 4.3 de JBoss ESB, la cual
posibilita la comunicacin entre distintos servicios que estn 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 serializacin 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 travs 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-publicacin de dicho extremo
a travs del ESB. El ESB se localiza entre el consumidor/cliente y el productor/servidor.
El propsito de este intermediario es proporcionar una capa de abstraccin que proporcione las
siguientes ventajas:

El cliente no se conecta directamente al servicio remoto.

- 41 -

El cliente puede ver un WSDL modificado, cambiando los parmetros 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 travs del
componente ContentBasedRouter.

3.5.2.4 Gateway
Un gateway de aplicacin es un componente que se ejecuta en un servidor, el cual es el encargado de
interconectar dos redes/nodos. Cuando un cliente establece una conexin con un destino, se conecta a
una aplicacin de gateway. A partir de ese momento, el cliente interacta con el gateway con el fin de
comunicarse con el servicio destino. Una vez establecida la conexin, 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 continuacin 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 aplicacin HTTP, para exponer end-points.
Debido a la utilizacin 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 sern utilizados al momento de
interceptar los mensajes SOAP que llegan al ESB.
A modo de ejemplo, la Figura 23 presenta una configuracin donde se expone un end-point HTTP para
un servicio con categora Vehicles y nombre Cars. Esta configuracin permite interceptar todas aquellas
peticiones que llegan al ESB y coincidan con la URL http://<host>:<puerto>/<.esbname>/http/*.

Figura 23 - Configuracin de patrones de URL.

- 42 -

La propiedad allowedPorts de este componente permite limitar un servicio a un puerto especfico o a un


conjunto de ellos. Esto se especifica enumerando una lista de puertos deseados, como se presenta en la
Figura 24.

Figura 24 - Configuracin de restricciones de puertos.

La configuracin 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 cdigo de error HTTP (404).
Gateway JBR
El protocolo JBoss Remoting12 se puede utilizar como una opcin de transporte en JBoss ESB. Este
servicio se apoya en el protocolo HTTP(S) y Socket (+SSL) a travs de JBR.
A modo de ejemplo, la Figura 25 presenta una configuracin bsica de este componente.

Figura 25 - Configuracin de jbr-provider.

La configuracin 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 travs de un jbr-listener, para
exponer un servicio como Gateway.

Figura 26 - Configuracin del jbr-listener.

El JBR-Gateway posee un gran nmero de propiedades que pueden ser configuradas para el jbr-listener,
jbr-bus y jbr-provider. A continuacin, la Tabla 7 presenta las principales propiedades y sus valores por
defecto.

12

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

- 43 -

Nombre

Descripcin

Valor por defecto

synchronous

Servicio destino se invoca de forma sincrnica

True

serviceInvokerTimeout

Tiempo de espera de llamada asincrnica.

20000

asyncResponse

Respuesta asincrnica.

<ack/>

securityNS

Este es el espacio de nombres para la versin de


seguridad de servicios Web que se debe utilizar.

http://docs.oasis-open.org/wss/2004/01/oasis200401http-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
estn correlacionados. Una vez que un conjunto completo de mensajes ha sido recibido, el Aggregator
recoge informacin de cada mensaje correlacionado y genera un nico mensaje, agregndolo al canal de
salida para su posterior procesamiento.
3.5.2.6 Monitoreo y Administracin de Servicios
En JBoss ESB existe una serie de opciones para el seguimiento y la administracin de los servicios que se
encuentran dentro del servidor JBoss. En particular este producto proporciona una serie de MBeans que
exponen informacin 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 continuacin:

deployment: Dentro de deployment se puede visualizar el estado de todos los paquetes de ESB
que se han desplegado dentro del servidor, as como tambin obtener informacin acerca de la
configuracin y su estado actual.

listener-name: Dentro de esta opcin se visualizan todos los listeners desplegados en el


servidor, detallando informacin acerca de su configuracin, el tiempo de inicio, mxima
cantidad de hilos, estado, etc. El administrador tiene la opcin de inicializar, parar y destruir un
listener.

MessageCounter: Los contadores de mensajes agrupan todos los servicios desplegados en el


ESB, brindando informacin acerca de la cantidad de mensajes procesados, el tiempo de
procesamiento de cada uno de ellos, etc.

service-name: Muestra estadsticas de un servicio, como por ejemplo el nmero de mensajes, el


estado, el tamao promedio de mensaje, el tiempo de procesamiento, etc. Adems, el nmero
total de mensajes puede ser reseteado y los servicios pueden ser detenidos y reiniciados.

- 44 -

3.5.2.7 Servicios
Cada uno de los servicios registrados en el ESB puede ser visualizado en la consola de administracin
JMX, donde se detalla por accin 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 administracin JMX tambin proporciona un contador general de mensajes, el cual se
encarga de contar todos aquellos mensajes que pasan a travs del ESB. El Message-Counter mantiene un
registro de la cantidad de mensajes exitosos y fallidos, as como tambin la fecha y la hora de los
mismos.
3.5.2.9 Transformaciones
Para cada transformacin Smooks que est registrada en el ESB, existe un MBean que mantiene su
informacin, conteniendo este registro el tiempo de procesamiento de cada una de ellas y un recuento
total de la cadena de transformacin. Toda esta informacin puede ser visualizada desde la consola de
administracin 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.

- 45 -

- 46 -

4 Solucin Propuesta
En este captulo se describen las principales caractersticas de la plataforma implementada, presentando
en la Seccin 4.1 una descripcin conceptual de la solucin, y especificando en la Seccin 4.2 el esquema
general de su arquitectura, la cual se basa en la solucin propuesta en [1]. Conjuntamente, en la Seccin
4.3 se describen los distintos componentes de la plataforma, y cmo stos se implementaron en JBoss
ESB. En la Seccin 4.4 se describen las principales interacciones que se dan en tiempo de ejecucin entre
los componentes, ESB Adaptativo, Consola de Administracin y Motor de Adaptacin y Monitoreo. La
Seccin 4.5 presenta las distintas opciones de extensibilidad que posee cada uno de estos componentes.
Finalmente, en la Seccin 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 Descripcin Conceptual


En esta seccin se presenta una descripcin conceptual de la solucin desarrollada en este proyecto, la
cual implementa la plataforma propuesta en [1], basndose en las capacidades de mediacin del
producto JBoss ESB.
La Figura 27 permite distinguir entre aquellos componentes nativos de JBoss ESB y aquellos que fueron
extendidos o implementados especficamente para hacer frente a los requerimientos de la plataforma.

Figura 27 - Descripcin conceptual de la Arquitectura.

- 47 -

La plataforma implementada extiende las funcionalidades brindadas por JBoss ESB para poder abordar
de forma dinmica, automtica y en tiempo las distintas necesidades de adaptacin 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). Adems, se identifica un conjunto de funcionalidades nativas de JBoss ESB que debieron ser
extendidas con el fin de variar su comportamiento en tiempo de ejecucin. Un ejemplo de este tipo de
funcionalidades es la accin que aplica transformaciones XSLT, que debi ser modificada para soportar
la definicin de transformaciones en tiempo de ejecucin. 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 implementacin del ESB Adaptativo, se
encuentran la Consola de Administracin y el Motor de Administracin y Monitoreo, que brindan las
funcionalidades restantes para poder realizar el ciclo completo de configuracin, monitoreo y
adaptacin de los servicios registrados en la plataforma.

4.2 Arquitectura General


En esta seccin se presenta la arquitectura lgica 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
diseados especficamente para posibilitar el monitoreo y las adaptaciones en el ESB, de forma
dinmica, automtica y en tiempo de ejecucin.

Motor de Adaptacin y Monitoreo: este componente est diseado con el objetivo de brindar
soporte a la toma de decisiones de adaptacin y monitoreo en la plataforma, notificando al ESB
Adaptativo en aquellos casos que considere necesario.

Consola de Administracin: este componente est diseado para la administracin 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 informacin ms destacados. Adems, se
distingue entre los nuevos componentes de la plataforma y aquellos componentes internos de JBoss ESB
que fueron personalizados.

- 48 -

Figura 28 - Componentes de la Plataforma ESB Adaptativa.

La arquitectura propuesta est determinada principalmente por los siguientes requerimientos:

Los procesos de adaptacin no deben deteriorar la performance del sistema.

La plataforma debe contar con puntos de extensin que permitan agregar fcilmente nuevas
funcionalidades a las ya implementadas.

La plataforma debe permitir la ejecucin distribuida de cada uno de sus principales


componentes, permitiendo que la misma posea alta disponibilidad y escalabilidad.

Configurar y administrar fcilmente 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 Adaptacin, Servicios ESB, Administrador de Adaptacin, Administrador de Monitoreo,
Administrador de Requerimientos de Servicios y Mecanismos de Adaptacin y Monitoreo) y el Motor de
Adaptacin y Monitoreo. En el marco de este proyecto se decidi aadir a esta arquitectura un nuevo
componente denominado Consola de Administracin que se detalla en la Seccin 4.3.10.

- 49 -

El ESB Adaptativo es el principal componente en esta arquitectura, y es en donde se aplican


composiciones de servicios que se denominan flujos de adaptacin, los cuales se seleccionan en tiempo
de ejecucin para cada uno de los servicios registrados en la plataforma. Paralelamente, dicho
componente permite monitorear propiedades acerca de la calidad, saturacin 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 implementacin. Adicionalmente, se presentan
todas aquellas funcionalidades que no fueron consideradas en [1] pero estn 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 Adaptacin. Cada Servicio Virtual se encarga de acceder a un Web Service externo de
acuerdo al patrn Servicio Proxy Simple detallado en la Seccin 2.3.4.1. Por otro lado, los Servicios de
Adaptacin aplican mecanismos de adaptacin (como por ejemplo trasformaciones y ruteos) que
permiten realizar acciones de adaptacin en el ESB. La Figura 29 presenta grficamente 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 implementacin de este componente, se utiliz la forma estndar de definir servicios en


JBoss ESB, que consisten en especificar una serie de acciones que se encargan de procesar los mensajes
de manera secuencial.

- 50 -

4.3.1.1 Servicios de Adaptacin


Estos servicios utilizan los mecanismos de adaptacin para poder realizar las distintas acciones de
adaptacin que se contemplan en la plataforma.
JBoss ESB soporta de forma nativa varios de los mecanismos de adaptacin descriptos en la Seccin
2.5.2, salvo excepciones como el cache y el retardador de mensajes. Sin embargo, se realizaron
modificaciones sobre la gran mayora de dichos mecanismos, con el fin de obtener los datos de cada
mensaje de forma dinmica a partir de su itinerario adjunto, permitiendo que cada mecanismo pueda
variar su comportamiento en tiempo de ejecucin.
En la Tabla 8 se presentan los servicios bsicos con los que cuenta la plataforma implementada, para los
cuales se detalla su nombre, descripcin y el mecanismo utilizado en su accin de adaptacin.
Nombre

Descripcin

Mecanismo

TRN

Servicio encargado de aplicar la transformacin que se


encuentra en el itinerario del mensaje.

Transformacin

RUT

Servicio encargado de realizar el ruteo de un mensaje segn


cierta lgica 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 perodo de tiempo.

Retardador

Tabla 8 - Servicios de Adaptacin base de la plataforma.

En la plataforma implementada se manejan dos acciones de adaptacin por servicio, la primera accin
es la encargada de realizar la adaptacin, mientras que la segunda es la encargada de guiar el mensaje
segn el patrn 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 adaptacin, en este caso una transformacin, mientras que la
segunda dirige el mensaje hacia el prximo servicio, tal como lo especifica el itinerario adjunto al
mensaje.

- 51 -

Figura 30 - Configuracin del servicio TRN en JBoss ESB.

4.3.1.2 Servicios Virtuales


Para poder implementar Servicios Virtuales es necesario disponer de algn mecanismo que posibilite
consumir Web Services externos y adems 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 accin 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 configuracin que permite implementar un
servicio virtual en JBoss ESB, utilizando la accin SOAPProxy.

Figura 31 - Implementacin de un Servicio Virtual utilizando SOAPProxy.

En el ejemplo presentado se define un Servicio Virtual que se identifica con la categora eGov y el
nombre BPSWSProxy. El servicio definido realiza la invocacin a un Web Service externo que se
encuentra publicado donde lo especfica el WSDL determinado por la propiedad wsdl. Tal como se
describi en la Seccin 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

- 52 -

GLOBAL y ejecuta en la misma JVM. Adems, esta configuracin permite que los servicios virtuales se
encuentren en diferentes proyectos ESB.

4.3.2 Mecanismos de Adaptacin


Como se especifica en [1], los Mecanismos de Adaptacin (transformaciones, ruteo, etc.) permiten
aplicar acciones de adaptacin sobre los mensajes interceptados en el ESB Adaptativo, colaborando con
el objetivo principal de la plataforma de generar adaptaciones dinmicas, automticas y en tiempo de
ejecucin. Estos mecanismos se implementan en la plataforma utilizando las acciones genricas
brindadas por JBoss ESB, las cuales poseen un mtodo encargado de procesar cada mensaje que llega al
servicio donde fue definida dicha accin. Es en este mtodo donde se define toda la lgica 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 caractersticas y/o propiedades adicionales.
Nombre del Mecanismo

Caracterstica/Propiedad Adicional

Transformaciones

Lgica de transformacin

Ruteo intermediario

Lgica de ruteo
Servicios ESB destino

Lista de destinatarios

Servicios ESB destinos

Condicin de Completitud
(mejor respuesta)
Algoritmo de Agregacin

Cache

Mximo tiempo de almacenamiento

Retardador

Tiempo de retardo

Unificador de respuestas

Tabla 9 - Caractersticas y/o propiedades de los mecanismo de adaptacin.

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 ejecucin variar sus caractersticas y propiedades. Por esta razn, se debieron implementar
nuevas acciones que permitan obtener en tiempo de ejecucin la informacin 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 Seccin 5.1, presentando
en aquellos casos que corresponda, las acciones de JBoss ESB en la cual se bas la implementacin.

- 53 -

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 informacin 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 algn
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 comunicacin, como por ejemplo, HTTP, JMX y JMS, entre otros. La comunicacin 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 grficamente cmo un mecanismo de monitoreo interacta con servicios externos
a la plataforma, utilizando diferentes protocolos para la comunicacin.

Figura 32 - Invocacin a agentes de monitoreo externos.

JBoss ESB posee mecanismos de monitoreo nativos que exponen su informacin a travs de MBeans, los
cuales facilitaron la implementacin de los mecanismos encargados de monitorear las invocaciones a los
Servicios Virtuales. Sin embargo, fue necesario realizar una implementacin especfica que permita
monitorear los contratos de los Web Services externos, ya que el producto no ofrece ninguna
funcionalidad especfica para este cometido.
En la Seccin 5.2 se presentan cada uno de los mecanismos de monitoreo implementados, detallando
para cada uno de ellos la forma en que monitorean la informacin.

4.3.4 Administrador de Adaptacin


El Administrador de Adaptacin, es el componente encargado de gestionar los flujos definidos en las
directivas de adaptacin de cada Servicio Virtual. Como se especifica en [1], este componente recibe los
distintos flujos de adaptacin generados por el Motor de Adaptacin y Monitoreo, y los alberga durante

- 54 -

su tiempo de vida. Paralelamente, cada vez que el Gateway lo solicite, el Administrador de Adaptacin le
retorna cul es el flujo de adaptacin actual para un determinado servicio.
Concretamente, en la plataforma implementada, la comunicacin entre el Administrador de Adaptacin
y el Gateway de Adaptacin se realiza mediante la simple interaccin de clases Java, pues ambos
componentes se encuentran en el ESB Adaptativo. Sin embargo, la comunicacin entre el Administrador
de Adaptacin y el Motor de Adaptacin y Monitoreo es un poco ms compleja, ya que se utiliza el
protocolo de mensajera JMX13 para el envo de las distintas directivas de adaptacin.
La implementacin de este componente se basa en un HashMap en memoria, el cual asocia
identificadores de servicios virtuales con directivas de adaptacin. El HashMap guarda en memoria las
directivas de adaptacin de cada uno de los servicios virtuales. Por lo tanto, a partir del identificador de
un servicio virtual es posible obtener rpidamente su directiva de adaptacin.
A medida que el Motor de Adaptacin y Monitoreo genera nuevas directivas de adaptacin para un
servicio, utiliza la interfaz Java MBean para registrarlas en el ESB Adaptativo. El Administrador de
Adaptacin almacena para cada servicio la ltima directiva de adaptacin registrada, y cada vez que el
Gateway solicita el flujo de adaptacin actual de un servicio, este componente verifica si el servicio
posee un flujo de adaptacin vigente, y en este caso, el flujo es enviado directamente al Gateway. Si el
servicio no tiene definido ningn flujo, o el flujo de adaptacin actual ya expir, el Administrador de
Adaptacin le enva 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 Adaptacin.

Como funcionalidad adicional de la plataforma implementada, este componente guarda informacin


histrica acerca de los distintos flujos de adaptacin que se aplicaron para cada uno de los Servicios
Virtuales. Estos datos son tiles para la Consola de Administracin, la cual obtiene la informacin
utilizando mensajera JMX y luego la presenta de forma grfica.

13

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

- 55 -

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 enva al
Motor de Adaptacin 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 Adaptacin 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 enva al Motor de Adaptacin 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 Seccin 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 Seccin 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 informacin que monitorea la plataforma, permiten detectar
aquellas situaciones que generan nuevos requerimientos de adaptacin.

- 56 -

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 ms de 100 veces por un perodo de
tiempo (configurable).
Requerimiento

Servicio

1
2

SRV-3
SRV-3

Propiedad
Tiempo respuesta promedio
Cantidad de invocaciones

Operador

Valor

<
<=

1000ms
100

Tabla 10 - Ejemplo de Requerimientos de Servicios.

Los Requerimientos de Servicio complejos, como el requerimiento de cambio de contrato, se evalan


utilizando clases Java instanciadas e invocadas mediante Java Reflection.
Una vez definidos los requerimientos de los servicios virtuales, el Motor de Adaptacin y Monitoreo
puede solicitar, mediante la utilizacin de la interfaz Java MBean provista, que este administrador
evale 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 comunicacin.

Figura 35 - Interacciones del Administrador de Requerimientos de Servicios.

- 57 -

En la Seccin 5.4 se detalla cmo son registrados los Requerimientos de Servicios (complejos y simples)
y cmo stos son evaluados en tiempo de ejecucin.

4.3.7 Gateway de Adaptacin


Segn lo especificado en [1], este componente debe ser capaz de interceptar todos aquellos mensajes
que llegan al ESB y pretenden invocar un servicio virtual. Adems de interceptar los mensajes, este
componente debe interactuar con el Administrador de Adaptacin, para corroborar la existencia de
algn flujo de adaptacin. Para cada flujo de adaptacin 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 adaptacin. Cabe mencionar que la implementacin de este componente utiliza la propiedad
wsa:To del estndar 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 Adaptacin, 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 accin, lo cual garantiza que el procesamiento de las dos implementaciones sea idntico. Para
realizar estas implementaciones se utilizaron los componentes HTTP-Gateway y JBR-Gateway de JBoss
ESB. En lo que respecta a la implementacin que utiliza el listener HTTP-Gateway, se defini un patrn
de URL que garantiza un nico punto de acceso a la Plataforma ESB Adaptativa, mientras que en la
implementacin que utiliza el listener JBR-Gateway recibe y procesa las peticiones en un puerto
preestablecido.
En la Seccin 5.5 se brindan ms detalles de ambas implementaciones, donde se presenta la
configuracin particular de cada gateway.

4.3.8 Registro de Servicios y Configuracin


Como se detalla en [1], el Registro de Servicios tiene la responsabilidad de administrar la informacin de
los servicios virtuales que se registran en la Plataforma ESB Adaptativa. Adems, este componente se
encarga de gestionar las transformaciones, que permiten transformar el contenido de un mensaje desde
y hacia el modelo de datos cannico. 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 cmo es almacenada la informacin de los
servicios virtuales de la plataforma.

- 58 -

Figura 36 - Esquema de persistencia de la informacin almacenada por el Registro de Servicios.

Este registro tiene un papel significativo en la plataforma implementada, ya que la informacin 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 Informacin Almacenada sobre aquellos
servicios que sean de datos, y es el Registro de Servicios quien conoce sta informacin. 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 Administracin. El primero solamente consulta la
informacin almacenada, mientras que el segundo utiliza las funcionalidades del Registro de Servicios
para brindar una interfaz grfica, donde el usuario final puede registrar nuevos servicios virtuales, darlos
de baja, editar su informacin y definir servicios equivalentes.
De forma similar al producto JBoss ESB, la plataforma implementada brinda un conjunto de archivos
XML que permiten su configuracin. En la Seccin 5.6 se brindan ms detalles de la implementacin de
este componente.

4.3.9 Motor de Adaptacin y Monitoreo


El Motor de Adaptacin y Monitoreo se encarga de tomar las decisiones de adaptacin y de monitoreo
en la plataforma. Las responsabilidades definidas en [1] para este componente son las siguientes:

detectar cundo se debe generar un evento monitoreado para un servicio.

decidir cundo se debe generar un requerimiento de adaptacin para un servicio.

seleccionar una estrategia de adaptacin para abordar un requerimiento de adaptacin.

crear un flujo de adaptacin que implemente la estrategia seleccionada, utilizando los


mecanismos de adaptacin disponibles en el ESB.

notificar al Administrador de Adaptacin el nuevo flujo de adaptacin para un servicio.

El Motor de Adaptacin y Monitoreo se encuentra lgicamente fuera del ESB Adaptativo, y en la


plataforma implementada est compuesto por tres componentes, Administrador de Eventos,
Administrador de Requerimientos de Adaptacin y Administrador de Estrategias. La comunicacin entre

- 59 -

estos componentes se realiza mediante interacciones de clases Java, mientras que la comunicacin 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
seccin 5.7 se brindan ms detalles de la implementacin de cada uno.
4.3.9.1 Administrador de Eventos
El Administrador de Eventos, es responsable de obtener los requerimientos de servicios que no estn
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 Adaptacin.
La Tabla 11 presenta y describe cada uno de los Eventos Monitoreados que pueden ser detectados en la
configuracin base de la plataforma implementada.
Evento Monitoreado

Descripcin

degradacin-tiempo-respuesta

Detecta cundo un servicio virtual supera el umbral


preestablecido para su tiempo de respuesta.

degradacin-respuestas-exitosas

Detecta cundo un servicio virtual supera el umbral


preestablecido para la cantidad de fallas en sus
respuestas.

saturacin-servicio

Detecta cundo un servicio virtual supera la mxima


cantidad de peticiones que puede procesar por
perodo de tiempo.

cambio-contrato

Detecta cundo 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 Adaptacin


Este componente es el encargado de generar los nuevos Requerimientos de Adaptacin a partir de los
Eventos Monitoreados que dispara la plataforma. La Tabla 12, presenta y describe cada uno de los
Requerimientos de Adaptacin que se pueden generar en la configuracin base de la plataforma
implementada.

- 60 -

Requerimiento de Adaptacin

Descripcin

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 nmero 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 Adaptacin de la configuracin base de la plataforma.

4.3.9.3 Administrador de Estrategias


Este componente gestiona las distintas estrategias que permiten abordar los Requerimientos de
Adaptacin de la plataforma. El Administrador de Estrategias utiliza los servicios de adaptacin del ESB
para construir flujos que implementen las distintas Estrategias de Adaptacin.
En la Tabla 13 se describen las estrategias con las que cuenta la configuracin base de la plataforma
implementada, las cuales permiten abordar los Requerimientos de Adaptacin que genera el
Administrador de Requerimientos de Adaptacin.
Estrategia de Adaptacin

Descripcin

invocar-servicio-equivalente

Se invoca un servicio equivalente del servicio virtual para el cual que se


detect un requerimiento de adaptacin.

utilizar-informacin-almacenada

Se utiliza informacin previamente almacenada del servicio virtual para


el cual se detect un requerimiento de adaptacin.

distribuir-solicitud-equivalentes

Se distribuye la solicitud a un conjunto de servicios equivalentes del


servicio virtual que gener el requerimiento de adaptacin.

balancear-carga

Se balancea la carga de solicitudes entre varios servicios equivalentes al


servicio virtual que requiere una adaptacin.

diferir-pedidos

Se posterga el envo de la solicitud al servicio virtual para el cual se


detect el requerimiento de adaptacin.

modificar-solicitud-respuesta

Se modifica la solicitud o respuesta del servicio para el cual se detect


el requerimiento de adaptacin.

Tabla 13 - Estrategias de la configuracin base de la plataforma.

En este administrador se encapsula toda la lgica necesaria para implementar las estrategias bsicas de
adaptacin, lo que facilita una futura extensin del Motor de Adaptacin y Monitoreo. Adems, se

- 61 -

dispone de un componente capaz de producir estrategias elementales que pueden combinarse para
formar estrategias ms complejas.

4.3.10 Consola de Administracin


La Consola de Administracin es el componente que facilita la configuracin de la plataforma mediante
una interfaz grfica. Adems, permite el control y anlisis de los procesos de adaptacin que se generan
para cada servicio. Este componente est totalmente desacoplado del ESB Adaptativo y del Motor de
Adaptacin y Monitoreo, lo que posibilita una comunicacin bien definida mediante interfaces. La
comunicacin entre los principales componentes de la plataforma y la Consola de Administracin se
realiza a travs 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 adaptacin que se generan en la plataforma y almacenar
un histrico de los mismos.

configurar cada uno de los componentes de la plataforma.

La implementacin 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 categoras. Por una parte se agrupan aquellas
funcionalidades que facilitan la gestin de los Servicios Virtuales, y por otra parte, aquellas que permiten
tanto la configuracin del Motor de Adaptacin y Monitoreo, como la del ESB Adaptativo. En la Seccin
5.8 se detallan cada una de las funcionalidades implementadas para este componente.

4.4 Interaccin entre componentes


En esta seccin se describen las principales interacciones que se dan en tiempo de ejecucin, entre los
componentes de la Plataforma ESB Adaptativa, haciendo especial nfasis en la interaccin entre los
componentes ESB Adaptativo y el Motor de Adaptacin y Monitoreo.

4.4.1 Envo de Propiedades Monitoreadas al Motor de Adaptacin y Monitoreo


Como se mencion en la Seccin 0, el Administrador de Monitoreo tiene como responsabilidad, calcular
los valores de las propiedades que monitorea la plataforma y enviarlos al Motor de Adaptacin 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
15

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

- 62 -

de obtener informacin acerca de los Servicios Virtuales. Dicha informacin 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 Adaptacin 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 - Envo de Valores de Propiedades Monitoreadas.

En este caso, el Administrador de Monitoreo interacta 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 lgica de monitoreo, tal es el caso del monitoreo de cambio de contrato,
donde no existe interaccin 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
Adaptacin y Monitoreo para su posterior procesamiento. El envo de esta propiedad se realiza a travs
de la interfaz Java MBean expuesta por el Motor de Adaptacin y Monitoreo.
Como variante a esta secuencia, el Administrador de Monitoreo puede tener que interactuar con ms de
un Mecanismo de Monitoreo para calcular el valor de una propiedad.

- 63 -

4.4.2 Mecanismo de Monitoreo para Cambio de Contrato


Los cambios de contratos son detectados mediante un Mecanismo de Monitoreo diseado
especficamente 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, envindole toda la informacin del servicio que se desea
monitorear. Esta informacin es utilizada por el mecanismo para obtener la ubicacin del WSDL del
servicio externo. Luego de obtener la ubicacin donde se encuentra publicado el WSDL externo, el
mecanismo de monitoreo se responsabiliza de obtener su informacin y almacenarla. A partir de este
momento, el mecanismo compara la ltima informacin del contrato del servicio con la informacin
previamente almacenada. Si se encuentra algn tipo de diferencia entre los contratos, ya sea a nivel de
operaciones o parmetros, el mecanismo se encarga de almacenar esta informacin como la ltima
informacin monitoreada, y adems descarta la informacin anterior. En caso que no se detecten
diferencias, permanece almacenada la informacin del monitoreo recabada anteriormente. Cabe
mencionar, que al existir diferencias en la comparacin 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 adaptacin 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.

- 64 -

4.4.3 Envo de Directivas de Adaptacin


Los cambios en el valor de una propiedad monitoreada, pueden ocasionar que se generen nuevos
requerimientos de adaptacin para un servicio, ante lo cual la plataforma debe responder con una
directiva de adaptacin para abordarlo. En la Figura 39 se presentan las interacciones que realiza el
Motor de Adaptacin y Monitoreo cuando recibe las propiedades monitoreadas desde el Administrador
de Monitoreo. En caso que el motor detecte un nuevo requerimiento de adaptacin, deber interactuar
con los diferentes componentes de la plataforma, para finalmente generar una nueva directiva de
adaptacin y enviarla al Administrador de Adaptacin.

Figura 39 - Envo de directivas de adaptacin.

El Administrador de Monitoreo enva el valor de una propiedad monitoreada al Motor de Adaptacin y


Monitoreo, por ejemplo, el tiempo de respuesta promedio de un servicio. El motor recibe este valor e
interacta con el Administrador de Requerimientos de Servicios para obtener aquellos requerimientos
que no estn siendo satisfechos. A partir de la informacin recibida, el motor decide si se est ante una
situacin (evento monitoreado) que pueda generar un requerimiento de adaptacin. 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 adaptacin (dependiendo
del contexto, estrategias registradas y los metadatos del servicio). En caso que se genere un nuevo
requerimiento de adaptacin, el Motor de Adaptacin y Monitoreo puede necesitar interactuar con el
Registro de Servicios para seleccionar e implementar una estrategia de adaptacin. Una vez
seleccionada e implementada la estrategia a travs de un flujo de adaptacin, sta se enva como nueva
directiva de adaptacin, pudindose especificar adems una fecha de expiracin. Las directivas de
adaptacin en la Plataforma ESB Adaptativa tienen el siguiente formato id de servicio - flujo de
adaptacin - fecha de expiracin.

- 65 -

Como variante a la interaccin anterior, el motor puede generar un requerimiento de adaptacin para el
cual no exista una estrategia de adaptacin que lo aborde. En este caso el motor se encarga de notificar
esta situacin y finalizar sus interacciones.

4.4.4 Adaptacin en el ESB


Cuando el Administrador de Adaptacin recibe una nueva directiva de adaptacin para un servicio, la
almacena, y todas las subsiguientes invocaciones al servicio aplicarn la directiva almacenada hasta que
su tiempo de vigencia expire o sea reemplazada por una nueva. En la Figura 40, se presenta cmo se
desarrolla una invocacin a un Servicio Virtual, para el cual existe una directiva de adaptacin vigente en
el Administrador de Monitoreo.

Figura 40 - Adaptacin en el ESB.

En una primera instancia, la Aplicacin Cliente enva una peticin al ESB Adaptativo para invocar al
servicio SRV-1. El ESB intercepta dicha peticin y la redirige al Gateway de Adaptacin, el cual obtiene
desde el Administrador de Adaptacin la directiva vigente para el servicio que se desea invocar. En caso
de que no exista una directiva de adaptacin vigente para el servicio invocado, se retorna directamente
el Servicio Virtual. Luego que el Administrador de Adaptacin retorne la directiva, el Gateway de
Adaptacin se encarga de adjuntarla al mensaje, para que posteriormente sea procesada segn el
patrn de Ruteo Basado en Itinerario. Finalmente, el Gateway de Adaptacin redirige el mensaje hacia el
primer nodo del flujo contenido en la directiva de adaptacin del servicio invocado.
El flujo de adaptacin de la Figura 40, consiste en invocar secuencialmente a los servicios de RET y SRV1. El servicio RET procesa el mensaje y avanza el flujo al prximo nodo, aplicando cierto retardo antes de
redirigir el mensaje hacia el prximo servicio. Luego que el mensaje llega al servicio SRV-1, ste invoca a
un Web Service externo y retorna su respuesta hacia la Aplicacin Cliente que realiz la peticin.

- 66 -

Como variante al flujo anterior, puede ocurrir que la respuesta retornada por el Web Service tenga que
ser transformada antes de redigirla hacia la Aplicacin Cliente. Este caso es comn 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 Adaptacin


Como se describe en la Seccin 4.4.4, cuando existe una directiva de adaptacin vigente para un
servicio, el Gateway de Adaptacin se encarga de adjuntar un flujo de adaptacin a todos los mensajes
que pretendan invocarlo.
A modo de ejemplo, la Figura 41 presenta cmo se procesa un mensaje a travs de un flujo de
adaptacin, que consiste en balancear la carga (RBAL) entre dos servicios equivalentes (SRV-2 y SRV-3).

Figura 41 - Procesamiento del Flujo de Adaptacin.

Como se observa en la Figura anterior, el mensaje posee un flujo de adaptacin adjunto a travs del cual
debe ser procesado (1), cada paso de procesamiento (RBAL, SRV-2, SRV-3) se encarga de avanzar una
posicin en dicho flujo, para que posteriormente la accin del itinerario enve el mensaje al prximo
destino, de esta manera la Plataforma ESB Adaptativa conoce cules son los prximos 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 sincrnica.
Una vez obtenida la respuesta del Web Service externo (que puede ser almacenada para su posterior
utilizacin) se avanza una posicin en el flujo de adaptacin. Una vez que el flujo no posea mas pasos
(6), el mensaje es ruteado por el ESB a la Aplicacin Cliente que corresponda.

4.4.6 Interaccin de la Consola de Administracin


Como se mencion en la Seccin 4.3.10, la Consola de Administracin tiene como responsabilidad
facilitar la configuracin y la administracin de la plataforma. Para esto, debe interactuar con distintos

- 67 -

componentes de la plataforma, con el fin de obtener informacin acerca de los servicios y presentarla
de forma grfica al usuario.
A modo de ejemplo, la Figura 42 presenta las interacciones que realiza la Consola de Administracin
para obtener y persistir los datos de configuracin (metadatos, transformaciones, etc.) de un servicio
registrado.

Figura 42 - Interaccin para la modificacin de un Servicio Virtual.

En primer lugar, la Consola de Administracin se comunica con el sub-componente Registros de


Servicios y Configuracin del ESB Adaptativo, solicitando toda la informacin disponible acerca de un
Servicio Virtual. Esta informacin contiene los metadatos de servicio, como por ejemplo, nombre,
categora y endpoint del Web Service externo, entre otros. En segundo lugar, en caso de que el servicio
tenga definidas transformaciones cannicas, 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 cannico. Finalmente, en caso de que se realice alguna modificacin 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 Adaptacin y Monitoreo y Consola de Administracin, cada uno de estos componentes se
encuentran organizados a su vez en sub-componentes. Este diseo basado en componentes y sub-

- 68 -

componentes permite fcilmente la reutilizacin de las funcionalidades ya existentes, para el desarrollo


de nuevas funcionalidades que den soporte a nuevos requerimientos.
Adicionalmente a lo mencionado, los sub-componentes ms 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 configuracin 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 Seccin 4.5.1, los principales componentes de la plataforma (ESB Adaptativo,
Motor de Adaptacin y Monitoreo, Consola de Administracin) se intercomunican a travs de interfaces
Java MBeans, lo que posibilita el cambio de los distintos componentes por otras implementaciones, as
como tambin la posibilidad de desplegar cada uno de ellos en diferentes servidores fsicos o virtuales.
La extensibilidad a nivel de componentes est dada por las distintas interfaces que exponen cada uno de
ellos. En la Seccin 4.5.3 se describen algunas de las operaciones presentes en la interfaz que expone el
componente ESB Adaptativo para su administracin.

4.5.2 Extensibilidad a nivel de sub-componentes


La extensibilidad a nivel de sub-componentes est dada mediante la configuracin de archivos XML, los
cuales registran funcionalidades, que son cargadas en tiempo de despliegue, y que pueden ser
actualizadas desde la Consola de Administracin en tiempo de ejecucin. En particular, los componentes
ESB Adaptativo y Motor de Adaptacin y Monitoreo, cuentan con archivos de configuracin XML que
permiten fcilmente 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 ejecucin utilizando Reflection16, o mediante archivos de configuracin, 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
Adaptacin 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 configuracin de este componente son los
siguientes:

16

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

- 69 -

Mecanismos de monitoreo: El archivo de configuracin jboss-adaptative-monitormechanism.xml permite definir nuevos mecanismos de monitoreo, que posibilitan extender el
conjunto de los mecanismos brindados por la plataforma.

Propiedades monitoreadas: En el archivo jboss-adaptative-properties.xml, se localizan las


diferentes propiedades que se monitorean en la plataforma, y es posible agregar nuevas
propiedades que permitan abordar nuevos requerimientos.

Requerimientos de servicios: En el archivo jboss-adaptative-service-requirements.xml, se


definen los requerimientos de servicios considerados por la plataforma, permitiendo definir en
este archivo nuevos requerimientos que posibilitan extender los ya existentes.

Configuracin 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 Adaptacin y Monitoreo


Los puntos de extensibilidad y los respectivos archivos de configuracin de este componente se detallan
a continuacin:

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

Requerimientos de adaptacin: En el archivo jboss-adaptative-adaptation-requirements.xml se


pueden definir nuevos requerimientos de adaptacin que sern generados por el Motor de
Adaptacin y Monitoreo, a partir de los eventos que son disparados por la plataforma.

Estrategias de adaptacin El archivo jboss-adaptative-strategies.xml permite especificar nuevas


estrategias de adaptacin, que posibiliten abordar los distintos requerimientos de adaptacin
que se generan en la plataforma.

4.5.3 Interfaz de Administracin 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 administracin 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 interaccin entre el ESB
Adaptativo y los componentes Consola de Administracin y Motor de Adaptacin y Monitoreo,
permitiendo el desacoplamiento de los principales componentes de la plataforma.

- 70 -

Figura 43 - Interfaz EsbAdmServicesMBean.

4.6 Limitaciones y mejoras


En esta seccin 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 diseo, 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 implicaran.

Limitaciones y mejoras para el componente ESB Adaptativo


Actualmente, el ESB Adaptativo considera un intervalo de tiempo fijo para la obtencin y clculo 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
ms sensibles al paso del tiempo y deban tener un intervalo de actualizacin reducido, as como
tambin existirn otros casos donde el tiempo de procesamiento es elevado, y por tal motivo se
debern configurar intervalos de tiempo ms extensos. Por dichos motivos, se concluye que establecer
tiempos individuales para los intervalos de clculo de propiedades y mecanismos, sera una mejora
significativa en el ESB Adaptativo.
Actualmente el sistema maneja un nico hilo para la ejecucin de los mecanismos de monitoreo y el
clculo de las propiedades monitoreadas. El cambio propuesto implica mantener distintos hilos de
ejecucin para cada uno de los mecanismos, y as poder controlar de forma individual sus intervalos de
ejecucin.

- 71 -

Limitaciones y mejoras para el componente Motor de Adaptacin y Monitoreo


El Motor de Adaptacin y Monitoreo encapsula la lgica necesaria para procesar la informacin que
recibe del ESB Adaptativo y evaluar qu estrategia de adaptacin se debe utilizar para cada servicio. Una
de las mejoras a efectuar en este componente, es la reutilizacin de esta lgica para dar soporte a
mltiples ESB Adaptativos. Implementar esta mejora en el sistema no implica grandes esfuerzos, dado
que se cuenta con archivos de configuracin, donde se establecen los distintos canales de comunicacin
utilizados, por lo que solamente se deber extender esta funcionalidad para poder registrar ms 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 ms de una estrategia de adaptacin para abordar
un determinado requerimiento, el motor toma una decisin aleatoria para escoger cul estrategia
aplicar. La toma de este tipo de decisiones podra mejorarse notoriamente si se considerara informacin
histrica de los servicios, o algn algoritmo de aprendizaje automtico como una red neuronal, que
detecte patrones comunes en el conjunto de servicios registrados en la plataforma.

Limitaciones y mejoras del componente Consola de Administracin


Dado que la Consola de Administracin 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 algn otro componente, para luego consumirla y exponerla de forma
grfica al usuario.
A pesar de que la Consola de Administracin permite la recarga en tiempo de ejecucin de todos los
archivos de configuracin, stos no pueden ser editados desde la interfaz grfica, lo que es una gran
limitante para una administracin amigable de la plataforma. La implementacin de esta nueva
funcionalidad implicara que cada uno de los componentes exponga en su interfaz, mtodos que
permitan la edicin de cada uno de sus archivos de configuracin. Adems, la Consola de Administracin
debera proveer grficamente una vista que simplifique la edicin de las distintas configuraciones.
Otro conjunto interesante de funcionalidades para integrar a la Consola de Administracin, son las que
permitan generar y administrar estadsticas de la plataforma, como por ejemplo almacenar informacin
del servicio con ms adaptaciones, la cantidad de estrategias utilizadas para cada servicio, estrategias
ms eficaces y estrategias ms utilizadas, entre otras. Esto permitira visualizar en distintos grficos la
evolucin de las adaptaciones de cada uno de los servicios. Una implementacin acotada de estas
funcionalidades, es posible con las interfaces que actualmente exponen los distintos componentes, las
cuales permiten obtener el histrico de los flujos de adaptacin de los servicios. Por lo tanto, solo
restara implementar en la consola, aquellas funcionalidades que permitan obtener, almacenar y
desplegar la informacin.

- 72 -

5 Detalles de Implementacin
En esta seccin se presenta detalladamente la implementacin de los componentes ms relevantes de
la plataforma, describiendo tambin aquellos componentes que pueden ser reutilizados en otros
proyectos que utilicen JBoss ESB. Adems, se comentan los principales problemas encontrados durante
la implementacin de la Plataforma ESB Adaptativa.

5.1 Mecanismos de Adaptacin


Los mecanismos de adaptacin implementados en la plataforma base son los descriptos en la Seccin
4.3.2, los cuales se encargan de realizar las acciones de adaptacin en el ESB.
Especficamente, se implementaron mecanismos de adaptacin que obtienen dinmicamente la
informacin del itinerario de cada mensaje, y se basan fuertemente en los mecanismos de adaptacin
provistos por JBoss ESB. En la Tabla 14 se presentan cada uno de los mecanismos de adaptacin
implementados, describiendo para cada uno de ellos, la accin del producto en la cual se basa.
Mecanismo

Accin JBoss ESB

Accin Personalizada

Transformacin

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

Invocacin 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 accin en JBoss ESB

org.fing.edu.uy.esbadp.action.cache. CacheLoadAction

Retardador

No existe accin 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 cdigo 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 especificacin del servicio
definido en el archivo jboss-esb.xml, tal como lo realizan la acciones nativas del producto.
En cuanto a la implementacin 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, agregndole a cada

- 73 -

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 accin retorne la primera respuesta obtenida para un identificador
dado, y descarte el resto. Esta implementacin se bas fuertemente en la accin Aggregator de JBoss
ESB.
Por otra parte, la implementacin 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 implementacin de los mecanismos de adaptacin cache e itinerario se describen con
detenimiento en la Seccin 5.9.

5.2 Mecanismos de Monitoreo


Como se mencion en la Seccin 0, la Plataforma ESB Adaptativa monitorea la informacin 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 informacin para cada uno de
ellos, como por ejemplo el tiempo de respuesta y el xito de sus invocaciones, entre otros. Esta
informacin 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 deteccin de eventos monitoreados por parte de la
plataforma, como lo son: la degradacin del tiempo de respuesta, la degradacin de respuestas exitosas
y la saturacin de los servicios. A continuacin, se describe la implementacin de aquellos mecanismos
de monitoreo que obtienen informacin 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
informacin a travs de Java MBeans, que pueden ser accedidos desde cualquier cliente que soporte el
protocolo de mensajera JMX. Concretamente, este mecanismo de monitoreo obtiene su informacin
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 informacin a travs de Java MBeans. En particular, la implementacin de este mecanismo,

- 74 -

obtiene su informacin del atributo messages failed count brindado por el MBean MessageCounter de
JBoss ESB.
Monitoreo del tiempo de respuesta
JBoss ESB expone de forma nativa, informacin del tiempo de respuesta de cada uno de sus servicios. Al
igual que en los mecanismos anteriores, la informacin 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 fcilmente estos
mecanismos, sin tener la necesidad de crear nuevos servicios que recaben informacin 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 adaptacin para manejar los distintos cambios
que se producen en los contratos de los servicios.
En cuanto a la implementacin, este mecanismo no consume ninguna de las funcionalidades brindadas
por JBoss ESB, ya que el producto no realiza ningn tipo de seguimiento sobre los contratos de los
servicios a los que accede. Sin embargo, la implementacin de esta funcionalidad se bas en la idea
presentada en [22], donde se desarroll una herramienta capaz de comparar documentos WSDL. En
particular, la implementacin realizada utiliza las funcionalidades brindadas por la biblioteca EasyWSDL
[23], que permite manipular fcilmente 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 versin del WSDL de
dicho servicio, para posteriormente proseguir a la comparacin de los WSDLs. De no existir una versin
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 algn 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 cmo 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, adems de los esquemas auxiliares que utiliza el propio documento WSDL.

17

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

- 75 -

Figura 44 - Estructura para el almacenamiento de los contratos de los servicios.

Cabe mencionar, que para soportar el tipo de publicacin DOCUMENT y RPC se debieron crear dos
versiones del comparador, ya que la forma en que stos organizan la informacin 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 operacin.

Soportado. No afecta comportamiento.

Renombrar operacin.

Solamente se detecta este cambio si los parmetros de entrada y de salida de la nueva


operacin y de la antigua son idnticos, tanto en sus nombres como en sus tipos de
datos. Cabe aclarar, que tambin se valida que la antigua operacin no siga existiendo en
el nuevo WSDL, ya que en este caso el sistema interpretar que existe una nueva
operacin en el contrato del servicio.

Quitar operacin.

No soportado. No es posible manejarlo.

Modificar MEP de operacin.

No soportado.

Agregar Parmetro.

Soportado siempre y cuando el nuevo parmetro admita un valor por defecto. El sistema
interpretar la existencia de un nuevo parmetro, cuando no se elimine un parmetro y
se agregue otro con el mismo tipo de dato y en la misma posicin.

Renombrar Parmetro.

Soportado. El sistema interpretar un renombre de parmetro cuando en el nuevo WSDL


exista un parmetro que no exista en el WSDL antiguo, y adems sus tipos de los datos y
sus posiciones en ambos WSDL sean iguales.

Cambiar Opcionalidad Parmetro.

No soportado.

Cambiar Orden Parmetros.

No soportado.

Quitar Parmetro.

Soportado.

Tabla 15 - Cambios en los contratos de los servicios soportados por la plataforma.

La informacin recabada por este mecanismo es utilizada por la estrategia encargada de manejar los
cambios de contrato de los servicios, que a partir de dicha informacin genera transformaciones XSLT,
permitiendo seguir invocando a un servicio que sufri cambios en su contrato.

- 76 -

5.3 Administrador de Monitoreo


Como se menciona en la Seccin 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 perodo 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
enva dichas propiedades al Motor de Administracin y Monitoreo, y se vuelve a dormir. La Figura 45
presenta una pequea mquina 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 adems brinda la posibilidad de extender este
conjunto como se detalla en la Seccin 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 mtodo, que es invocado por el Administrador de
Monitoreo cada vez que se requiera calcular el valor de dicha propiedad.
El mtodo definido en la interfaz recibe la lista de los valores obtenidos por los mecanismos de
monitoreo, junto con la informacin del servicio para el cual se requiere calcular las propiedades
monitoreadas. Este mtodo, tiene la responsabilidad de retornar el objeto que representa la propiedad
calculada, permitiendo implementar cualquier lgica para el clculo de una propiedad.
El valor de estas propiedades se calcula a partir de la informacin 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 fcilmente
segn la informacin monitoreada por el mecanismo Monitoreo de Tiempo de Respuesta. En otros
casos, como por ejemplo, la propiedad cantidad de invocaciones, el clculo se realiza a partir de la

- 77 -

informacin de varios mecanismos de monitoreo. La cantidad de invocaciones de un servicio se calcula


como la suma de la cantidad de invocaciones exitosas, ms 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.
Descripcin

Mecanismos utilizados

Forma de clculo

Cantidad de invocaciones por


unidad de tiempo.

Invocaciones exitosas.
Invocaciones con fallas.

Inv. exitosas + Inv. con fallas

Porcentaje de respuestas
exitosas

Invocaciones exitosas.
Invocaciones con fallas.

Inv. exitosas * 100 / (Inv. exitosas + Inv. con fallas)

Tiempo de respuesta promedio

T. de respuesta total
Invocaciones exitosas.
Invocaciones con fallas.

T. de respuesta total / (Inv. exitosas + Inv. con fallas)

Diferencias detectadas en el
WSDL

Cambio de contrato.

Diferencias ( wsdl1, wsdl2)

Tabla 16 - Propiedades implementadas en la plataforma.

5.4 Administrador de Requerimientos de Servicios


Segn lo mencionado en la Seccin 4.3.6, el Administrador de Requerimientos de Servicios gestiona toda
la informacin 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 lgica 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 cmo 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.

- 78 -

Cada servicio registrado en la plataforma debe tener definido en su metadata un valor que especifique
el tiempo lmite 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 lmite del servicio.
Por otra parte, cuando el requerimiento de servicio es de tipo complejo, se debe especificar el nombre
cannico 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 cmo 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 algn cambio.
Luego que este administrador culmina la evaluacin de los requerimientos de un servicio, retorna el
conjunto de requerimientos que no se satisfacen al Motor de Adaptacin y Monitoreo.

5.5 Gateway de Adaptacin


Como se menciona en la seccin 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 accin GatewayAction implementada en la
plataforma, la cual se encarga de interactuar con el Administrador de Adaptacin y adjuntar los flujos de
adaptacin en los mensajes.
La Figura 48, presenta la implementacin del Gateway de Adaptacin basada en el listener HTTPGateway, donde se visualiza que el action pipeline consta de una nica accin denominada
GatewayAction. Por otra parte, se puede ver que el listener Http definido posee un patrn de URL, el
cual es utilizado por el servidor de aplicacin para dirigir las peticiones que concuerden con el contexto
/http/* hacia la accin GatewayAction.

- 79 -

Figura 48 - Implementacin del Gateway de Adaptacin basada en HTTP-Gateway.

A continuacin, la Figura 49 presenta la segunda implementacin del Gateway de Adaptacin, la cual se


basa en el listener JBR-Gateway de JBoss ESB.

Figura 49 - Implementacin del Gateway de Adaptacin basada en JBR-Gateway.

En este caso, el servicio consta de un nico listener y de una nica accin 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 accin de adaptacin es la misma que se utiliza en la
implementacin basada en HTTP-Gateway.

5.6 Registro de Servicios y Configuracin


El Registro de Servicios y Configuracin encapsula toda la lgica que permite agregar, eliminar y
modificar la informacin de los servicios virtuales y de sus relaciones. Adems, permite cargar los
archivos de configuracin de la plataforma, posibilitando por ejemplo, activar el registro de histricos de
las adaptaciones que se realizan sobre los servicios virtuales. La implementacin 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 gestin se puede realizar utilizando la Consola de Administracin, o bien invocando
directamente las interfaces Java MBean que expone la plataforma.

- 80 -

La informacin de los servicios virtuales y de sus relaciones, es persistida en una base de datos
relacional, utilizando el mismo DataSource de los archivos de configuracin de JBoss ESB (jbossesbproperties.xml), el cual permite seleccionar entre varios motores de base de datos.
En la Figura 50, se detalla el modelo de datos utilizado para la persistencia de los servicios, las relaciones
de equivalencia y la metadata de los servicios.

Figura 50 - Modelo de datos ESB Adaptativo.

La tabla SERVICE persiste informacin 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: categora 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: representacin en cadena de caracteres de la metadata.

Por ltimo, la tabla SERVICE_EQUIV persiste la relacin 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.

- 81 -

Los archivos que definen las transformaciones desde y hacia el modelo de datos cannico son
persistidos directamente en disco, segn 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 cannico, 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 cannicas.

5.6.2 Archivos de configuracin y definicin.


Como se menciona en la Seccin 4.3.8, la plataforma maneja una gran cantidad de archivos de
definicin, que permiten especificar los distintos puntos de extensibilidad. Estos archivos se cargan en
tiempo de despliegue y pueden ser recargados en tiempo de ejecucin. La plataforma cuenta adems
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 aplicacin 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

Descripcin

Archivo

SleepTimeThreadAdmMonitor

Intervalo en segundos del clculo de las propiedades


monitoreadas por el Administrador de Monitoreo

jboss-adaptative-config.xml

CompareWSDLImpl

Nombre cannico de la clase Java que implementa el


comparador de WSDL

jboss-adaptative-config.xml

MotorMonitorURL

Url del servicio MBean expuesto por el Motor de Adaptacin


y Monitoreo.

jboss-adaptative-config.xml

MotorMonitorObjectName

Nombre del servicio MBean expuesto por el Motor de


Adaptacin y Monitoreo.

jboss-adaptative-config.xml

PathWSDLStore

Ruta relativa a la instalacin de JBoss ESB donde son


persistidos los WSDL utilizados por el comparador.

jboss-adaptative-config.xml

PathXSLTStore

Ruta relativa a la instalacin de JBoss ESB donde son


persistidos los archivos XSLT para las transformaciones
desde y hacia el modelo de datos cannico.

jboss-adaptative-config.xml

Tabla 17 - Propiedades de configuracin para el ESB Adaptativo.

- 82 -

Nombre

Descripcin

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 adaptacin (en


milisegundos).

config.properties

motor.historic.flag

Habilita el registro del histrico de las estrategias de adaptacin


utilizadas para cada servicio.

config.properties

motor.historic.count

Cantidad mxima de flujos de adaptacin almacenados por servicio.

config.properties

Tabla 18 - Propiedades de configuracin para el Motor de Administracin y Monitoreo.

5.6.3 Histrico de Adaptaciones


La implementacin del Histrico de Adaptaciones permite almacenar los ltimos flujos de adaptacin
que fueron procesados por la plataforma, los cuales se pueden observar grficamente desde la Consola
de Administracin. El registro de esta informacin histrica genera un overhead al final de cada ciclo de
adaptacin, y produce un gran volumen de informacin. Por esta razn, se mantiene en memoria una
lista circular FIFO, con los flujos procesados para cada servicio, permitiendo almacenar sus ltimos n
flujos de adaptacin, correspondientes a sus ltimas n invocaciones. El valor de n es parte de la
configuracin de la plataforma, siendo su valor por defecto 10.
Adicionalmente, existe la opcin de deshabilitar esta funcionalidad para aquellos ambientes donde no
se requiera analizar informacin histrica, o se tengan otros mecanismos para hacerlo.

5.7 Motor de Adaptacin y Monitoreo


Como se describe en la Seccin 4.3.9, el Motor de Adaptacin y Monitoreo debe ser capaz de recibir las
propiedades monitoreadas por el ESB Adaptativo, enviar directivas de adaptacin al Administrador de
Adaptacin y brindar mecanismos que permitan tomar decisiones de adaptacin.
En la plataforma implementada, cada vez que el ESB Adaptativo notifica que existen nuevas propiedades
monitoreadas para un servicio, el Motor de Adaptacin y Monitoreo crea un nuevo hilo de ejecucin,
que se encarga de procesar la informacin recibida, para luego generar nuevas directivas de adaptacin
en caso que considere necesario. La Figura 52 detalla los estados por los que transitan los hilos creados
por el Motor de Adaptacin y Monitoreo.

- 83 -

Figura 52 - Estados y transiciones de los hilos creados por del Motor de Adaptacin y Monitoreo.

El Motor de Adaptacin y Monitoreo implementa la lgica que permite decidir qu directiva de


adaptacin se utiliza en aquellos escenarios donde exista ms de un requerimiento de adaptacin, o
ms de una estrategia que aborde un mismo requerimiento. La implementacin 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 adaptacin. La lgica implementada para
combinar estas directivas de adaptacin, puede ser reutilizada en la implementacin de un motor ms
inteligente, que genere flujos de adaptacin ms 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 adems sufri cambios en su
contrato.

- 84 -

Figura 53 - Combinacin de estrategias.

En las siguientes sub-secciones se describen cada uno de los sub-componentes que conforman el Motor
de Adaptacin y Monitoreo.

5.7.1 Administrador de Eventos


Este administrador es el encargado de la gestin 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 configuracin 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 cmo se define el evento Degradacin 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 configuracin de un Evento Monitoreado.

Se debe tener en cuenta, que los nombres de requerimientos de servicios definidos en el archivo jbossadaptative-events.xml, deben coincidir con los que fueron definidos previamente en el archivo jbossadaptative-service-requirements.xml, los cuales son utilizados por el Administrador de Requerimientos

- 85 -

de Servicios para realizar la evaluacin de los requerimientos de los servicios registrados en la


plataforma.

5.7.2 Administrador de Requerimientos de Adaptacin


Este administrador es el encargado de gestionar los Requerimientos de Adaptacin de la plataforma
implementada, los cuales se generan a partir de los distintos Eventos Monitoreados.
A modo de ejemplo, la Figura 55 detalla cmo definir un Requerimiento de Adaptacin para disminuir el
nmero de solicitudes que recibe un determinado servicio. En este caso, el Requerimiento de
Adaptacin se genera luego de que la plataforma detecta un evento de saturacin de servicio.

Figura 55 - Requerimiento de adaptacin para una saturacin de servicio.

En el marco de este proyecto se decidi realizar una asociacin uno a uno entre los Eventos
Monitoreados y los Requerimientos de Adaptacin que stos generan. En particular, los eventos
degradacin-tiempo-respuesta, degradacin-respuestas-exitosas, saturacin-servicio y cambio-contrato
generan los requerimientos de adaptacin disminuir-tiempo-respuesta, aumentar-respuestas-exitosas,
disminuir-solicitudes y manejar-cambio-contrato respectivamente.

5.7.3 Administrador de Estrategias de Adaptacin.


Este administrador gestiona las estrategias de adaptacin de la plataforma implementada, las cuales
permiten hacer frente a los distintos requerimientos de adaptacin. Las condiciones que determinan si
una estrategia es aplicable a un determinado requerimiento de adaptacin, se definen en el archivo de
configuracin jboss-adaptative-strategies.xml. A modo de ejemplo, la Figura 56 presenta una
especificacin de la estrategia que utiliza informacin 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 informacin almacenada.

- 86 -

Cada nueva estrategia que se desarrolle en la plataforma debe implementar la interfaz IAdpStrategy, la
cual define un nico mtodo (getAdpTree), que es utilizado por el Motor de Adaptacin y Monitoreo
para generar la directiva de adaptacin correspondiente a un determinado servicio. Consecuentemente,
esta interfaz permite que el Motor de Adaptacin 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 Administracin


El objetivo de esta seccin es presentar las funcionalidades con las que cuenta la Consola de
Administracin, la cual est orientada a facilitar la administracin, configuracin y el monitoreo de la
Plataforma ESB Adaptativa.

5.8.1 Servicios Virtuales


Estas funcionalidades permiten realizar la gestin de los servicios virtuales registrados en la plataforma,
permitiendo de forma grfica 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 cannico. 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
adaptacin vigente, y el historial de las distintas adaptaciones aplicadas sobre un determinado servicio.
A continuacin se detallan las funcionalidades de la consola referentes a los servicios virtuales.

alta, baja, modificacin y visualizacin de los servicios virtuales registrados en la plataforma.

- 87 -

alta y baja de transformaciones desde y hacia el modelo de datos cannico.

configuracin de la metadata de cada servicio virtual.

visualizacin de la directiva de adaptacin para cada uno de los servicios registrados.

visualizacin del histrico de flujos de adaptacin procesados para cada servicio.

La Figura 58 presenta cmo se visualizan los servicios virtuales registrados en la plataforma, detallando
en cada uno de ellos su identificador, nombre, categora, etc.

Figura 58 - Registro de Servicios Virtuales.

5.8.2 Configuracin del ESB Adaptativo y del Motor de Adaptacin y Monitoreo


En este grupo, se ubican aquellas funcionalidades que permiten visualizar el contenido de los diferentes
archivos de configuracin del ESB Adaptativo y del Motor de Adaptacin y Monitoreo, as como tambin
la funcionalidad que posibilita recargarlos.
Todos los archivos de configuracin descriptos en la Seccin 4.5.2.1, cuentan con una vista asociada en
la Consola de Administracin. A modo de ejemplo, la Figura 59 presenta la configuracin de los
Requerimientos de Servicios de la plataforma.

- 88 -

Figura 59 - Requerimientos de Servicios.

5.9 Componentes ESB Reutilizables


En esta seccin 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 genrica.
En la Seccin 5.9.1 se detalla la implementacin y reutilizacin del Ruteo Basado en Itinerario mientras
que en la Seccin 5.9.2 se presenta el mecanismo de adaptacin que utiliza informacin almacenada
(Cache).

5.9.1 Ruteo Basado en Itinerario


El ruteo basado en itinerario, determina en tiempo de ejecucin 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 implementacin concreta de cada uno de los mecanismos de
adaptacin. Cada mecanismo de la plataforma debe implementar dicha interfaz, la cual define tres
mtodos: obtener el nombre del servicio, obtener la categora del servicio y una representacin de sus
propiedades en formato plano. A su vez, cada una de estas implementaciones posee caractersticas y/o
propiedades adicionales, que dependen en gran medida de cada mecanismo de adaptacin. Por
ejemplo, el mecanismo de retardo, posee un atributo que especifica el tiempo de postergacin 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.

- 89 -

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 Adaptacin.
Cuando un nuevo mensaje llega al Gateway de Adaptacin, 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 prximo servicio del flujo, o directamente retornar una
respuesta en caso de ser el ltimo nodo. La plataforma implementa la accin ItineraryAction que abstrae
este proceso, redirigiendo un mensaje hacia el siguiente Servicio ESB definido en su flujo.
La implementacin 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 implementacin de la Interfaz AdpFlowInterface. Cabe recordar que los servicios involucrados en el
itinerario de un mensaje, deben contener la accin ItineraryAction como la ltima accin 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 informacin 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 adaptacin solo es aplicable sobre servicios de datos. Si un servicio
efecta una operacin de negocio que altere alguna informacin (por ejemplo, efectuar un pago), es
necesario invocarlo directamente y no es factible la utilizacin de este mecanismo.
La implementacin de este componente fue desarrollada utilizando la librera EHCache18, que permite
configurar el tamao del mximo de cache (en disco y memoria), el tiempo de vida, el tiempo de
18

http://ehcache.org/

- 90 -

inactividad y otras propiedades. Adicionalmente, el Cache implementado cuenta con mecanismos para
obtener informacin estadstica en tiempo de ejecucin, como por ejemplo, el tamao 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 configuracin, y adems consultarlos en tiempo de ejecucin utilizando el
protocolo JMX.
La implementacin de este Cache tiene en consideracin el requerimiento de disminucin 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 bsquedas de la informacin 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 configuracin por servicio de los tiempos de vida, el tamao 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 fcilmente 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
20

http://www.ietf.org/rfc/rfc1321.txt
http://mvnrepository.com/artifact/net.sf.ehcache/ehcache/2.6.0

- 91 -

5.10 Problemas Encontrados


En esta seccin se detallan las diferentes problemticas presentadas en la etapa de implementacin de
la Plataforma ESB Adaptativa, donde se menciona cul 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
informacin disponible en la plataforma, ya que no se cuenta con ninguna relacin entre las acciones de
los servicios equivalentes. Para mitigar este problema se decidi reemplazar el atributo soapaction de la
peticin HTTP por la accin vaca, obligando de esta forma a que el servicio obtenga la accin a invocar
desde el Body del propio mensaje SOAP. Otro enfoque que se puede tomar para solucionar esta
problemtica, es que la plataforma se encargue de almacenar informacin extra de sus servicios
virtuales equivalentes, permitiendo relacionar as las acciones equivalentes entre ellos.

5.10.2 Service Invoker sincrnico


La invocacin a servicios virtuales de forma sincrnica fue otro de los problemas enfrentados durante la
implementacin 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 invocacin a estos servicios
se presentaba al realizar invocaciones sincrnicas, donde el control de la ejecucin no era retornado
correctamente, no pudindose as almacenar su respuesta. Para resolver este inconveniente se debi
recurrir al cdigo fuente de la accin SynServiceInvoker de JBoss ESB, investigando cmo 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 invocacin, permitiendo as transferir temporalmente el control de la ejecucin desde el
servicio que realiza la invocacin al que se desea invocar, y cuando ste ltimo finalice su ejecucin,
retorne el control al servicio que realiz la invocacin.

5.10.3 Incremento de los hilos de ejecucin


Otro de los problemas enfrentados en la implementacin de la plataforma se debi a una mala
utilizacin de los conectores JMX, ya que por cada invocacin que se realiza utilizando este protocolo, se
crea un nuevo hilo de ejecucin 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 conexin
establecida.
El problema enfrentado en el marco de este proyecto, se daba despus 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 posea activos y que ya no se utilizaban. Estos hilos consuman
recursos innecesarios, ya que nunca eran liberados e impedan la creacin de nuevos hilos, debido a que
se alcanzaba la mxima cantidad de hilos activos. Analizando el problema con herramientas como

- 92 -

VisualVM, se observ que el mismo era causado por no cerrar las conexiones establecidas a travs de las
comunicaciones JMX.

5.10.4 Problemas de performance con el servicio DeadLetter de JBoss ESB


La utilizacin del servicio DeadLetterService en el mecanismo de adaptacin Unificador de Respuestas,
provoc grandes problemas de performance, ya que por cada invocacin 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 tamao cercano a
los 300MB su performance se ve degradada, ya que es una base diseada para ambientes de desarrollo
y no para almacenar grades volmenes de datos. Por esta razn, se decidi que el Unificador de
Respuestas descarte los mensajes que no son entregados, en vez de enviarlos al DeadLetterService, pues
en un corto perodo de tiempo la estrategia Distribuir Solicitud a Servicios Equivalentes genera una gran
cantidad de mensajes descartados.

5.10.5 Comparador de documentos WSDL


La implementacin del comparador de documentos WSDL debi afrontar la problemtica del tipo de
style que se utiliza en el SOAPBinding de la publicacin 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 publicacin. 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 versin 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 parmetro es opcional y cuando deja de serlo. Para esto se puede inspeccionar el documento
WSDL y obtener para cada parmetro su valor mnimo de ocurrencia (min-occur), o utilizar algn tipo de
documentacin adicional que indique su opcionalidad.

21

http://hsqldb.org/

- 93 -

- 94 -

6 Caso de Estudio y Pruebas Realizadas


En este captulo se presenta un caso de estudio basado en el contexto de Gobierno Electrnico, 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 adems, evaluar el overhead generado por las acciones de adaptacin de la
plataforma. En la Seccin 6.1 se describe un contexto reducido de Gobierno Electrnico, en la Seccin
6.2 se presentan las pruebas a las que fue sometida la implementacin de la plataforma, y finalmente,
en la Seccin 6.3 se presentan las conclusiones del captulo.

6.1 Caso de Estudio: Gobierno Electrnico


En esta seccin se presenta el caso de estudio de Gobierno Electrnico que proporciona un marco
conceptual para ejemplificar las distintas estrategias de adaptacin presentadas en la Seccin 2.5.4.
Hoy en da, muchas instituciones del gobierno deben solicitar a los ciudadanos informacin que otras
instituciones del Estado ya poseen, agregando procesos y tiempos innecesarios, adems, dentro del
propio Estado, muchas veces es necesario contar con informacin de diferentes organismos para tomar
algn tipo de decisin. Con el fin de evitar estos inconvenientes, muchos pases han utilizado tecnologas
de la informacin para avanzar en el desarrollo de lo que se denomina Gobierno Electrnico.
El desarrollo del Gobierno Electrnico 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 evolucin tecnolgica 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 tambin la reutilizacin y aprovechamiento de los recursos con los que cuenta el
Estado. [24]
En nuestro pas, la Plataforma de Gobierno Electrnico (PGE) que ha implementado la Agencia para el
Desarrollo del Gobierno de Gestin Electrnica y la Sociedad de la Informacin y del Conocimiento
(AGESIC), permite y facilita la integracin de los servicios ofrecidos por los organismos, proporcionando
el contexto tecnolgico y legal que la regula. Para esto, la PGE brinda mecanismos que apuntan a
simplificar la integracin entre los organismos del Estado y a mejorar la utilizacin de sus recursos. En
particular, estos mecanismos proveen la infraestructura base que permiten la implementacin de una
SOA a nivel del Estado, la cual se apoya en la tecnologa de Web Services. Los organismos proveen
entonces sus funcionalidades de negocio a travs de servicios que son descriptos, publicados,
descubiertos, invocados y combinados de forma independiente a la plataforma tecnolgica en la que
fueron implementados. [24]

- 95 -

La Figura 62 permite visualizar las caractersticas generales de la Plataforma de Gobierno Electrnico.

Figura 62 - Plataforma de Gobierno Electrnico. Extrada de [1].

La PGE se aplica sobre un contexto caracterizado por una alta distribucin y heterogeneidad entre los
organismos, la distribucin est dada por la interaccin de muchas entidades y la heterogeneidad se da
tanto a nivel tecnolgico como de recursos.
La plataforma se basa en una arquitectura SOA, la cual cuenta con un sistema de control de acceso, un
sistema de gestin de metadatos y una plataforma de middleware. Estos componentes facilitan la
provisin, bsqueda e invocacin de los Web Services que son brindados por los organismos, as como la
interoperabilidad e interaccin segura entre los mismos. Los organismos pueden utilizar esta plataforma
tanto para publicar y descubrir servicios, como para utilizar las diferentes capacidades de mediacin que
permiten desacoplar clientes y servicios [24]. Consecuentemente, la PGE resulta un marco adecuado
para realizar acciones de adaptacin.
El componente de middleware de la PGE cuenta con mecanismos para facilitar el desarrollo, despliegue
e integracin de servicios y aplicaciones. Adems, est integrado con tecnologa ESB, por lo que resulta
un escenario interesante para ejemplificar las estrategias de adaptacin descriptas en la Seccin 2.5.4.

6.1.1 Entidades y Modelo de Datos Cannico


En el marco de este proyecto, se modelan los principales conceptos presentes en el contexto de
Gobierno Electrnico, donde se destaca la gran cantidad de informacin que deben administrar los
distintos organismos, tanto de empresas como de ciudadanos. Por esta razn, y con el fin de realizar

- 96 -

pruebas que permitan verificar el correcto desempeo de las estrategias de adaptacin, se resolvi
modelar un conjunto reducido de entidades. Estas entidades son: Empresa y Persona.
La Tabla 19 presenta el modelo de datos cannico definido para las empresas y personas de la realidad
modelada, detallando cada uno de sus atributos y sus posibles valores.
Persona
Primer Nombre
Segundo Nombre
Apellido Paterno
Apellido Materno
Firma
Sexo
C.I

Valores Posibles

Empresa

(.*)
(.*)
(.*)
(.*)
(.*)
(M|F)
(\d.\d\d\d.\d\d\d-\d)

RUT
Ciudad
Departamento
Direccin
Cant. Empleados
DGI al da
BPS al da

Valores Posibles
(\d{13})
(.*)
(.*)
(.*)
(\d*)
(S|N)
(S|N)

Tabla 19 - Modelo de datos cannico

Definir este modelo de datos cannico en la plataforma permite por ejemplo, especificar una
representacin comn 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 cannico entre los distintos
organismos. Las funcionalidades seleccionadas son:

Registro de Empresa: esta funcionalidad permite emular el registro de una nueva empresa dada
su informacin correspondiente.

Obtener Informacin de Empresa: esta funcionalidad permite obtener la informacin referente


a una empresa dado el RUT correspondiente.

Obtener Informacin de Persona: esta funcionalidad permite obtener la informacin referente


a un ciudadano a partir de su cdula 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
informacin 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 dems servicios, pero esta
relacin no se cumple a la inversa, ya que el servicio DNICWS no posee las funcionalidades de Registro
de Empresa ni Obtener Informacin de Empresa. La Figura 62 presenta la relacin de equivalencia
mencionada anteriormente.

- 97 -

Figura 63 - Relacin de equivalencia entre los servicios del caso de estudio

Cabe destacar, que al igual que el modelo de datos cannico se defini un modelo cannico 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 cannico de servicios considerado, detallando los nombres de las operaciones, sus parmetros y
el formato de los mismos.
Operacin

Parmetros

Formato

registrarNuevaEmpresa
obtenerInfoEmpresa
obtenerPersona

Entidad Empresa
RUT
C.I

Cannico
(\d{13})
(\d.\d\d\d.\d\d\d-\d)

Tabla 20 - Modelo cannico de servicios

6.1.3 Escenario de prueba


En esta seccin se presenta el contexto reducido de la PGE, el cual permite evaluar las estrategias de
adaptacin propuestas.
A continuacin se listan los organismos que componen el contexto simplificado:

BPS - Banco de Previsin Social


DGI - Direccin General Impositiva
DNIC - Direccin Nacional de Identificacin Civil

Estos organismos administran informacin referente a empresas y personas, pero no todos representan
de la misma forma los datos de dichas entidades, por lo que no existe una representacin nica ni de
empresas, ni de personas. Debido a esto, es necesario considerar un modelo de datos cannico, que
permita describir la informacin de empresas y personas, independientemente de las distintas
representaciones particulares de cada organismo.
A continuacin, 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. Adems, se observa el modelo de datos cannicos considerado, a travs de
la utilizacin 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
cannico y viceversa.

- 98 -

Figura 64 - Escenario de prueba.

6.1.4 Invocacin a Servicio Equivalente


Una de las estrategias de adaptacin que se aplican en el caso de estudio es Invocacin a Servicio
Equivalente. En esta seccin se describe lo que implicara esta estrategia en este contexto.
Supongamos que una aplicacin cliente desea invocar la funcionalidad obtenerPersona del organismo
BPS a travs de la plataforma, y en sta existe una directiva de adaptacin vigente que invoca al servicio
equivalente DNICWS. En una primera instancia, la plataforma debe transformar la representacin de la
solicitud original hacia el modelo cannico, en donde se transforman los parmetros correspondientes a
la cdula de identidad del modelo particular de BPS hacia el modelo cannico. Una vez que la solicitud
est representada en el modelo cannico de entidades, es necesario realizar una transformacin hacia al
modelo particular del organismo DNIC. En este ltimo caso, la trasformacin desde el modelo cannico
hacia el modelo particular de DNIC debe por un lado, trasformar los parmetros que representan la
cdula de identidad, modificndolos al formato particular definido por DNIC, y por el otro, renombrar la
operacin del modelo cannico hacia su correspondiente operacin en el modelo particular. De forma
anloga, se debe transformar la representacin de la respuesta del servicio DNIC hacia el modelo
particular de BPS, primero transformndola al modelo cannico, para luego llevarla al modelo particular
de BPS.
A continuacin, 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 estndar de transformar
documentos en formato XML.
Inicialmente, en el paso 1 se muestra el mensaje original con el cual se realiza la peticin desde la
aplicacin cliente hacia la Plataforma ESB Adaptativa. A continuacin, se modifican los parmetros del
mensaje original para transformarlos a la representacin de la funcionalidad obtener informacin de
persona del servicio cannico, tal como se observa en el paso 2 de la Figura 65. Luego, se transforma el
mensaje desde el modelo cannico hacia el modelo particular de DNIC, paso 2 a 3, donde se modifica el
nombre de la operacin y el formato de sus parmetros. En este momento, el mensaje est preparado

- 99 -

para realizar una invocacin a la funcionalidad obtener informacin persona, brindada por un servicio
virtual que accede a los servicios del organismo DNIC.

Figura 65 - Transformacin 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
peticin original realizada por la aplicacin cliente fue sobre dicho servicio, esperando recibir la
respuesta en la representacin particular de BPS. Estas transformaciones se realizan de manera anloga
a las descriptas para invocar un servicio virtual equivalente: primero se transforma la respuesta desde el
modelo particular de DNIC hacia el modelo cannico, luego se la transforma al modelo particular de BPS.

6.2 Pruebas Realizadas


En esta seccin, se describen las pruebas a las que fue sometida la Plataforma ESB Adaptativa,
detallando en cada una de ellas los resultados obtenidos. Dichas pruebas estn enfocadas en validar la
mejora de los atributos de calidad tenidos en cuenta en la solucin planteada, mediante el uso de flujos
de adaptacin, as como tambin evaluar el overhead generado por la plataforma en el procesamiento
de cada peticin.
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.

- 100 -

Para la simulacin 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 ncleo 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 mquina virtual (Virtual Box v4.1.16) que prioriza los procesos Java que son
ejecutados en dicha mquina.

6.2.1 Prueba sobre atributos de calidad


Esta prueba, consiste en verificar que la implementacin de la plataforma mejora los atributos de
calidad de los servicios virtuales, en un contexto simplificado de Gobierno Electrnico. El servicio
utilizado para estas pruebas es aquel que representa el organismo DNIC, definido en la Seccin 6.1.1, el
cual cuenta con una sola operacin y dos servicios equivalentes, BPSWS y DGIWS. En esta prueba se
registran los tiempos de respuesta y el porcentaje de respuestas exitosas para cada invocacin realizada
sobre dicho servicio, con el fin de cuantificar los resultados obtenidos y evaluar los atributos de calidad
mencionados en la Seccin 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:

22
23

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 mximo 1500 peticiones por minuto, sobrepasando este
lmite, 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 mximo: 250ms.
Porcentaje de tolerancia a invocaciones no exitosas : 0%
Tiempo de espera para la estrategia de retardo: 100ms.
Cantidad mxima de invocaciones que puede procesar el servicio: 800/min.

El tiempo de vida de las estrategias generadas por la plataforma es de 200s.

http://www.soapui.org/
http://visualvm.java.net/

- 101 -

La Figura 66 presenta de forma grfica la configuracin antes mencionada.

Figura 66 - Configuracin 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 adaptacin 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 mtodo obtenerInformacionPersona del servicio DNICWS, para el cual
aproximadamente un 10% de sus solicitudes son idnticas, 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 invocacin directa sobre dichos servicios, y otra a travs de la Plataforma ESB
Adaptativa, esta ltima con todas sus funcionalidades activas (Mecanismos de Monitoreo, Estrategias de
Adaptacin, etc.).
En la Tabla 21 se muestran los resultados obtenidos de las invocaciones al servicio DNIC, utilizando un
pool mximo de 60 hilos de ejecucin durante un perodo de 15 min, es decir que en dicho perodo se
obtienen como mximo 60 invocaciones concurrentes al servicio.
Tipo de Invocacin

Cant. invocaciones
procesadas

Tiempo respuesta
promedio (ms)

Errores

Invocaciones
exitosas

Invocacin directa

30569

1013

10351

67%

Invocacin a travs 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 tambin la disminucin de los tiempos de respuesta promedio,
mejorando as la degradacin de calidad del servicio. Adicionalmente, se observa un gran incremento de
las peticiones procesadas, esto se debe a que al invocar a travs la plataforma se utilizan los

- 102 -

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 adems, el gran beneficio de la utilizacin 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 saturacin de dicho servicio.
Servicio

Cantidad total de pedidos

Porcentaje del total

BPSWS
DGIWS
DNICWS
Cache

4777
20701
6370
4532

13%
57%
18%
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 travs de la plataforma, como si el mismo no hubiera sufrido ningn 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 invocacin.
Se debe tener en cuenta que en esta prueba, no se puede realizar una comparativa entre la invocacin
directa al servicio virtual y la invocacin a travs de la plataforma, ya que la invocacin directa retorna
una excepcin en la mayora 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
Agregar Operacin
Agregar Parmetro
Renombrar operacin
Renombrar Parmetro
Eliminar Parmetro

Descripcin

Detectado

Invocacin

Si

Exitosa

Si

Exitosa

Si

Exitosa

Si

Exitosa

Si

Exitosa

Se agrega la operacin nuevaOper.


Se agrega el parmetro nuevoParam al mtodo
obtenerInfoEmpresa.
Se renombra el nombre de la operacin registroEmpresa a
registroEmpresaNueva.
Se renombra el nombre del parmetro miles a mil del
mtodo obtenerPersona.
Se elimina el parmetro digitoVerificacion del mtodo
obtenerPersona.

Tabla 23 - Resultados obtenidos para los cambios de contrato

- 103 -

Segn 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 comparacin 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 invocacin directa al
servicio virtual. A continuacin, la Tabla 24 presenta los valores obtenidos en la prueba realizada.
Estrategias

Max (ms)

Min (ms)

Promedio (ms)

OverHead (ms)

Invocacin Directa

110

18

No posee

Sin estrategia

124

21

Cache

10

No posee

Retardo (100ms)

349

106

121

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 mayora de los casos inferiores a 200ms. Para la estrategia de
invocacin a una lista de servicios equivalentes, el procesamiento de las transformaciones desde y hacia
el modelo de datos cannicos genera un aumento considerable en el tiempo de procesamiento, adems
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 implementacin 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 utilizacin de
recursos por parte de la Plataforma ESB Adaptativa, permitiendo evaluar el desempeo de la misma
cuando es sometida a una carga de procesamiento considerable. En este monitoreo, se evala el uso de
recursos como la memoria, los hilos de ejecucin y la utilizacin de la CPU, para cada una de las
estrategias implementadas.
En la Figura 67 se presenta un esbozo grfico de la utilizacin 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 invocacin a servicios equivalentes, adems de la invocacin

- 104 -

sincrnica 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 invocacin a lista de destinatarios, en la cual se puede observar
un incremento considerable del uso de la CPU, debido a la gran utilizacin 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 grfico de la utilizacin de memoria por intervalo de tiempo, detallando al igual
que en la Figura 67, aquellos intervalos relevantes. Cabe resaltar, que la utilizacin 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 grfico presentado. Los picos ms altos de consumo de memoria se producen con la
estrategia de invocacin 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 adaptacin 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 computacin.

- 105 -

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 invocacin 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 perodo de tiempo.

Figura 69 - Consumo de hilos de ejecucin.

6.3 Conclusiones
En ese captulo se present el contexto reducido de Gobierno Electrnico en el cual fueron detalladas
las pruebas realizadas sobre la Plataforma ESB Adaptativa. Dichas pruebas demuestran que la
plataforma con esta implementacin 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 informacin almacenada, se obtienen
mejores tiempos de respuesta, porcentaje de repuestas exitosas y cantidad de invocaciones procesadas

- 106 -

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 das en actualizar
sus contratos, lo que deja inaccesible al servicio durante un gran perodo 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 ms acorde a la situacin y una implementacin
ms 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 implementacin 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 desempeo de la plataforma en cualquier contexto.

- 107 -

- 108 -

7 Conclusiones del Trabajo


En este captulo se presentan las conclusiones del trabajo realizado. En la Seccin 7.1 se presenta un
resumen del trabajo y sus principales contribuciones, y en la Seccin 7.2 se comentan posibles trabajos a
futuro.

7.1 Resumen y Contribuciones


Este proyecto consisti en la implementacin de una plataforma adaptativa, tomando como base un
producto ESB existente, extendiendo sus funcionalidades para aplicar acciones de adaptacin en
sistemas orientados a servicios. Adems, se desarrollaron pruebas sobre un contexto reducido de
Gobierno Electrnico, 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
adaptacin.
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 anlisis permiti seleccionar a JBoss ESB como el producto base para la implementacin
de la plataforma, debido a su buena documentacin y a su amplio conjunto de capacidades de
mediacin. El anlisis permiti comprobar adems que los ESB analizados presentan gran nivel
funcional, pero no poseen un nivel de documentacin acorde a sus capacidades de mediacin.
Luego, tomando como base el producto JBoss ESB se implement una plataforma que permite abordar
necesidades de adaptacin que surgen por la degradacin de la calidad de servicio, la saturacin de
servicios y cambios en los contratos de servicios. Adicionalmente a los objetivos planteados, se
implement un Motor de Administracin y Monitoreo funcional, que es capaz de tomar decisiones
esenciales de adaptacin y de monitoreo, determinando los pilares para un desarrollo futuro de un
motor ms complejo. Dada la necesidad de facilitar la administracin y configuracin de la Plataforma
ESB Adaptativa, se implement una consola de administracin que permite de forma grfica, configurar,
administrar y monitorear los distintos aspectos de la plataforma. Por ltimo, se quiere resaltar que la
implementacin de la plataforma fue realizada desde un principio teniendo en cuenta un alto nivel de
extensibilidad, lo que permite incorporar fcilmente nuevas funcionalidades.
Finalmente, para validar el funcionamiento de la plataforma se dise un escenario de prueba basado
en el contexto de Gobierno Electrnico. Si bien las pruebas realizadas fueron acotadas y no
representaron un escenario de produccin real, demostraron que la plataforma con la implementacin
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 relacin a las mejoras que se generan.
Adems, se concluye que las estrategias implementadas permiten abordar eficazmente las necesidades
de adaptacin consideradas en el diseo de la plataforma.

- 109 -

Como conclusin general, el trabajo realizado demuestra que la implementacin 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
mediacin brindadas por JBoss ESB.
Como principales contribuciones del proyecto se destacan:

Implementacin de una plataforma adaptativa que permite realizar adaptaciones de forma


dinmica, automtica y en tiempo de ejecucin, basndose en la propuesta Plataforma ESB
Adaptativa para Sistemas Basados en Servicios.

Implementacin de mecanismos de adaptacin y de monitoreo concretos, que permiten


abordar necesidades de adaptacin que surgen por la degradacin en la calidad de los servicios,
la saturacin y los cambios en los contratos de los servicios.

Diseo e implementacin de componentes para la plataforma JBoss ESB, que pueden ser
reutilizados en otros proyectos de igual dominio. En particular, se implementaron los
mecanismos de adaptacin Ruteo Basado en Itinerario y Cache.

Desarrollo de las principales funcionalidades de los distintos componentes del Motor de


Adaptacin y Monitoreo, que implementan decisiones esenciales de adaptacin segn los
distintos datos monitoreados. La implementacin de este motor est totalmente desacoplada
de los dems componentes que conforman la plataforma.

7.2 Trabajo a Futuro


Durante el transcurso de este proyecto se identificaron funcionalidades y aspectos de la solucin que
podran ser mejorados, pero debido a los tiempos acotados para este trabajo estas ideas no fueron
desarrolladas, por lo que se presentan como lneas de trabajo a futuro.

7.2.1 Extender las comunicaciones JMX


Actualmente, la comunicacin entre los principales componentes de la plataforma se realiza utilizando
el protocolo de mensajera JMX, lo que implica que todos los componentes de la plataforma deban estar
implementados en Java. Se propone como lnea de trabajo a futuro, extender dichas comunicaciones a
un nivel ms distribuido, utilizando HTTP o Web Services. Esto permitira, por ejemplo, tener el ESB
Adaptativo, el Motor de Adaptacin y Monitoreo y la Consola de Administracin implementados en
distintas plataformas, y adems, poder acceder a ellos remotamente a travs de internet.
Para implementar esta extensin, se podra por ejemplo, utilizar el protocolo WS-Management25, o
algn conector SOAP para JMX como MX4J26. [26]
25
26

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

- 110 -

7.2.2 Directivas Administradas por el usuario


En la solucin desarrollada, el usuario puede consultar la directiva de adaptacin que se aplica a un
determinado servicio, pero no pude modificarla. Se plantea como una lnea de trabajo a futuro la
posibilidad de extender la plataforma, implementando las funcionalidades requeridas para que el
usuario final pueda alterar las directivas de adaptacin de un servicio, permitiendo tanto cancelar, crear
y modificar directivas, como alterar sus tiempos de vida.

7.2.3 Estadsticas de las directivas procesadas


Las estadsticas de los servicios virtuales son datos relevantes para ajustar la configuracin de la
plataforma y analizar su correcto funcionamiento, tambin pueden servir como entrada para el Motor
de Adaptacin y Monitoreo, colaborando en la eleccin de una directiva de adaptacin ms eficiente
para un determinado servicio.
En la plataforma implementada se almacena un registro histrico de las directivas de adaptacin de
cada servicio virtual. Se podra agrupar dicho histrico con la informacin de las propiedades
monitoreadas, la metadata de los servicios y sus tiempos de respuesta, y mostrar grficamente toda
esta informacin en la Consola de Administracin, permitiendo as visualizar el funcionamiento de la
plataforma. Adems, toda la informacin podra ser utilizada para mejorar las decisiones de adaptacin
que realiza el Motor de Administracin y Monitoreo.

7.2.4 Manejar el vencimiento de las Directivas de Adaptacin


La plataforma adaptativa solo mantiene una directiva de adaptacin por servicio, lo que implica que
cuando una directiva expira, existe un tiempo donde un servicio puede requerir una nueva adaptacin
que la plataforma an no detect.
Las pruebas realizadas detectaron que estos casos degradan rpidamente los atributos de calidad de la
plataforma, por lo que sera interesante incorporar alguna nueva funcionalidad que permita manejar el
vencimiento de las directivas de adaptacin. La mejora planteada puede ser implementada en el Motor
de Adaptacin y Monitoreo, quien debera forzar que una directiva de adaptacin sea sustituida antes
de su vencimiento. Otra opcin es extender el ESB Adaptativo para que soporte ms de una directiva de
adaptacin por servicio.

7.2.5 Motor de adaptacin Multi-ESB-Adaptativo


Como se menciona en la Seccin 4.3.9, el Motor de Adaptacin y Monitoreo tiene la responsabilidad de
implementar la lgica que permite tomar decisiones respecto a la estrategias que se aplican sobre los
servicios virtuales. Dicha lgica puede ser reutilizada si el Motor de Adaptacin y Monitoreo es
extendido para trabajar con varios ESB Adaptativos.
Se plantea la posibilidad de extender la implementacin actual de la plataforma, permitiendo registrar
varios ESB Adaptativos y brindar mecanismos que permitan conocer sus servicios de adaptacin.

- 111 -

7.2.6 Mejorar la seleccin de la directiva de Adaptacin


Para aquellos casos en los que un servicio posee varios requerimientos no satisfechos, o existen varias
estrategias de adaptacin para un mismo requerimiento, la implementacin actual del Motor de
Adaptacin y Monitoreo selecciona de forma aleatoria una de las distintas estrategias que se pueden
utilizar.
La implementacin de un motor de decisin basado en heursticas y/o conocimientos histricos,
permitira generar directivas de adaptacin ms eficaces, dado que las decisiones tomadas de esta
forma contemplaran tanto las directivas generadas para un servicio especfico, como las generadas para
el resto de los servicios registrados en la plataforma.

7.2.7 Mecanismos de alerta


Actualmente la plataforma cuenta con informacin que posibilita una implementacin de mensajes de
alerta. Se podra implementar por ejemplo, alertas que notifiquen la presencia de patrones de
degradacin de los servicios, permitiendo detectar problemas antes que sea necesario realizar acciones
de adaptacin. Adems, las alertas podran ser detectadas y enviadas de forma automtica a los
administradores de los servicios.

7.2.8 Metadata de los servicios definida en intervalos de tiempo


En la implementacin actual de la plataforma se supone que los servicios registrados mantienen sus
requerimientos incambiados durante un perodo de tiempo prolongado.
Dada la realidad actual de los planes elsticos de Cloud Computing, como lo es el servicio Amazon Elastic
Compute Cloud27, los requerimientos de cada servicio podran llegar a variar considerablemente segn
las horas o los das. Se propone como lnea de trabajo a futuro, el diseo y la implementacin de
mecanismos que permitan definir metadata para intervalos de meses, das u horas, y de esta manera
lograr que la plataforma adaptativa detecte de forma ms eficaz los requerimientos de cada servicio.

7.2.9 Mecanismos de monitoreo con tiempos independientes


Como se plantea en la Seccin 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 clculo de propiedades, se deben tener en cuenta
aspectos que actualmente la plataforma no contempla. Se deberan incorporar funcionalidades que
permitan que el ESB-Adaptativo y el Motor de Adaptacin y Monitoreo manejen conjuntos parciales de
las propiedades monitoreadas, lo que implicara un gran cambio sobre la plataforma implementada,
siendo una lnea de trabajo a futuro muy interesante.

27

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

- 112 -

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 relacin de equivalencia entre cada una
sus operaciones. Se propone como lnea de trabajo a futuro, mejorar la definicin de equivalencia para
poder soportar equivalencia a nivel de operaciones, lo que implicara definir para cada operacin de un
servicio, otra operacin que pueda ser invocada de manera equivalente. De esta forma se lograra tener
un conjunto mayor de operaciones equivalentes, que permitiran 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 lnea de trabajo a futuro extender la implementacin actual de
este comparador, con el propsito de soportar aquellos casos que no son contemplados actualmente,
como por ejemplo, el reordenamiento de los parmetros de una operacin y el cambio en la
opcionalidad de un parmetro.

- 113 -

- 114 -

8 Referencias
[1] Gonzlez, Ing. Laura, Plataforma ESB Adaptativa para Sistemas Basados en Servicios,
Montevideo, Agosto, 2011.
[2] accenture, Arquitectura Orientada a Servicios (SOA), [En lnea].
http://www.accenture.com/SiteCollectionDocuments/Local_Spain/PDF/SOA.pdf.

Available:

[3] Martin Daro Amagro, Jess Enrique Londoo, Julan Andrs Zapata, Service oriented architecture
in the enterprise architecture field, Revista de Avances en Sistemas e Informtico, 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 lnea]. 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 lnea].
Available: http://www.w3.org/TR/wsdl20-soap11-binding/. [ltimo acceso: Mayo 2012].
[8] W3C, SOAP Specifications, [En lnea]. Available: http://www.w3.org/TR/soap/. [ltimo acceso:
Mayo 2012].
[9] OASIS, UDDI Version 3.0.2, [En lnea]. 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 lnea]. 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
lnea].
http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/wsenterpriseconnectivitypatterns/Enterprise-Connectivity-Patterns-pdf.pdf.
[ltimo
Noviembre 2012].

Available:
acceso:

[14] IBM, Cache mediation pattern specification: an overview, [En lnea]. Available:
http://www.ibm.com/developerworks/webservices/library/ws-soa-cachemed/. [ltimo acceso:
Junio 2012].
[15] DZone, Java Management Extensions, [En lnea]. Available: http://java.dzone.com/articles/javamanagement-extensions.
[16] The
YAWL
Foundation,
YAWL
Manuals,
[En
lnea].
Available:
http://www.yawlfoundation.org/pages/support/manuals.html. [ltimo acceso: Junio 2012].

- 115 -

[17] CENATIC,
ASPECTOS
TECNOLGICOS,
[En
lnea].
Available:
http://www.cenatic.es/laecsp/page21/page22/page22.html. [ltimo acceso: Junio 2012].
[18] 11
Of
Best
Opensource
ESB
Tools,
[En
lnea].
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
lnea].
http://architects.dzone.com/news/top-open-source-esbs. [ltimo acceso: Junio 2012].

Available:

[20] O.
Alliance,
The
OSGi
Architecture,
[En
lnea].
http://www.osgi.org/Technology/WhatIsOSGi. [ltimo acceso: Septiembre 2012].

Available:

[21] Community,
JBoss,
Programmers
Guide,
[En
lnea].
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 lnea]. Available: http://www.membranesoa.org/soa-model-doc/1.2/compare-wsdl-java-api.htm. [ltimo acceso: Noviembre 2012].
[23] OW2 Consortium, EasyWSDL Toolbox, [En lnea]. Available: http://easywsdl.ow2.org/index.html.
[ltimo acceso: Junio 2012].
[24] AGESIC,
Plataforma
de
EGob,
[En
lnea].
Available:
http://www.agesic.gub.uy/innovaportal/v/1710/1/agesic. [ltimo acceso: Octubre 2012].
[25] W3C,
The
Extensible
Stylesheet
Language
Family,
http://www.w3.org/Style/XSL/. [ltimo acceso: Octubre 2012].

[En

lnea].

Available:

[26] UserException, Monitorizando componentes usando JMX, [En lnea]. Available:


http://userexception.blogspot.com/2011/11/monitorizando-componentes-usando-jmx.html.
[ltimo acceso: Noviembre 2012].
[27] Apache, Apache Synapse, [En lnea]. Available: http://synapse.apache.org/. [ltimo acceso: Mayo
2012].
[28] http://servicemix.apache.org/, ServiceMix, [En lnea]. [ltimo acceso: Mayo 2012].
[29] ServiceMix,
ServiceMix,
[En
lnea].
http://docs.huihoo.com/apache/servicemix/home.html. [ltimo acceso: Mayo 2012].

Available:

[30] RedHat,
JBOSS
ENTERPRISE
SOA
PLATFORM,
[En
lnea].
Available:
http://www.latam.redhat.com/pdf/JBoss_Enterprise_SOA_Platform.pdf. [ltimo acceso: Mayo
2012].
[31] JBoss, JBoss ESB, [En lnea]. Available: http://www.jboss.org/jbossesb. [ltimo acceso: Mayo
2012].
[32] OpenESB Community, Open ESB, [En lnea]. Available: http://www.open-esb.net/. [ltimo
acceso: Junio 2012].
[33] OpenESB,
Open
ESB
Architecture,
[En
lnea].
Available:
http://wiki.openesb.java.net/Wiki.jsp?page=Glassfish9.1OpenESBArch. [ltimo acceso: Junio 2012].
[34] MuleSoft, What is Mule ESB?, [En lnea]. Available: http://www.mulesoft.org/what-mule-esb.

- 116 -

[ltimo acceso: Mayo 2012].


[35] W3C, W3C XML Schema, [En lnea]. Available: http://www.w3.org/XML/Schema. [ltimo acceso:
05 2012].
[36] AS3 Studio, Adaptaive SOA Approach, [En lnea]. Available: https://www.soa.edu.pl/AS3Studio/?q=ASOAapproach. [ltimo acceso: Agosto 2012].
[37] W3C,
Web
Services
Addressing
(WS-Addressing),
[En
lnea].
http://www.w3.org/Submission/ws-addressing/. [ltimo acceso: Octubre 2012].

- 117 -

Available:

- 118 -

Apndice 1.

Estrategias de Adaptacin

En este apndice se detallan todas las estrategias de adaptacin presentadas en la Seccin 2.5.4, las
cuales permiten abordar la degradacin en la calidad de los servicios, la saturacin 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 adaptacin. Concretamente, esta estrategia permite abordar las siguientes necesidades de
adaptacin:

Degradacin de la calidad: Considerando esta necesidad, se podra mejorar el tiempo de


respuesta de un servicio si se invoca un servicio equivalente con menor tiempo de respuesta.
Tambin se lograra 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 adaptacin que representa la estrategia Invocacin a Servicio


Equivalente. Dicho flujo est compuesto por servicios de adaptacin 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 - Implementacin de estrategia de invocacin 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 aplicacin cliente a partir de la primera respuesta obtenida. En
particular, esta estrategia permite abordar la siguiente necesidad de adaptacin:

Degradacin de la calidad: Con respecto a esta necesidad, al invocar a varios servicios


equivalentes se tiene ms 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

- 119 -

manera similar, hay ms posibilidades de obtener alguna respuesta exitosa si se enva la


solicitud a varios servicios equivalentes.
La Figura 71 despliega un flujo de adaptacin 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 - Implementacin 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 adaptacin, esta estrategia permite abordar la
siguiente necesidad:

Saturacin: Esta estrategia reduce claramente la cantidad de invocaciones que un servicio


procesa por perodo de tiempo, debido a la distribucin uniforme que la misma realiza.

La Figura 72 muestra un flujo de adaptacin que representa esta estrategia. Este flujo utiliza los
mecanismos de ruteo intermediario y transformaciones.

Figura 72 - Ejemplo de una implementacin de la estrategia que balancea la carga.

Utilizar Informacin Almacenada


Esta estrategia utiliza informacin almacenada en invocaciones previas de un servicio, generando una
respuesta sin la necesidad de invocar directamente al Servicio Virtual. Especficamente, esta estrategia
permite abordar las siguientes necesidades de adaptacin:

- 120 -

Degradacin de la calidad: Con respecto a esta necesidad, disponer de informacin


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.

Saturacin: Para abordar la saturacin 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 informacin previamente almacenada, sin la
necesidad de realizar la invocacin a un servicio que modific su contrato.

La Figura 73 presenta un flujo de adaptacin que constituye la estrategia Utilizar Informacin


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 informacin previamente almacenada.

Figura 73 - Implementacin de estrategia que utiliza informacin almacenada.

Diferir Pedidos
Esta estrategia recibe un mensaje y posterga su entrega por un determinado perodo de tiempo.
Concretamente, esta estrategia permite abordar la siguiente necesidad de adaptacin:

Saturacin: Esta estrategia permite reducir el nmero de solicitudes que recibe un servicio por
perodo de tiempo. La estrategia tiene como objetivo diferir pedidos para que el servicio no
procese ms solicitudes de las que puede soportar.

La Figura 74 muestra el flujo de adaptacin que representa a la estrategia encargada de diferir los
pedidos a un Servicio Virtual.

Figura 74 - Implementacin de la estrategia para diferir pedidos.

- 121 -

Modificar Solicitud y Respuesta


Esta estrategia tiene la capacidad de modificar tanto un mensaje de solicitud a un Servicio Virtual, as
como tambin su respuesta. Especficamente, esta estrategia aborda la siguiente necesidad de
adaptacin:

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 algn 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 - Implementacin de la estrategia para invocar servicios con cambios de contrato.

- 122 -

Apndice 2. Principales Caractersticas de los Productos ESB


Este apndice 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 ms adecuado a las
necesidades de este proyecto.

Apache Synapse ESB


Apache Synapse es un software libre y de cdigo 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 travs de diversos protocolos de la capa de
transporte. [27]
Caractersticas brindadas

Es un ESB que soporta la mayora de las funcionalidades de los modelos de ESB tericos.

Es sencillo de configurar y de utilizar, adems la calidad de su documentacin 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.

Tambin soporta transformacin de mensajes (XSLT, Scripting).

Dispone de ruteos dinmicos a travs de XPath o a travs de expresiones regulares, donde un


mensaje puede tener un destino diferente segn su estructura.

Posee un balanceador de carga, el cual es configurable segn 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 grfica
que brinda facilidades de monitoreo.

Permite implementar fcilmente un gateway de aplicacin a partir de uno de sus componentes


nativos.

- 123 -

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. Extrado de [27].

Service Mix ESB


Apache ServiceMix es un contenedor de integracin flexible y de cdigo abierto que unifica las
caractersticas y funcionalidades de Apache ActiveMQ, Camel, CXF, ODE y Karaf en una plataforma de
ejecucin 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]
Caractersticas brindadas

Es un ESB basado en la especificacin JBI.

Soporta mltiples protocolos de transporte como por ejemplo JMS, HTTP, FTP, Sistema de
ficheros, entre otros.

Dispone de una consola web para tareas de administracin, adems de un IDE grfico que
permite la generacin de Proyectos ESB.

Posee motor de orquestacin de servicios BPEL.

Permite transformacin de documentos XML a travs 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.

- 124 -

Posee motor de orquestacin de servicios BPEL.

La intercepcin 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. Extrada de [29].

JBoss ESB
JBoss Enterprise SOA Platform incluye middleware de cdigo 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]
Caractersticas

Soporta el estndar JBI.

Soporta mltiples protocolos de transporte, como por ejemplo JMS, TCP/IP, Email y Sistema de
ficheros, entre otros.

Incluye IDE grfico para el desarrollo.

- 125 -

Posee motor de orquestacin de servicios BPEL.

Transformacin de mensajes XML, a travs 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 documentacin y comunidad activa.

Tiene gran variedad de ejemplos de cdigo para la generacin de nuevos servicios.

Es posible cambiar fcilmente 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 implementacin de una infraestructura SOI (Service Oriented
Infrastructure). [31]

Figura 78 - Arquitectura de JBoss ESB. Extrado de [31].

Open ESB
OpenESB es un ESB basado en la especificacin JBI, iniciado por Sun Microsystems, y que permite
integrar fcilmente aplicaciones empresariales y servicios como aplicaciones con bajo acoplamiento.

- 126 -

Esto ESB permite desarrollar de manera fluida y rpida aplicaciones compuestas, con todas las ventajas
de la Arquitectura Orientada a Servicios. [32]
Caractersticas brindadas

Basado en el estndar JBI.

Soporta mltiples protocolos de transporte, como JMS, HTTP, SOAP, REST, FTP, Email y Sistema
de ficheros, entre otros.

Incluye IDE grfico y una consola de administracin web.

Motor de orquestacin de servicios BPEL.

Transformacin de datos XML a travs 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 arquitectnicos que son relevantes para la
integracin de OpenESB con Glassfish.

Figura 79 - Arquitectura de Open ESB. Extrado de [33].

- 127 -

Mule ESB
Mule ESB est implementado en Java y permite integrar sistemas de forma sencilla,
independientemente de las diferentes tecnologas y aplicaciones. Mule fue diseado para integrarse
fcilmente con servidores de aplicacin o ejecutar como un servidor standalone. Se integra con
numerosos framework, como por ejemplo spring, adems soporta una gran cantidad de conectores de
capa de transporte. [34]
Caractersticas brindadas

Soporta mltiples protocolos de transporte como por ejemplo JMS, HTTP, email, FTP, etc.

Incluye IDE grfico para el desarrollo de aplicaciones.

Soporta transformacin de datos XML, utilizando transformaciones XSLT.

Ruteo de mensajes basado en contenido, a travs de Xpath y JXPath.

Permite comunicacin sncrona y asncrona.

Manejo de mensajera utilizando request y response.

Brinda soporte a J2EE, como por ejemplo JBI, JMS, EJB, JCA, JTA, Servlet.

Amplitud de conectividad (ms de 60 tecnologas).

Tolerancia a fallos a travs de la gestin de excepciones.

Opciones de seguridad, brindando funcionalidades de autenticacin y autorizacin.

Facilidad para realizar pruebas unitarias a travs de la biblioteca JUnit.

Es el ESB Open Source ms utilizado.

- 128 -

Arquitectura
A continuacin, la Figura 80 presenta la arquitectura general del producto Mule ESB, detallando sus
principales componentes, los cuales hacen posible su integracin con varios servidores de aplicaciones.

Figura 80 - Arquitectura de Mule ESB. Extrado de [34].

- 129 -

- 130 -

Apndice 3. Estructura Fsica de la Plataforma


En este apndice se detalla cmo est estructurada la implementacin 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 Administracin), Jboss-ESB-AdaptativeMotorMonitor (Motor de Administracin y Monitoreo) y un cuarto proyecto comn a los anteriores, que
contiene las interfaces y el cdigo compartido, denominado Jboss-ESB-Adaptative-Core.
La Figura 81 muestra de forma grfica la estructura de cada uno de los proyectos y sus principales
paquetes.

Figura 81 - Proyectos java de la plataforma implementada.

- 131 -

- 132 -

Apndice 4. Opciones de Extensibilidad de la Plataforma


Este apndice presenta ejemplos prcticos 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 Adaptacin, luego se presenta cmo crear un nuevo Requerimiento de Adaptacin.

Implementacin de una nueva Estrategia de Adaptacin


Para implementar nuevas Estrategias de Adaptacin, se debe generar un proyecto Jar que permita ser
desplegado en el mismo ClassLoader que el Motor de Adaptacin 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 adaptacin son desarrolladas utilizando clases Java que deben implementar la interfaz
IAdpStrategy. Esta interfaz contiene un solo mtodo denominado getAdpTree, que el Motor de
Adaptacin y Monitoreo invoca cuando se requiere utilizar una estrategia de adaptacin. Dicho mtodo
recibe la informacin 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 adaptacin del tipo
GenericTreeNode<AdpFlowInterface>.
La Figura 82 presenta el cdigo utilizado para implementar la estrategia encargada de diferir los pedidos
de un servicio virtual.

Figura 82 - Implementacin de la estrategia encargada de diferir los pedidos.

- 133 -

Cada estrategia registrada en la plataforma se carga en tiempo de ejecucin utilizando Reflection, y cada
vez que se requiere invocarla se crea una nueva instancia. Por lo tanto, la incorporacin de una nueva
estrategia est libre a la creatividad del desarrollador, siendo posible utilizar cualquier mecanismo de
adaptacin en su implementacin.

Registro de las Estrategias de Adaptacin


El registro de las Estrategias de Adaptacin se realiza mediante el archivo de configuracin jbossadaptative-strategies.xml. Para registrar una estrategia se debe indicar tanto la clase Java que la
implementa, como la lista de los requerimientos de adaptacin que la estrategia puede abordar. La
definicin 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 ejecucin segn 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 adaptacin se detalla en la
Figura 83.

Figura 83 - Registro de estrategias de adaptacin.

Implementacin de un nuevo Requerimiento de Adaptacin Complejo.


Para definir un nuevo Requerimiento de Adaptacin se debe especificar una clase Java que implemente
la interfaz IAdpServiceRequirement, de esta forma se tratan de forma genrica todos los requerimientos
de adaptacin de la plataforma. Dicha interfaz cuenta con un nico mtodo denominado
needRequiredAdp, que recibe toda la metadata definida para un servicio y su lista de las propiedades
monitoreadas. El mtodo needRequiredAdp tiene la responsabilidad de calcular si el requerimiento de
adaptacin se cumple o no.
La clase implementada debe estar accesible en el mismo ClassLoader en el que se encuentre ESBAdaptativo, y debe tener como dependencia al proyecto JBoss-ESB-Adaptative-Core. La Figura 84
presenta el cdigo utilizado para implementar el requerimiento de cambio de contrato, definido en la
configuracin base de la plataforma.

- 134 -

Figura 84 - Implementacin de un requerimiento de adaptacin complejo.

Registro de los Requerimientos de Adaptacin complejos.


El archivo de configuracin jboss-adaptative-service-requirements.xml registra todos los requerimientos
de adaptacin de la plataforma, siendo posible especificar tanto requerimientos simples como los
complejos. Todos los requerimientos de adaptacin se especifican fcilmente como se detalla en la
Seccin 5.4.

- 135 -

You might also like