Professional Documents
Culture Documents
Universidad de la Repblica
Montevideo, Uruguay
Implementacin de una
Plataforma ESB Adaptativa
Informe de Proyecto de Grado
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
Solucin Propuesta..................................................................................................................... 47
4.1
4.2
4.3
4.4
4.5
4.6
-5-
Referencias ................................................................................................................................115
Apndice 1.
Apndice 2.
Apndice 3.
Apndice 4.
-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.
-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.
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.
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-
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.
-9-
- 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].
1
2
http://www.w3.org/
http://www.oasis-open.org
- 11 -
- 12 -
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 -
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383532
- 14 -
- 15 -
mltiples plataformas. Los ESBs pueden resolver gran parte del proceso de integracin permitiendo
tener un buen control del mismo.
Comunicacin
Capacidad
Ruteo.
Manejo de Direcciones.
Al menos un tipo o estilo de mensaje.
Al menos un protocolo de transporte.
Integracin
Servicio de interaccin
Direccin y autonoma
Motivo
- 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.
www.eaipatterns.com
- 17 -
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 -
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.
- 19 -
- 20 -
- 21 -
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]
- 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.
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 -
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.
- 24 -
Representacin Grfica
Caractersticas
Tranformacin de Mensajes
Lgica de Transformacin
Cache
Retardador
Tiempo de retardo
Ruteo de Mensajes
Unificador de Respuestas
Condicin de Completitud
Algoritmo de Agregacin
Lista de Destinarios
- 25 -
Ruteo para Balanceo de Carga: Tiene como objetivo distribuir la carga de las distintas solicitudes
a mltiples Servicios ESB.
- 26 -
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
Condicin de Salida
Servicio Virtual
Tarea atmica
AND-split
XOR-split
XOR-join
- 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.
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 -
- 30 -
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 -
6
7
http://www.jboss.org/jbossesb
http://www.mulesoft.org/
- 33 -
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.
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.
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.
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.
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
09/04/2012
17/11/2011
06/01/2012
04/01/2010
17/02/2012
Documentacin
MUY BUENA
BUENA
REGULAR
ESCASA
BUENA
SI
SI
SI
NO
SI
Experiencia
SI
NO
NO
NO
NO
Tipo de Licencia
11
http://jcp.org/en/jsr/detail?id=312
- 36 -
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
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
- 37 -
JBoss ESB
Mule ESB
Apache Synapse
OpenESB
ServiceMix
SI
SI
SI
SI
SI
Geronimo,
JBoss, WebLogic,
WebSphere, Tomcat
Glassfish
JBossAS
Apache
Geronimo
JBOSS JonAS
Compatibilidad estndar
JBI
SI
SI
NO
SI
SI
NO
NO
NO
SI
SI
Conector JDBC
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
Conector transporte
HTTP
SI
SI
SI
SI
SI
Conector transporte de
ficheros
SI
SI
SI
SI
SI
SI
SI
SI
SI
SI
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
- 38 -
- 39 -
- 40 -
- 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/*.
- 42 -
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.
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.
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
synchronous
True
serviceInvokerTimeout
20000
asyncResponse
Respuesta asincrnica.
<ack/>
securityNS
http://docs.oasis-open.org/wss/2004/01/oasis200401http-wss-wssecurity-secext-1.0.xsd
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.
- 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.
- 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.
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.
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 -
La plataforma debe contar con puntos de extensin que permitan agregar fcilmente nuevas
funcionalidades a las ya implementadas.
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 -
- 50 -
Descripcin
Mecanismo
TRN
Transformacin
RUT
Ruteo intermediario
LST
Lista de destinatarios
UNI
Unificador de respuestas
CCH
Cache
RET
Retardador
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 -
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.
Caracterstica/Propiedad Adicional
Transformaciones
Lgica de transformacin
Ruteo intermediario
Lgica de ruteo
Servicios ESB destino
Lista de destinatarios
Condicin de Completitud
(mejor respuesta)
Algoritmo de Agregacin
Cache
Retardador
Tiempo de retardo
Unificador de respuestas
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 -
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.
- 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.
13
http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html
- 55 -
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.
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.
- 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
- 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.
- 58 -
- 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
degradacin-respuestas-exitosas
saturacin-servicio
cambio-contrato
- 60 -
Requerimiento de Adaptacin
Descripcin
disminuir-tiempo-respuesta
aumentar-respuestas-exitosas
disminuir-solicitudes
manejar-cambio-contrato
Descripcin
invocar-servicio-equivalente
utilizar-informacin-almacenada
distribuir-solicitud-equivalentes
balancear-carga
diferir-pedidos
modificar-solicitud-respuesta
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.
analizar en tiempo real los procesos de adaptacin que se generan en la plataforma y almacenar
un histrico de los mismos.
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.
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.
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 -
- 64 -
- 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.
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.
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.
- 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.
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 -
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.
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.
- 70 -
- 71 -
- 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.
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
org.fing.edu.uy.esbadp.action.cache. CacheLoadAction
Retardador
org.fing.edu.uy.esbadp.action.delayer. DelayerAction
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.
- 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.
17
http://www.w3.org/TR/wsdl#_soap-b
- 75 -
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.
Renombrar operacin.
Quitar 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.
No soportado.
No soportado.
Quitar Parmetro.
Soportado.
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 -
- 77 -
Mecanismos utilizados
Forma de clculo
Invocaciones exitosas.
Invocaciones con fallas.
Porcentaje de respuestas
exitosas
Invocaciones exitosas.
Invocaciones con fallas.
T. de respuesta total
Invocaciones exitosas.
Invocaciones con fallas.
Diferencias detectadas en el
WSDL
Cambio de contrato.
- 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.
- 79 -
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.
- 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.
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:
Por ltimo, la tabla SERVICE_EQUIV persiste la relacin de equivalencia de los servicios virtuales. Los
atributos que componen esta tabla son las siguientes:
- 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.
Descripcin
Archivo
SleepTimeThreadAdmMonitor
jboss-adaptative-config.xml
CompareWSDLImpl
jboss-adaptative-config.xml
MotorMonitorURL
jboss-adaptative-config.xml
MotorMonitorObjectName
jboss-adaptative-config.xml
PathWSDLStore
jboss-adaptative-config.xml
PathXSLTStore
jboss-adaptative-config.xml
- 82 -
Nombre
Descripcin
Archivo
jmx.service.url.esbadp
config.properties
jmx.service.name.esbadp
config.properties
motor.time.expiration.strategy
config.properties
motor.historic.flag
config.properties
motor.historic.count
config.properties
- 83 -
Figura 52 - Estados y transiciones de los hilos creados por del Motor de Adaptacin y Monitoreo.
- 84 -
En las siguientes sub-secciones se describen cada uno de los sub-componentes que conforman el Motor
de Adaptacin y Monitoreo.
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 -
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.
- 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.
- 87 -
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.
- 88 -
- 89 -
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.
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 -
- 92 -
VisualVM, se observ que el mismo era causado por no cerrar las conexiones establecidas a travs de las
comunicaciones JMX.
21
http://hsqldb.org/
- 93 -
- 94 -
- 95 -
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.
- 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)
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.
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 -
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)
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 -
- 99 -
para realizar una invocacin a la funcionalidad obtener informacin persona, brindada por un servicio
virtual que accede a los servicios del organismo 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.
- 100 -
22
23
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.
http://www.soapui.org/
http://visualvm.java.net/
- 101 -
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%
36380
731
784
90%
- 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
BPSWS
DGIWS
DNICWS
Cache
4777
20701
6370
4532
13%
57%
18%
12%
Descripcin
Detectado
Invocacin
Si
Exitosa
Si
Exitosa
Si
Exitosa
Si
Exitosa
Si
Exitosa
- 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.
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
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.
- 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.
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 -
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.
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 -
- 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:
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.
http://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.1.pdf
http://mx4j.sourceforge.net/
- 110 -
- 111 -
27
http://aws.amazon.com/es/ec2/
- 112 -
- 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:
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 -
- 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.
- 119 -
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:
La Figura 72 muestra un flujo de adaptacin que representa esta estrategia. Este flujo utiliza los
mecanismos de ruteo intermediario y transformaciones.
- 120 -
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.
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.
- 121 -
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.
- 122 -
JBoss ESB, OpenESB y Mule ESB, el cual permiti seleccionar el producto ESB ms adecuado a las
necesidades de este proyecto.
Es un ESB que soporta la mayora de las funcionalidades de los modelos de ESB tericos.
Provee soporte a HTTP/S, Mail (POP3, IMAP, SMTP), JMS, TCP, UDP, VFS, SMS, XMPP and FIX.
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.
- 123 -
Arquitectura
La Figura 76 presenta la arquitectura de los componentes del producto Apache Synapse, detallando sus
conectores y protocolos.
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.
Dispone de ruteo basado en contenido a partir de expresiones XPath sobre mensajes XML
normalizados
- 124 -
El producto puede ser integrado de forma nativa con JBoss AS, Apache Geronimo o JOnAS.
Arquitectura
La Figura 77 presenta la arquitectura del ESB ServiceMix, donde se detallan sus principales
componentes.
JBoss ESB
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 mltiples protocolos de transporte, como por ejemplo JMS, TCP/IP, Email y Sistema de
ficheros, entre otros.
- 125 -
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.
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]
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
Soporta mltiples protocolos de transporte, como JMS, HTTP, SOAP, REST, FTP, Email y Sistema
de ficheros, entre otros.
Arquitectura
La Figura 79 presenta los principales componentes arquitectnicos que son relevantes para la
integracin de OpenESB con Glassfish.
- 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.
Brinda soporte a J2EE, como por ejemplo JBI, JMS, EJB, JCA, JTA, Servlet.
- 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.
- 129 -
- 130 -
- 131 -
- 132 -
- 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.
- 134 -
- 135 -