WICC 2012 423

Análisis de Calidad en Enterprise Service Bus, propietarios y de

código abierto, mediante la utilización del método de calidad ESB-
QM
Arias Esteban Gabriel1, Mg. Patricia Bazán2
1 Facultad de Informática UNLP 2 LINTI Facultad de Informática UNLP
[email protected], [email protected]

Resumen • Middleware diferentes para manejar la

La integración de sistemas de manera comunicación (MOMS, Object Request
confiable, escalable, robusta, segura y adaptable a Brokers (CORBA, RMI), RPCs)
los cambios es una necesidad ante el crecimiento y • Múltiples modelos de transmisión
diversidad de sistemas y tecnología y ante los (conversacionales,
requerimientos de alta disponibilidad. Como requerimiento/respuesta, publicación \
resultado de de estos esfuerzos de integración suscripción )
surge Arquitectura orientada a servicios (SOA por • Múltiples tecnologías de Persistencia de
sus siglas en Ingles), que permite construir Datos (BD relacionales, VSAM, BD de
aplicaciones e integrar las existentes a partir de escritorio como Microsoft Access, XML
servicios auto-contenidos y heterogéneos, tanto en BD)
tecnología como en locación geográfica. La En contraste, los procesos de negocio,
herramienta tecnológica que surge para resolver la raramente hacen uso de un silo funcional en
parte técnica de esta arquitectura, que refiere a la particular, mas bien son procesos que usan distinta
integración tecnológica entre servicios, son los información procedente de los mismos y a través
ESB (Enterprise Service Bus). En este artículo se de distintos departamentos claves de las empresas.
propone demarcar los lineamientos para realizar Dicha característica de los procesos de
análisis de calidad a atributos que son propios de negocio, a la hora de integrar las aplicaciones,
los productos ESB, basándonos en la taxonomía generó graves inconvenientes y costes de
definida por el método ESB-QM, que es el único desarrollo al intentar automatizarlos como
enfoque hasta la fecha que los considera. consecuencia lógica de las necesidades de
Palabras clave: ESB, SOA, ESB-QM procesamiento de las empresas, debido a que la
información se encontraba frecuentemente en
varios sistemas a la vez, con formatos dispares, y
Contexto
tecnológicamente diferentes, a la vez que podían
El presente es un trabajo de fin de carrera
residir en lugares geográficamente distintos.
de Licenciatura en Informática de la Facultad de
a. Evolución hacia ESB
Informática de la UNLP, del alumno Esteban
La primera aproximación para integrar
Arias, dirigida por la Mg. Patricia Bazán.
las aplicaciones era no tener ningún método
preestablecido y realizar las mismas al vuelo,
Introducción conectando directamente las aplicaciones. A este
Hasta hace poco más de una década, las tipo de integración se la llamo “arquitectura
aplicaciones de software empresarial se enfocaban accidental” [3] y se muestra en la figura 1, donde
hacia el tipo de información que procesaban y se se ve la conexión realizada de manera puntual y
construían de manera aislada unas de otras [1]. directa entre las distintas aplicaciones.
Entre estos sistemas se pueden encontrar:
• ERP (Enterprise resource planning)
• BI (Sistemas de Business
Intelligence)
• CRM (Customer Relationship
Management)
• Sistemas de Logística
• Sistemas Web (Portales,
Aplicaciones Web y Web Services)
• Sistemas pertenecientes a los
partners de negocio
Estas aplicaciones están construidas en
los más diversos lenguajes y plataformas Figura 1 - Arquitectura Accidental [3]
tecnológicas. Se pueden encontrar por ejemplo: [2] Dicha arquitectura tiene varios
• Clientes servidores monolíticos, sistemas inconvenientes como:
n-capas y silos mainframe. • Crecimiento exponencial de conexiones
• Sistemas orientados a objetos, • Alto acoplamiento entre las aplicaciones
procedurales y basados en componentes • Altos costo de modificación
• Múltiples lenguajes de programación.

2012 XIV Workshop de Investigadores en Ciencias de la Computación

WICC 2012 424

• Imposibilidad de unificar monitoreo y 2. Costos altos de instalación debido a que no

gerenciamiento de la infraestructura. permiten despliegue incremental de la
• Imposibilidad de usar estándares infraestructura, y de licenciamiento y
Una mejora al planteo anterior son las capacitación de la misma, ya que utilizan
arquitecturas Hub and Spoke. Estas se caracterizan tecnologías propietarias del proveedor del
por usar un administrador de mensajería HUB y sus adaptadores.
centralizado (HUB), construido sobre un 3. Baja performance y escalabilidad ante el
middleware orientado a mensajes (MOM), y crecimiento de la información a administrar,
adaptadores (SPOKE), que conectan las por su naturaleza centralizada y monolítica
aplicaciones al administrador, como se visualiza 4. No soportan nuevas tecnologías como Web
en la figura 2, y convierten los datos de las Services.
aplicaciones en un formato que el administrador b. Enterprise Service Bus
entiende, y viceversa. Como se ve en la tabla 1, Como resultado de los esfuerzos de
introduce mejoras considerables en confiabilidad, resolver los problemas de integración de las
acoplamiento, cantidad de conexiones y arquitecturas anteriores surgió SOA (Service
gerenciamiento de la infraestructura, con respecto Oriented Architecture).
a la arquitectura accidental. SOA representa una arquitectura ágil,
abierta, federada, extensible y compuesta,
comprendida de servicios autónomos con
capacidades de calidad (QoS), interoperables,
reusables, y con transparencia de locación de los
mismos. Permite establecer una abstracción de la
lógica y de la tecnología de negocio de manera que
se puede introducir cambios al proceso de
modelado del negocio y de la arquitectura técnica,
dando por resultado bajo acoplamiento entre estos
modelos. [1][4].
La arquitectura SOA cumple con
Figura 2 - Arquitectura hub and spoke
integración, reusabilidad, transparencia de
locación, interoperabilidad y seguridad, mediante
Tabla 1 – Aportes de la Arquitectura hub and
un componente central denominado ESB
spoke
(Enterprise Service Bus). Un Enterprise Service
Característic Descripción de la mejora
a mejorada Bus es una plataforma de integración, basada en
El HUB y los adaptadores aíslan estándares y altamente distribuida, que permite a
Acoplamient
a las aplicaciones de los detalles las aplicaciones ser accedida vía servicios. Esta
o entre
tecnológicos de ruteo y infraestructura combina: [3] [4] [5]:
aplicaciones
transformación de mensajes y • Middleware de mensajería (MOMs)
protocolos, y de las direcciones • Web Services y REST-Based Services
físicas reales para comunicarse • XML
entre ellas. Adicionalmente, • Transformación de datos
permite virtualmente que una • Conversión de protocolos
aplicación no conozca a las
• Ruteo inteligente
aplicaciones que consumen sus
Una descripción detallada de cómo
mensajes.
soporta un ESB estas características se encuentra
Reducción El orden de Conexiones es O(n),
ya que las aplicaciones en la tabla 2.
de
solamente se conectan al El modelo de despliegue de los ESB es
conexiones
adaptador que les corresponde. una red integrada de instancias de servicios, que se
El número n es la cantidad de distribuyen y colaboran a través de contenedores
aplicaciones a conectar. de servicios [3], como se visualiza en la figura 3.
Confiabilida Los MOMs existentes en el Estos contenedores están distribuidos a través de la
d HUB garantizan el envío de red y permiten descentralizar la arquitectura y el
mensajes por medio de técnicas despliegue incremental de los mismos.
como store and forward. Un ESB desacopla a los consumidores de
Gestión Al ser una arquitectura los servicios de los proveedores de los mismos, y
centralizada centralizada, también su gestión permite virtualmente, conectar los mismos
y monitoreo se realiza de independientemente de la tecnología de las
manera centralizada y aplicaciones. Proveen capacidades adicionales
homogénea. como [3] [4]:
Sin embargo hay algunos problemas • Manejo centralizado de la seguridad
aquí: • Envío de mensajes asegurado
1. Se introduce un punto único de falla, ya que si • Configuración y monitoreo centralizado
falla el HUB fallará toda la infraestructura
• Directorios de servicios
asociada a él.

2012 XIV Workshop de Investigadores en Ciencias de la Computación

WICC 2012 425

• Gateways de acceso externo a la mensajería confiable se

empresa logra a través de los MOMs
que posee el ESB.
• Servicios de coreografía de procesos.
Los mismos soportan estilos de
integración empresarial como son arquitecturas
manejadas por mensaje y arquitecturas manejadas
por eventos, además de SOA.
Tabla 2 - Aportes fundamentales de ESB
Característica Descripción de la mejora
que mejora
ESB
Procesamiento EL procesamiento se
distribuido distribuye a través de
contenedores de servicios,
que permiten gestionar el
despliegue y ciclo de vida Figura 3 - Visión general de un ESB [6]
de los servicios y puede ser c. Métodos de evaluación de ESB
distribuido en distintas La especificación y evaluación de calidad
locaciones geográficas. Esto de productos de software, es un factor clave para
permite eliminar el punto garantizar la calidad adecuada de los mismos.
único de falla que genera el Esto puede lograrse mediante la definición de
procesamiento centralizado características de calidad apropiadas, teniendo en
de las arquitecturas HUB cuenta los propósitos de uso de los productos de
and SPOKE, a la vez que software. Los requisitos no funcionales, son
hace escalable fácilmente la importantes para la integración de aplicaciones, y
infraestructura. en consecuencia para realizar comparación entre
Uso de A diferencia de las solucione que las realicen [6].
estándares arquitecturas anteriores, En particular los modelos de evaluación
hace alto uso de estándares,
de calidad de arquitecturas de software reúnen
en especial de XML, lo cual
taxonomías de atributos de calidad, comúnmente
baja costos de capacitación
y licenciamiento, permite usados para especificar y evaluar requerimientos
cambiar de productos ESB no funcionales. Buscan definir características que
con relativa facilidad, y a la debe satisfacer un producto de software, de forma
vez permite más que se puedan cuantificar las mismas a través de
interoperabilidad entre los atributos medibles. La diferencia entre modelos
distintos componentes que radica en dicha clasificación [6].
conforman la infraestructura Existen varios métodos para evaluar
de integración. ESB. El grupo Seybold [7], y Vollmer [8]
Web Services Los ESB soportan diseñaron frameworks y cuestionarios de
completamente la mediación evaluación que agrupan las características
y gestión de servicios vía funcionales y no funcionales que deberían tener
web servicies, a la vez que un ESB. Estos métodos son bastante completos
adhieren a la mayoría de los pero no apuntan a medir los ESB mediante
estándares WS-* atributos de calidad sino por el grado de resolución
Ruteo Un ESB es capaz de decidir de características técnicas. Los atributos de calidad
Inteligente el destino de los mensajes los nombran de manera aislada y mezclados con
que transitan a través de él, las características técnicas, como se muestra en la
basado en el contenido del
tabla 3 y no tienen en cuenta atributos clave de un
cuerpo del mensaje, basado
ESB como por ejemplo reusabilidad.
en los datos de contexto del
mensaje o por medio de Tabla 3 - Algunas características, agrupando
motores de reglas como capacidades técnicas mezcladas con atributos
pueden ser los motores que de calidad [7].
implementan BPEL4WS
Transformació Un ESB es capaz de de
n de mensajes, transformar los datos de un
conversión de mensaje de un formato a
protocolos y otro, en especial por el uso
mensajería de plantillas XSLT.
confiable También es capaz de mediar
transparentemente entre las
aplicaciones para realizar
conversiones entre
protocolos distintos de
comunicación. La

2012 XIV Workshop de Investigadores en Ciencias de la Computación

WICC 2012 426

Por otro lado los trabajos bien apuntados virtualización de los servicios, de forma que si
a medir atributos de calidad de ESB, trabajan con un equipo falla, o si se cambia la ubicación de
algún atributo de calidad en concreto, como ser un proveedor de servicio, no es preciso
performance en [9], y no definen un método notificar el cambio a cada uno de los clientes
completo de evaluación de calidad de ESB. individuales. La transparencia de ubicación
No se observa a partir del análisis permite que los servicios se actualicen,
realizado, evaluaciones completas sobre los ESB, muevan o reemplacen sin necesidad de
direccionadas íntegramente desde el punto de vista modificar los códigos de las aplicaciones.
de calidad. Una de las aproximaciones evaluadas, 2. Independencia de implementación: Capacidad
que va en la dirección correcta, para brindar una de un ESB para abstraer el contrato de la
herramienta de evaluación desde este punto de implementación del servicio.
vista de calidad, y que es la que se selección para
el presente trabajo es el Modelo ESB-QM.
3. Facilidad de reubicación: Facilidad de un ESB
para permitir la reubicación transparente de la
El modelo de calidad ESB-QM, es una
implementación de un servicio en caso de que
instancia del modelo ISO-9126-2001, clasifica el
esta haya cambiado.
producto de software usando las 6 características
del modelo ISO-9126-1 más cuatro características 4. Disponibilidad: Capacidad de un ESB para
propias de los ESB, como se visualiza en la tabla exponer servicios de negocio tanto a internos
4, la cual compara ambos modelos: ubicuidad, como a externos y componer servicios a partir
delegabilidad, reusabilidad y manejabilidad de otros ya existentes a través de lenguajes no
procedurales, metalenguajes o cualquier otra
Tabla 4 - Modelo ESB-QM [6] metodología.
2 – Delegabilidad
Es el conjunto de atributos de un ESB
que le permite a un servicio delegar funciones a
otro servicio y recuperar los resultados en forma
transparente y confiable a través de éste. Sus
subcategorías son:
1. Facilidad de desentendimiento: Capacidad de
un ESB para permitir la entrega de un
mensaje y liberar de responsabilidad al
remitente, esto es logrado a través de la
utilización de las facilidades brindadas por la
mensajería asíncrona y el paradigma
publicación/suscripción.
3 – Reusabilidad
Es la facilidad con la cual aplicaciones
existentes o componentes pueden ser reutilizados.
Los servicios propios del ESB son modulares y
auto-contenidos, reduciendo el número de
dependencias de uso entre ellos. Por esta razón, es
la capacidad de un servicio propio de ser
d. Atributos de calidad de los ESB, definidos en
reutilizado en muchas aplicaciones integradas vía
el método ESB-QM
el ESB. Sus subcategorías son:
Las características propias de los ESB,
enumeradas en el método ESB-QM [6] son: 1. Separability: Es el conjunto de capacidades
1 - Ubicuidad que permite independencia entre servicios y
Es el conjunto de atributos de un ESB que poca complejidad en sus relaciones. Está
brindan a un servicio la capacidad de ser asociado con dos atributos: (a) Bajo
encontrado y utilizado independiente de su acoplamiento que refiere a la capacidad de un
ubicación e implementación. Sus subcategorías ESB para permitir la independencia entre las
son: implementaciones de los servicios mediante la
definición de funcionalidades acotadas y
1. Transparencia de ubicación: Capacidad de un específicas, y (b) Modularidad, que refiere a
ESB para localizar la instancia de un Servicio
la capacidad de un ESB para disminuir las
independiente de su ubicación. Se logra a
dependencias entre 2 servicios disminuyendo
través del enrutamiento inteligente y debe
las dependencias artificiales.
poder ser configurado basado en el asunto,
contenido o itinerario del mensaje. Con la 2. Flexibilidad: Los ESB facilitan la
mediación entre servicios, un servicio cliente composición de aplicaciones basándose en
que invoque al proveedor de servicio solo servicios, permiten la definición de sistemas
necesita saber que el servicio existe. El cliente complejos distribuidos, incluyendo la
no necesita saber dónde se está ejecutando el integración de diferentes aplicaciones,
servicio. El ESB localiza el servicio cuando se sistemas, firewall, etc. Además estos pueden
invoca. Esto proporciona un cierto nivel de

2012 XIV Workshop de Investigadores en Ciencias de la Computación

WICC 2012 427

ser construidos a partir de sistemas FORMACIÓN DE RECURSOS HUMANOS

preconstruidos.
4 – Manejabilidad La integración de aplicaciones de
Los ESB deben tener las capacidades de software representa un desafío no solamente para
administración, de forma que puedan gestionar y la industria sino también dentro de los ámbitos
monitorear los servicios a los que dan soporte académicos. Su evolución ha dado lugar a la
mediante registros y auditorias de servicios instrumentación de métodos y herramientas
centralizados, fallas, estado de procesos, etc. que la sustenten e incluso la definición de nuevas
También deben ser capaces de integrarse en arquitecturas como lo es SOA y su principal
sistema de gestión del software. Sus subcategorías tecnología de soporte, los ESB. El análisis de
son: calidad, por su parte, es una actividad necesaria
1. Serviciabilidad: Capacidad de informar las para asegurar el cumplimiento de atributos que son
condiciones de excepción, proporcionando propios de los ESB.
información de las causas y efectos de las El presente trabajo se enmarca en una
mismas. línea de investigación en SOA-BPM donde se
están formando alumnos para desarrollar su tesina
2. Trazabilidad: Capacidad de informar el paso e interactuar con docentes e investigadores
por cada componente y notificar el estado de
formados con el objeto de incorporar herramientas
una transacción de proceso de negocio en
de soporte de esta línea de trabajo para solucionar
cada uno.
problemas reales.
LÍNEAS DE INVESTIGACIÓN Y
REFERENCIAS
DESARROLLO
Esta línea de investigación pretende
realizar un análisis profundo de las características [1] Thomas Erl – Service-Oriented Architecture:
de los ESB, tanto desde el punto de vista Concepts, Technology, and Design - Prentice Hall –
2005
tecnológico como teórico, indicando los distintos
[2] Juric Matjaz B., Loganathan Ramesh,
escenarios que solucionan y las distintas
Poornachandra Sarang, Frank Jennings - SOA
arquitecturas posibles de ESB para solucionar Approach to Integration XML, Web services, ESB,
dichos escenarios. Asimismo se busca aplicar de and BPEL in real-world SOA projects - Packt
manera práctica, un método de medición de Publishing. 2007.
calidad existente como lo es ESB-QM, a ESB
reales como Websphere ESB, propietaria de IBM, [3] D. Chappell. Enterprise Service Bus. O’Relly
y Mule ESB de código abierto, mediante un caso Media Inc. (2004)
de estudio concreto.
[4] M. Keen, A. Acharya y et al. IBM Redbooks
RESULTADOS Y OBJETIVOS Patterns: Implementing
an SOA Using an Enterprise Service Bus. (2004)
El objetivo del presente trabajo es
describir exhaustivamente cómo se debe evaluar [5] Nicolai M. Josuttis – SOA in practice – O`Reilly
un ESB mediante el método ESB-MQ, tanto en sus (2007)
aspectos funcionales como no funcionales, y
realizar la medición de 2 plataformas de [6] Daily Echeverría, Hernán Astudillo, Rodrigo
referencia, en este caso IBM Websphere ESB de Estrada - ESB-QM: Modelo de Calidad para
productos ESBs (2008)
código propietario, y Mule ESB de código abierto.
Los resultados giran en torna a la investigación de
[7] Patricia Seybold Group– Enterprise Service Bus -
los distintos patrones de construcción de los ESB, Evaluation Framework, Criteria for Selecting an
haciendo énfasis en como solucionan Enterprise Service Bus as an Integration Backbone
efectivamente los distintos problemas de -2005
integración de las EAI, SOA y B2B, con bajo
acoplamiento y bajo impacto en costos y [8] Ken Vollmer - The Forrester Wave™: Enterprise
desarrollo ante los cambios. Service Bus, Q2- 2011
Además se estudia y analiza a la
metodología ESB-QM, mostrando los distintos [9] Sanjay P. Ahuja, Amit Patel – Enterprise Service
aspectos evaluables de un ESB, funcionales y no Bus: A Performance Evaluation – 2011
funcionales, así como las métricas necesarias para
realizar dichas evaluaciones.
Por último, se aplica la medición de
calidad, mediante un caso de estudio, usando el
método ESB-QM, de un ESB propietario IBM
Websphere ESB http://www-01.ibm.com/software/
integration/wsesb/ y uno open source, Mule ESB
http://www.mulesoft.org/.

2012 XIV Workshop de Investigadores en Ciencias de la Computación