R Z. F U S - lsi.us.es · integraciÓn de aplicaciones un lenguaje especÍfico de dominio para el...

INTEGRACIÓN DE APLICACIONES###

UN LENGUAJE ESPECÍFICO DE DOMINIO PARA EL

DISEÑO DE SOLUCIONES DE INTEGRACIÓN

RAFAEL Z. FRANTZ

UNIVERSIDAD DE SEVILLA

RESEARCH REPORTDR. RAFAEL CORCHUELO

JUNIO, 2008

First published in June 2008 byThe Distributed GroupETSI InformáticaAvda. de la Reina Mercedes s/nSevilla, 41012. SPAIN

Copyright c© MMVIII The Distributed Grouphttp://[email protected]

In keeping with the traditional purpose of furthering science, education and research,it is the policy of the publisher, whenever possible, to permit non-commercial use andredistribution of the information contained in the documents whose copyright theyown. You however are not allowed to take money for the distribution or use of theseresults except for a nominal charge for photocopying, sending copies, or whichevermeans you use redistribute them. The results in this document have been tested ca-refully, but they are not guaranteed for any particular purpose. The publisher or theholder of the copyright do not offer any warranties or representations, nor do theyaccept any liabilities with respect to them.

Categorías (ACM 1998): D.2.11 [Software Architectures]: Domain-specific architectu-res; D.2.13 [Reusable Software]: Domain engineering.

Financiación: Evangelischer Entwicklungsdienst e.V. (EED), Plan Nacional de I+D+I(expediente TIN2007-64119) y la Orden de Incentivos de la Junta de Andalucía (expe-diente P07-TIC-02602). Parte de esta financiación procede de fondos FEDER.

http://www.tdg-seville.info

[email protected]

A mi mujer y a mis padres.

Índice general

Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI

I Prefacio

1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 Contexto de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Propósito de esta investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.1 Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.2 Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.3 Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Resumen de contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Alcance de las herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.2 Capacidades de modelado . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3 Características técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3 Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

II Revisión de propuestas

II Índice general

3 Herramientas para la integración . . . . . . . . . . . . . . . . . . . . . 293.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2 Apache Camel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.1 Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2.3 Puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.2.4 Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.5 Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.2.6 Ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2.7 Miscelánea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3 Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.1 Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3.3 Puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3.4 Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3.5 Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.3.6 Ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.7 Miscelánea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4 Apache ServiceMix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.4.1 Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4.3 Puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4.4 Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4.5 Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.4.6 Ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.4.7 Miscelánea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.5 Spring Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.5.1 Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.5.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.5.3 Puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.5.4 Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.5.5 Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.5.6 Ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.5.7 Miscelánea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.6 BizTalk 2006 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.6.1 Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.6.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.6.3 Puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Índice general III

3.6.4 Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.6.5 Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.6.6 Ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783.6.7 Miscelánea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.7 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

III Nuestra propuesta

4 Metamodelo Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.2 Estructura de la solución de integración . . . . . . . . . . . . . . . . . . . . . 844.3 Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.4 Building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.5 Puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.6 Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.7 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.8 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

IV Consideraciones finales

5 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

V Apéndices

A Terminación de la documentación . . . . . . . . . . . . . . . . . . . 111

B Calidad de la documentación . . . . . . . . . . . . . . . . . . . . . . . 113

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

IV Índice general

Índice de figuras

3.1 Conceptos del mundo de la integración . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 Modelo conceptual de la arquitectura de Camel . . . . . . . . . . . . . . . . . . 333.3 Estructura y taxonomía de los mensajes y exchanges en Camel . . . . . 353.4 Estructura y taxonomía de las tareas de Camel . . . . . . . . . . . . . . . . . . . 393.5 Modelo conceptual de la arquitectura de Mule . . . . . . . . . . . . . . . . . . . 423.6 Estructura de los mensajes en Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.7 Tipos de tareas de Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.8 Tareas en el flujo de entrada de un servicio en Mule . . . . . . . . . . . . . . . 483.9 Tareas en el flujo de salida de un servicio en Mule . . . . . . . . . . . . . . . . 483.10 Modelo conceptual de la arquitectura de ServiceMix . . . . . . . . . . . . . . 513.11 Estructura y taxonomía de los mensajes en ServiceMix . . . . . . . . . . . . 543.12 Taxonomía de los mensajes en ServiceMix . . . . . . . . . . . . . . . . . . . . . . . 563.13 Modelo conceptual de la arquitectura de Spring Integration . . . . . . . . 603.14 Estructura y taxonomía de los mensajes en Spring Integration . . . . . . 633.15 Taxonomía de las tareas de Spring Integration . . . . . . . . . . . . . . . . . . . 653.16 Modelo conceptual de la arquitectura de BizTalk . . . . . . . . . . . . . . . . . 683.17 Estructura y taxonomía de los mensajes en BizTalk . . . . . . . . . . . . . . . 703.18 Estructura y taxonomía de los puertos de BizTalk . . . . . . . . . . . . . . . . . 733.19 Tipos básicos de .NETComponents en BizTalk . . . . . . . . . . . . . . . . . . . 753.20 Componentes simples de BizTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.21 Componentes compuestos de BizTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.1 Niveles y vistas en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.2 Estructura de la solución de integración en Guaraná . . . . . . . . . . . . . . 854.3 Mensajes y exchanges en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.4 Building blocks en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.5 Representación gráfica de los wrappers en Guaraná . . . . . . . . . . . . . . 884.6 Representación gráfica de los procesos en Guaraná . . . . . . . . . . . . . . . 89

VI Índice de figuras

4.7 Representación gráfica de los service proxies en Guaraná . . . . . . . . . . 894.8 Tipos de puertos en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.9 Puertos de mensajes en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.10 Comunicación entre puertos en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . 924.11 Puertos de datos en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.12 Metáfora de un fregadero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.13 Tipos de tareas en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.14 Grupos de tareas simple en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.15 Tareas de tipo routers en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.16 Tareas de tipo transformadores en Guaraná . . . . . . . . . . . . . . . . . . . . . . 984.17 Tareas de tipo constructores en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . 984.18 Ejemplo de diseño de solución de integración con Guaraná . . . . . . . . 99

Índice de tablas

2.1 Propiedades relacionadas con el alcance de las herramientas . . . . . . . 132.2 Propiedades relacionadas con las capacidades de modelado . . . . . . . 172.3 Propiedades de carácter técnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4 Valores deseables para las propiedades de alcance . . . . . . . . . . . . . . . . 252.5 Valores deseables para las propiedades de modelado . . . . . . . . . . . . . 252.6 Valores deseables para las propiedades técnicas . . . . . . . . . . . . . . . . . . 26

3.1 Vocabulario de la herramienta Camel . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2 Vocabulario de la herramienta Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.3 Vocabulario la herramienta ServiceMix . . . . . . . . . . . . . . . . . . . . . . . . . . 523.4 Vocabulario de la herramienta Spring Integration . . . . . . . . . . . . . . . . . 613.5 Vocabulario de la herramienta BizTalk 2006 . . . . . . . . . . . . . . . . . . . . . . 69

4.1 Iconos de las tareas routers en Guaraná . . . . . . . . . . . . . . . . . . . . . . . . . 974.2 Iconos de las tareas transformadoras en Guaraná . . . . . . . . . . . . . . . . . 984.3 Iconos de las tareas constructoras en Guaraná . . . . . . . . . . . . . . . . . . . . 99

VIII Índice de tablas

Agradecimientos

Todo el gran proyecto tiene una determinada fecha en la que se coloca laprimera piedra. Por lo tanto, puedo decir que en el día 06/09/2006 se colocó laprimera piedra de mi proyecto de doctorado, todavía en marcha. En este día,hice un contacto con el profesor Dr. José Miguel Toro Bonilla, el que pronta-mente me puso en contacto con la persona encargada. Esto desencadenó unaserie de interacciones con el profesor Dr. Rafael Corchuelo, el que propulsóeste proyecto. De entonces, no podría olvidar expresar mi gratitud a estos dosprofesores, que desde el “Viejo Mundo” han colaborado a hacer posible unsueño en el “Nuevo Mundo”. De forma especial, me gustaría expresar misagradecimientos al profesor Dr. Rafael Corchuelo, hoy mi tutor, por todo elsoporte que me ha dado en el periodo de investigación.

Todo proyecto demanda un patrocinador. Por esto, de igual forma, expresomis reconocimientos al Evangelischer Entwicklungsdienst e.V. (EED) por laconcesión de la beca de doctorado.

X Agradecimientos

Resumen

El área de la integración está cobrando una gran importancia en el contextode los ecosistemas software actuales y de la alta inversión que requieren pararesolver los problemas de integración. Son varios los enfoques que se dan a laintegración. El primero, el Mashup, está enfocado en proporcionar la creaciónde una nueva aplicación por medio de la composición de servicios (llama-dos también Mashups); EAI enfoca la integración de aplicaciones dentro de lamisma empresa, con el objetivo de mantener las aplicaciones funcionando ensincronía y de forma exógena poder integrar sus funcionalidades; B2BI tieneun propósito muy parecido al anterior, pero con la diferencia que las aplica-ciones pertenecen a empresas distintas, lo que añade nuevos aspectos que hayque tener en cuenta a la hora de diseñar la solución de integración; EII enfocala integración de diversas fuentes de datos, de forma que un conjunto de apli-caciones puedan colaborar para ofrecer una vista homogénea y en vivo de losdatos; finalmente, ETL cuyo objetivo es extraer datos de fuentes distintas, pro-cesar las transformaciones que se hacen necesarias para almacenarlos en otrabase de datos y entonces permitir la ejecución de operaciones de lectura sobrelos datos, ofreciendo por medio de esta nueva base una vista homogénea perooffline de los datos.

Las herramientas actuales tienen problemas de alcance y aun no son ca-paces de responder de forma deseable a los problemas planteados por la in-tegración. Al término de la investigación llevada a cabo, creemos que es po-sible construir una herramienta para EAI que tenga un alcance más amplioque las actuales, y, que por lo tanto, permita diseñar soluciones más directasy sencillas con una menor inversión. En esta memoria describimos nuestrapropuesta, denominada Guaraná, para diseñar soluciones de integración deaplicaciones. Con el propósito de tener una primera validación hemos realiza-do dos proyectos de diseño de soluciones, en colaboración con empresas, pararesolver problemas de integración de aplicaciones.

En esta memoria también presentamos un resumen de nuestras contribu-ciones que hemos podido aportar hasta el momento, algunas de ellas ya pu-blicadas y otras en proceso de revisión.

XII Resumen

Parte I

Prefacio

Capítulo 1

Introducción

L os ecosistemas software actuales demandan una gran inversión a la ho-ra de diseñar soluciones de integración. Las herramientas actuales aun

no son capaces de responder de una forma deseable a este problema. En laSección §1.1 describimos el contexto de integración en el que nos movemos;en la Sección §1.2, presentamos el propósito de nuestra investigación, y pa-ra esto comentamos nuestra hipótesis, tesis y las primeras validaciones quehemos hecho; finalmente, en la Sección §1.3, presentamos un resumen de lascontribuciones que hemos aportado, hasta el momento, al área de integraciónde aplicaciones.

4 Capítulo 1. Introducción

1.1. Contexto de investigación

En las empresas actuales es muy habitual que convivan aplicaciones quehan sido adquiridas o desarrolladas conforme dichas empresas han evolucio-nado y han ido descubriendo nuevos requisitos, dando lugar a ecosistemassoftware que no siempre son fáciles de gestionar [21]. Un problema frecuenteen estos ecosistemas es integrar dos o más aplicaciones de forma que los datosque manejan por separado estén sincronizados o que puedan colaborar paraofrecer nueva funcionalidad o nuevas vistas de datos [17]. Según un recienteinforme de IBM los gastos de integración superan en una proporción de en-tre cinco y veinte a los de desarrollo de nueva funcionalidad [32]. No es deextrañar, por lo tanto, la enorme popularidad que las herramientas para cons-truir buses de servicios empresariales (ESBs) están ganando en este contexto,ya que ofrecen la infraestructura necesaria para integrar los sistemas más dis-pares [4].

El principal objetivo de una solución de integración es mantener las aplica-ciones que forman parte de la solución sincronizadas, aportar nuevas funcio-nalidades y vistas de datos. Dicha solución debe ofrecer al usuario una vistade más alto nivel con la que se puede interactuar, como si fuera una nueva yúnica aplicación. Es decir, la solución de integración permite crear nuevas apli-caciones en forma de funcionalidades o también en forma de vistas de datosque pueden proporcionar información de las aplicaciones integradas.

En esta área, además del reto de integrar aplicaciones que han sido desa-rrolladas por separado sin tener en cuenta la integración, hay que tener encuenta otros aspectos más específicos que se hacen importantes. Primero, lastecnologías en las que están desarrolladas las aplicaciones pueden ser muy di-ferentes, como, e.g., una aplicación hecha en Cobol/CSP que se ejecuta en unmainframe IBM S390 y otra hecha en Visual Basic .NET que se ejecuta en unamaquina Windows Vista. Dicho entorno tecnológico puede, en algunos casos,hacer más difícil la integración. Otro aspecto importante esta relacionado conel modelo de datos de las aplicaciones involucradas en una solución, pues-to que pueden tener modelos muy distintos sobre el mismo concepto, o aun,modelos muy distintos de dominios también muy diferentes, lo que puede di-ficultar el diseño de una solución. La comunicación con una aplicación, en elmundo de la integración, se hace por medio de una o más de sus capas, e.g.,base de datos, interfaz gráfica de usuario, lógica de negocio, etcétera. Aunquese pueda estar integrando aplicaciones del mismo dominio, dichas capas pue-den hacerse muy diferentes por las características expuestas anteriormente, yofrecer acceso a funcionalidades semánticamente equivalente, pero por mediode interfaces diferentes. Por lo tanto, esto nos permite ver que el hecho de in-tegrar aplicaciones puede involucrar una cantidad mucho mayor de aspectos

1.1. Contexto de investigación 5

de lo que podría parecer en un primer momento.

Al hablar de integración, hay que tener en cuenta algunas restricciones pa-ra que una solución de integración sea viable para las empresas. La primerarestricción es que después de hacer la integración, las aplicaciones involucra-das no deben cambiar. Un cambio en una de estas aplicaciones podrá afectarprofundamente o hasta invalidar totalmente otras soluciones de integración,o incluso, los procesos de negocio que soportan esas aplicaciones. La siguienterestricción es que, después de integradas, las aplicaciones deben mantenersedesacopladas las una de las otras como antes de la integración. La soluciónde integración no debe cambiar las aplicaciones involucradas generando de-pendencias en ellas que antes no existían. Finalmente, podemos añadir unatercera restricción según la cual la integración no debe ser hecha como partedel proceso de desarrollo de sistemas, sino conforme sea necesario.

La ingeniería informática debe proporcionar el soporte para, entre otrascosas, diseñar, implementar y gestionar soluciones de integración, de formaque las dificultades y costes sean reducidos al máximo. Dicho soporte inge-nieril debe englobar aspectos como, e.g., un lenguaje específico de dominio(DSL) con el que se puede realizar un modelo conceptual del problema deintegración que se pretende resolver. Además, debe aportar herramientas es-pecíficas para el área de integración, que permitan desde un nivel más altode abstracción, hacer uso de tecnologías de más bajo nivel, como, e.g., biblio-tecas de código para la comunicación, encriptación, autenticación, etcétera.Al igual deben dar soporte al uso del lenguaje DSL y permitir gestionar losproyectos diseñados en la herramienta. Aunque estos aspectos técnicos seanimportantes, también hay que tener en cuenta la necesidad de adopción debuenas prácticas enfocadas en la area de integración y metodologías que pue-dan servir cómo guía en el trabajo. Por ser el área de integración muy nueva,todavía hacen falta algunos de estos soportes.

La solución de integración puede estar fundada en una integración en ellado servidor o en el lado cliente, integración de funcionalidades o informa-ción. La integración que se puede hacer en el lado cliente es el más recientetipo de integración que se puede encontrar y se llama Mashup. Por otro ladolos tipos de integración que se pueden hacer en el lado servidor son varios, asaber: Enterprise Application Integration (EAI), Business to Business Integra-tion (B2BI), Enterprise Information Integration (EII) y Extract, Transform andLoad (ETL).

La tecnología de Mashup permite crear una nueva aplicación por mediode la composición de servicios (llamados también Mashups). Esta aplicaciónse ejecuta dentro del navegador del cliente y es responsable de orquestar Mas-hups. Los Mashups están enfocados en la integración de información, desde


una o más fuentes de datos. Diversas empresas en la web ofrecen herramientaspara diseñar este tipo de solución de integración. Por ejemplo, Google propor-ciona un editor llamado Mashup Editor en http://www.googlemashups.com,Microsoft proporciona Popfly en http://www.popfly.com y Yahoo proporcionaPipes en http://pipes.yahoo.com/pipes. Además, las empresas que ofrecen so-porte a esta tecnología, también, ofrecen por medio de una comunidad deusuarios, un conjunto de Mashups ya listos que uno puede incorporar a susolución.

Las soluciones de integración cuyo objetivo es mantener un conjunto deaplicaciones en sincronía, aportar nuevas funcionalidades y que se ejecutanen el lado del servidor, son las EAI. Este tipo de solución suele conectar doso más aplicaciones por medio de un flujo exógeno de datos y/o comandos,capaz de integrar funcionalidades de las aplicaciones involucradas sin que lasaplicaciones conozcan la solución. Es decir, una solución EAI aporta de formaexógena funcionalidad de una aplicación a la otra, o incluso, nuevas funciona-lidades, además de mantener las aplicaciones independientes una de las otrasy coordinarlas. Una característica importante en este tipo de solución de in-tegración, es que se considera que las aplicaciones que se están integrandopertenecen a la misma empresa.

Business to Business Integration (B2BI) representa un tipo de solución deintegración muy parecida a las soluciones EAI. La diferencia entre EAI y B2BIestá tan sólo en si se integran aplicaciones que son de una misma empresa(EAI) o de empresas distintas (B2BI). Aunque la diferencia se parezca peque-ña, los escenarios para dichos tipos de integración son muy diferentes, pues enB2BI hay aspectos que son mucho más críticos e importantes que en el contex-to de EAI. El primer aspecto se relaciona con el tema de la seguridad, puestoque el acceso a las aplicaciones de una empresa no queda abierto y libre. Hayque tener autorización y permisión para accederlas, y, por lo tanto, la soluciónde integración tiene que ser capaz de tratar esto. La autenticación, que en EAIsuele ser local, en B2BI puede requerir recurrir a servicios externos, pues esnecesario saber, e.g., si un usuario en una organización tiene o no acceso a unrecurso de otra organización. Otro aspecto muy importante es la fiabilidad dela infraestructura de mensajería que se utiliza, debido a que es mucho másprobable que falle en una solución B2BI que en EAI. Además en B2BI puedehaber la necesidad de certificar las transacciones con un notario electrónico,por otro lado en EAI todo está dentro de la misma empresa y no es necesariala presencia de un notario, pero en B2BI puede ser necesaria para dar fe de queuna transacción ha tenido lugar. Finalmente, se suele hacer uso de estándaresen B2BI, como, e.g., para el intercambio de datos como OBI (Open Buyingon the Internet) o EDI (Electronic Document Interchange), cXML (CommerceXML). Se han pensado dichos estándares para un entorno inter-organizacional

http://www.googlemashups.com

http://www.popfly.com

http://pipes.yahoo.com/pipes

1.1. Contexto de investigación 7

y no un entorno intra-organizacional cómo es el caso de EAI. Por lo tanto, sepuede decir que una solución B2BI necesita una infraestructura de integraciónmás completa que permita tratar estos aspectos.

Las soluciones de integración de tipo EII están enfocadas, exclusivamente,a la integración de información de diversas fuentes de datos. Dichas fuentesde datos suelen ser bases de datos, aunque cualquier canal que la aplicaciónutilice para escribir mensajes, e.g., también se considera una fuente de datos,ficheros o incluso la interfaz de usuario. Una solución EII debe proporcionarsoporte para que un conjunto de aplicaciones puedan colaborar y ofrecer unavista homogénea y en vivo de los datos que pertenecen a dichas aplicacionesintegradas. Sobre esta vista, el usuario podrá ejecutar operaciones con un len-guaje de alto nivel que le permita consultar y/o insertar datos en las diversasfuentes de una forma transparente. Una diferencia importante con relación aEAI, es que en EII no hay flujos de datos conectando aplicaciones con el ob-jetivo de mantenerlas sincronizadas, sino que flujos de datos de las fuentesque convergen en las vistas de la solución. Dichas vistas pueden simplementereflejar otras vistas ya existentes de las fuentes de datos o representar nuevasvistas de datos aportadas por la solución EII. Al igual que EAI e B2BI, este tipode solución se ejecuta en el lado servidor.

Extract Transform and Load (ETL) es otro tipo de solución de integraciónque se ejecuta en el lado servidor y cuyo objetivo, también, es la integración deinformación. La diferencia que hay entre ETL y EII está en que, mientras EIIproporciona una vista homogénea y en vivo de diferentes fuentes de dados,ETL tiene como objetivo proporcionar una vista homogénea y offline. Es decir,una solución ETL debe permitir extraer datos de fuentes distintas, procesarlas transformaciones que se hacen necesarias para almacenarlos en otra basede datos, en la que se puede ejecutar operaciones de lectura sobre los datos.Las operaciones que se suelen ejecutar son operaciones que pueden deman-dar mucho recursos de la maquina en la que está la información, por lo quese hace en una base de datos nueva y no en vivo como en EII. A dichas basesde datos se suelen llamar data warehouses o data marts. Mientras en un datawarehouse representa un conjunto de datos con información sobre toda la em-presa, los data marts suelen representar un almacén de datos más centrado enalgún aspecto especifico de la empresa, como, e.g., los clientes. No es objetivode esta memoria entrar en detalles sobre los conceptos de data warehouse ydata marts, así que no vamos profundizar en estos temas.

Como hemos podido ver hay varios tipos de soluciones de integración, ca-da uno de ellos con sus aspectos particulares. Nuestro trabajo de investigaciónestá centrado en las soluciones de integración de aplicaciones, así que tambiénvamos a centrar esta memoria en este tema.


1.2. Propósito de esta investigación

En esta sección demostramos la hipótesis que ha motivado nuestro trabajode investigación en el contexto de la integración. También presentamos la tesisque pretendemos defender y como queremos validar nuestra propuesta final.

1.2.1. Hipótesis

La integración de aplicaciones requiere una gran inversión en los ecosiste-mas software actuales. Las herramientas de EAI tienen problemas de alcancedebido a que sus características hacen inviable el diseño de algunas solucio-nes de integración; en otros casos, sus capacidades de modelado pueden darlugar a soluciones más artificiales y complejas de lo que sería deseable y porlo tanto más difíciles de mantener; también, se han identificado algunas defi-ciencias desde el punto de vista técnico que pueden resultar molestas para losprogramadores y administradores de sistemas.

1.2.2. Tesis

Es posible construir una herramienta para EAI con un alcance más amplioque las actuales y que permitan diseñar soluciones más directas y sencillas,así como características técnicas que faciliten el trabajo de los programadoresy administradores de sistemas, todo ello con el objetivo de producir solucionesde integración que requieren una menor inversión.

1.2.3. Validación

Se ha realizado una prospección participando en dos proyectos, uno re-lacionado con un sistema de gestión de llamadas de la Universidad de Ijuí(UNIJUÍ), y otro relacionado con un sistema de asesoramiento laboral de laempresa Indisys, S.L. Estos dos proyectos nos han permitido profundizar enEAI, avanzar en el diseño de nuestra propuesta y tener un primer contacto consu validación en casos reales. Se está en negociaciones con la empresa Sytia In-formática, S.L. para diseñar un sistema de integración en el entorno sanitario.Este proyecto nos permitirá seguir profundizando y validando nuestra pro-puesta en el contexto B2BI.

1.3. Resumen de contribuciones 9

En el futuro colaboraremos con alguna empresa para comparar el esfuerzode desarrollo de alguno de sus proyectos de integración con y sin nuestra pro-puesta. Los resultados nos permitirán obtener conclusiones sobre su alcance,capacidades de modelado y características técnicas, así como validar o refutarnuestra tesis.

1.3. Resumen de contribuciones

El estudio de algunas de las principales herramientas de EAI nos permi-tió diseñar un framework de comparación, el que puede ayudar una empresaa la hora de evaluar y escoger una herramienta de integración. Durante es-te trabajo, también hemos producido una documentación técnica sobre variosaspectos relevantes de la arquitectura de estas herramientas, el que puede ser-vir de base para estudiarlas. Todo esto nos ayudó a esbozar un metamodeloque proporciona un lenguaje específico de dominio para diseñar solucionesde integración de aplicaciones.

Los resultados de los trabajos anteriores han dado lugar a las siguientespublicaciones:

En [12] esbozamos los fundamentos de una herramienta para diseño desoluciones de integración. Para esto, proponemos una división de la so-lución en niveles y vistas que pueden facilitar el diseño, además de pre-sentar algunos de los building blocks fundamentales para tal actividad.

En [11] presentamos nuestra propuesta de un lenguaje específico de do-minio para diseñar soluciones de integración de aplicaciones. Hacemosuna primera comparación de nuestra propuesta con una de las herra-mientas actuales más referenciadas en el área de EAI y que implementalos patrones de integración [17].

El artículo [3] ha sido enviado a las JISBD’08 y en él presentamos unframework de comparación para herramientas de integración. Propone-mos un conjunto de propiedades, agrupadas en tres grupos distintos,que pueden ayudar a la hora de evaluar y escoger una herramienta parael diseño de soluciones de integración.

El artículo [13] ha sido enviado a las JISBD’08 y en él profundizamos ladiscusión de nuestro lenguaje DSL para la integración de aplicaciones.Para esto presentamos dos ejemplos de casos reales, en los que hemosutilizado el DSL para diseñar dos soluciones de integración. Además,


presentamos una comparativa de nuestro DSL con otras tres herramien-tas actuales, basada en el framework de comparación que hemos creado.

1.4. Estructura de la memoria

Esta memoria está organizada de la siguiente forma:

Parte I: Prefacio En esta parte, además de la introducción a nuestro trabajo,presentamos en el Capítulo §2 un estudio que nos ha servido de motiva-ción para el desarrollo de esta memoria.

Parte II: Revisión de propuestas La segunda parte de la memoria, está for-mada por el Capítulo §3, y se dedica al estudio de cinco herramientasmuy conocidas en el mundo de la integración. En este capítulo, explora-mos los aspectos arquitectónicos que juzgamos ser de más relevancia, eneste momento, para nuestra investigación.

Parte III: Nuestra propuesta Esta parte está formada por el Capítulo §4, en elque describimos nuestra propuesta, denominada Guaraná, para el dise-ño de soluciones de integración de aplicaciones. Además, presentamospor medio de un ejemplo un de diseño de una solución para resolver unproblema real de integración.

Parte IV: Consideraciones finales En esta parte, con el Capítulo §5, presenta-mos nuestras conclusiones del trabajo que hemos desarrollado hasta elmomento.

Parte V: Apéndices Los grados de terminación y sus características de cadanivel, se presentan en el Apéndice §A; luego en el Apéndice §B se pre-sentan los grados de calidad. Se utilizan estos dos grados a la hora decalificar las herramientas estudiadas en la revisión de propuestas.

Capítulo 2

Motivación

E n los días de hoy, podemos encontrar una gran cantidad de herra-mientas enfocadas en el área de integración de aplicaciones. Desafor-

tunadamente, dichas herramientas suelen tener deficiencias importantes quepueden traer dificultades, o incluso, invalidar un proyecto de integración. Eneste capítulo presentamos un estudio de un conjunto de propiedades esencia-les que hay que analizar a la hora de tomar una decisión sobre que herramien-ta usar, y, que nos ha motivado a investigar más en esta área. Para esto, enla Sección §2.1, presentamos una introducción al estudio; en la Sección §2.2,presentamos el conjunto de propiedades agrupadas en tres categorías distin-tas, relacionadas con el alcance, el modelado y los aspectos técnicos de unproyecto de integración; finalmente, en la Sección §2.3, discutimos los valoresdeseables e ideales para cada una de estas propiedades.

12 Capítulo 2. Motivación

2.1. Introducción

En nuestra revisión de la tecnología, hemos estudiado las siguientes pro-puestas: Camel [7], Mule [5], ServiceMix [2], Spring Integration [28] y Biz-Talk [34]. Las hemos elegido puesto que actualmente son de las más popula-res y, además, en el caso de ServiceMix, al estar basada en JBI [2] podemosconsiderarla como el representante canónico de todos los ESBs que también loimplementan, e.g., OpenESB, Fuse ESB o JBoss ESB. En mayor o menor grado,todas permiten implementar soluciones de integración basadas en el patrónarquitectónico Pipes and Filters [9]. Siguiendo este patrón, una solución de in-tegración se puede ver como el diseño de un conjunto de mensajes que fluyena través de tuberías entre diversos filtros. En esta memoria nos referimos a lospipes/tuberias como canales de comunicación, y a los filters como buildingblocks. Qué es un mensaje, un building block o un canal depende por com-pleto de la infraestructura elegida y del problema a resolver. Por ejemplo, unmensaje puede ser desde un documento XML hasta un objeto Java serializa-do; un building block puede ser desde un objeto COM que realiza una trans-formación de mensajes sencilla hasta un servicio web que interactua con unaaplicación de negocio; un canal puede ser desde un conjunto de objetos lecto-res y/o escritores para acceder a un sistema de archivos local hasta un canalde comunicación SOAP/HTTP. Esta gran flexibilidad es la que hace que lasherramientas para construir ESBs sean la opción habitual para implementarsoluciones de integración en ecosistemas software muy heterogéneos.

2.2. Problemas

El estudio llevado a cabo nos permitió identificar un conjunto de propieda-des que hay que tener en cuenta a la hora de escoger o diseñar una herramien-ta para la integración. Al igual, nos fue útil para identificar algunos puntosdébiles en las propuestas de tecnologías actuales. Hemos clasificado y agru-pado estas propiedades en tres categorías distintas que nos permiten hacerun paralelo a los perfiles profesionales jefe de proyecto, arquitecto software yprogramador. A continuación, presentamos cada una de ellas.

2.2.1. Alcance de las herramientas

La primera categoría de propiedades que hemos identificado está relacio-nada con el alcance de las herramientas, y suele servir de base para la toma

2.2. Problemas 13

Propiedad Camel Mule ServiceMix Spring Int. BizTalk

Contexto EAI EAI EAI EAI EAI/B2BI

Patrónarquitectónico Filters Pipes/Filters† Pipes/Filters† Filters Pipes/Filters

Nivel PSM PSM PSM PSM PSM

Transacciones ST-B ST-B ST-B/ST-S – ST-B/LT-B

RoutingSlipdinámico No No No No No

Extensiones No No No No Sí

Adaptadoresde aplicación No No No No Sí

Tipo demodelo O/D-IoC O/D-IoC O/D-IoC O/D-IoC D-Gráf. y XML

Licencia L-A L-BL L-A L-A L-P† Tan sólo ofrecen soporte parcial para el diseño de filtros (building blocks).

Tabla 2.1: Propiedades relacionadas con el alcance de las herramientas.

de decisiones de los jefes de proyecto. Se tratan de propiedades cuya ausen-cia puede dificultar enormemente e incluso invalidar una propuesta ya quepara suplirlas es necesario implementar extensiones cuyo coste de desarrollocreemos que puede ser inabordable en la mayoría de los casos. Entre las másimportantes, destacamos las siguientes, cf. Tabla §2.1:

Contexto: Suele ser habitual distinguir entre los siguientes contextos de in-tegración: Enterprise Application Integration (EAI), en donde el énfasises integrar aplicaciones con el objetivo de sincronizar sus datos o de im-plementar nuevas funcionalidades; Enterprise Information Integration(EII), cuyo énfasis están en proporcionar una vista en vivo de los datosque manejan las aplicaciones integradas; Extract, Transform, and Load(ETL), que busca proporcionar vistas materializadas de dichos datos so-bre la que aplicar técnicas extracción de conocimiento [33]. En todos loscasos anteriores, se asume implícitamente que las aplicaciones integra-das forman parte de una misma organización. Recientemente cada vezse le está prestando más atención al problema de integrar aplicacionespertenecientes a distintas organizaciones con el objeto de implementarprocesos de negocio inter-organizacionales; a este contexto se suele ha-cer referencia como Business to Business Integration (B2BI). También re-cientemente, han cobrado importancia los denominados mashups, queson aplicaciones que se ejecutan en un navegador web e integran da-tos proporcionados por diversas aplicaciones web. De nuestro análisisse desprende que casi todas las soluciones estudiadas se encuentran en


el contexto de EAI, con la única excepción de BizTalk, que también tieneen cuenta el contexto B2BI.

Patrón arquitectónico: Como ya sabemos, Pipes and Filters es el patrón porexcelencia en nuestro campo de interés. Por lo tanto, parece razonableesperar que las herramientas para la construcción de ESBs proporcionenlenguajes específicos de dominio para diseñar tanto tuberías (canales)como filtros (building block). Por desgracia, no es así ya que Camel ySpring Integration no proporcionan soporte alguno para el diseño detuberías y Mule y ServiceMix tan sólo proporcionan un soporte parcialpara el diseño de filtros. En el caso de Mule, este soporte se reduce aunas cuantas tareas de transformación o enrutado de mensajes que sedeben combinar siempre de forma lineal; en el caso de ServiceMix, laherramienta, como tal, no ofrece ninguna ayuda para construir los filtros,pero existe un componente JBI que proporciona la implementación dealgunas tareas comunes. En los dos casos, es muy habitual que el núcleode los filtros se diseñe directamente en Java debido a las limitaciones delas herramientas.

Nivel de abstracción: Trabajar con modelos independientes de la plataforma(PIM) permite diseñar soluciones estables tan independientes como re-sulta posible de la tecnología utilizada para implementarlas y su inevi-table evolución. Al trabajar con modelos PIM es necesario contar, ade-más, con herramientas capaces de transformarlos en modelos depen-dientes de la plataforma sobre la que se quiere realizar la implementa-ción (PSM) [20]. Por desgracia, ninguna de las herramientas estudiadaspermite realizar una separación clara entre los niveles PIM y PSM dadoque todas obligan al diseñador a trabajar directamente sobre las plata-formas Java o .NET.

Transacciones: Las transacciones permiten diseñar soluciones robustas capa-ces de hacer frente a fallos que puedan ocurrir durante la ejecución deuna solución de integración. Es habitual distinguir entre transacciones acorto plazo (ST) o a largo plazo (LT): las primeras suelen implementar-se usando el conocido protocolo Two-Phase Commit que, básicamente,consiste en llevar a cabo aquellas acciones que requieren cambios de es-tado tan sólo cuando todas las partes implicadas han confirmado quepueden llevarlas a cabo sin problema [26]; las segundas, por el contrario,ejecutan las acciones necesarias conforme sea posible y, en caso de quealguna falle, ejecutan a continuación acciones de compensación cuyo ob-jetivo es deshacer los efectos de las primeras o, en caso de que esto nosea posible, paliarlos [15, 25]. En el contexto de la integración de apli-caciones, también resulta útil clasificar las transacciones en función a sualcance, según lo cuál se distingue entre transacciones de building block

2.2. Problemas 15

(B) o de solución (S): las primeras son aquéllas que garantizan que unbuilding block logra ejecutar su tarea o de lo contrario cualquier cambioque haya podido realizar hasta el momento de detectar un fallo que-da invalidado; las segundas son aquéllas que garantizan esta propiedaddesde el punto de una solución completa. Casi todas las herramientassoportan transacciones a corto plazo, con la excepción de BizTalk quetambién soporta transacciones a largo plazo y de Spring Integration queno proporciona ningún soporte propio; con la excepción de Camel, todassoportan transacciones tanto a nivel de building block como de solución,pero, por desgracia, ninguna soporta transacciones a largo plazo a nivelde solución.

RoutingSlip dinámico: El patrón RoutingSlip permite enrutar un mensaje através de una secuencia de building blocks que no son conocidos a prio-ri [17]. Para conseguirlo se puede hacer que los mensajes incluyan en sucabecera la lista de building blocks o que esta información esté en algúnfichero de configuración. Gracias a esto es posible definir una ruta paralos mensajes después de haber diseñado la solución de integración. Laposibilidad de cambiar dinamicamente dicha lista durante la ejecuciónde un building block en la solución, para, e.g., en función de un determi-nado resultado añadir o quitar un building block, hace que este patrónsea de gran utilidad práctica. Por desgracia, entre las herramientas es-tudiadas apenas Camel a partir de la versión 1.3 y ServiceMix soportanel patrón RoutingSlip, pero todavía, ninguno de ellos permiten cambiarde forma dinámica la lista de building blocks, que debe ser asignada enel mismo momento en que se crea cada mensaje y se mantiene intactadurante todo el procesamiento que éste deba sufrir.

Extensiones: Las extensiones proporcionadas por las herramientas aportantareas específicas para un determinado dominio de negocio. Suelen darsoporte a estándares definidos para dichos dominios y facilitan muchoel diseño de una solución de integración dentro de los mismos. El hechode no haber disponible una extensión para un dominio puede resultardemasiado costoso para una empresa a la hora de crear una solución deintegración para su problema. Por desgracia, sólo BizTalk ofrece exten-siones para el área de la salud, el comercio electrónico, las finanzas y lascadenas de aprovisionamiento.

Adaptadores de aplicación: Los adaptadores de aplicación permiten conec-tar sistemas grandes enteros a una solución de integración. Esto permiteuna comunicación de más alto nivel entre la solución y la aplicación a finde intercambiar información. Un ejemplo claro es el adaptador de aplica-ción ofrecido por la empresa iWay [18] para usar el ERP Peoplesoft desdedentro de BizTalk. Creemos que el coste de desarrollo de estos tipos de


adaptadores, para una empresa que va a diseñar una solución de integra-ción, puede resultar prohibitivo, además de que, en muchos casos, no setiene el conocimiento necesario sobre la tecnología para la que hay quediseñar el adaptador. Por desgracia, entre las herramientas estudiadas,sólo hemos encontrado adaptadores de aplicación para BizTalk.

Tipo de modelo: De acuerdo con el tipo de modelo de la herramienta, se per-mite diseñar las soluciones de integración de forma operativa (O) o de-clarativa (D). Cuando el diseño es operativo, la herramienta proporcionauna biblioteca de clases que los programadores pueden combinar paracrear sus soluciones de integración; por el contrario, cuando es decla-rativo el programador puede trabajar a un nivel de abstracción muchomás alto. La primera forma es usando un lenguaje específico de dominiocon representación en XML o gráfica que después será traducido auto-máticamente a código ejecutable; la segunda es por medio de ficheros deconfiguración XML que después serán interpretados por un motor de In-version of Control (IoC) [10], e.g., Spring [31]. Desde este punto de vista,Camel, Mule, ServiceMix y Spring Integration soportan tanto modelosoperativos como declarativos mediante inversión de control; BizTalk esla única herramienta que ofrece un modelo declarativo tanto basado enXML como gráfico.

Licencia: El tipo de licencia de una herramienta puede invalidar su adopciónen una empresa por cuestiones políticas o económicas. Para esta pro-piedad, hemos clasificado las licencias en: licencias Apache (L-A), otraslicencias basadas en licencias libres (L-BL) y licencias propietarias (L-P).

2.2.2. Capacidades de modelado

La categoría de modelado representa propiedades que no son tan críticascomo las anteriores, y están relacionadas con el trabajo de los arquitectos soft-ware. La razón es que en caso de carecer de ellas aún es posible diseñar unasolución de integración efectiva con un coste razonable, pero quizás el dise-ño sea mucho más complejo y menos intuitivo, lo que puede tener, eviden-temente, un efecto negativo sobre el mantenimiento posterior. Entre las másimportantes, destacamos las siguientes, cf. Tabla §2.2:

Vistas: En una solución de integración, es posible distinguir las siguientes vis-tas: wrapper, que es la vista que muestra aquellos building blocks cuyoobjetivo es comunicar una aplicación con una solución de integración oal revés; proceso, que incluye aquellos building blocks que implemen-tan un proceso de negocio en la solución de integración; aplicación, que

2.2. Problemas 17


Vistas – – –Wrapper/Proceso/Solución†1

–

Card. building blocks 1 : N 1 : N 1 : N 1 : N N : M

Card. tareas 1 : N 1 : 1†2 –†3 1 : N 1 : 1

Card. localidades N : M-Comp

N : M-Comp

N : M-Comp

N : M-Comp 1 : 1

Correlación No No No No Sí

Tipos de puertos PD PD PD/ PM†4 PD PD/ PM4

Adaptadores en puertos 1:1 1:1 1:1 1:1 N:1

Puertos bidireccionales No No Sí No Sí

Pipeline en puertos No Sí†4 No Sí†4 Sí

Building block con estado No No No No No

Tareas con estado Sí Sí Sí Sí No

Diseño de tareas No No No No Sí†1 Aunque no incluya la vista de aplicación y nube.

†2 Salvo en el flujo de salida, en el que pueden haber tareas con 1 : N.†3 Las tareas son proporcionadas por un componente externo.

†4 Con limitaciones importantes.

Tabla 2.2: Propiedades relacionadas con las capacidades de modelado.

documenta por medio de un decorador cuáles son las aplicaciones inte-gradas; nube, que presenta los flujos de integración necesarios entre unconjunto de procesos para integrar varias aplicaciones, además de losflujos de entrada/salida para comunicación con los wrappers; solución,que es la más general puesto que presenta en una sólo vista todas las vis-tas anteriores. Por desgracia, ni Camel, ni Mule, ni ServiceMix, ni BizTalkofrecen la posibilidad de modelar ninguna de estas vistas, por lo que unbuilding block puede acabar implementando un wrapper, un proceso ouna solución completa, sin que sea posible documentar esto de forma ex-plícita en los modelos resultantes. Spring Integration es la más completade la estudiadas ya que distingue entre las vistas de wrapper, proceso ysolución, aunque la vista de solución no incluye la vista de aplicación ynube.

Cardinalidad de los building blocks: Algunos building blocks pueden re-querir mensajes de distintas fuentes para poder desempeñar su labor.Un situación común se presenta cuando es preciso tratar las distintaspartes de un mensaje utilizando building blocks diferentes y posterior-mente combinar los resultados. Por desgracia, tan sólo BizTalk permite


diseñar building blocks capaces de tomar información de varias fuen-tes. Por el contrario, todas las herramientas analizadas permiten que unbuilding block envíe información a varios canales de salida simultánea-mente. En este punto es interesante destacar que gracias a herramientascomo los motores de BPEL es posible diseñar building blocks capacesde tomar información de varias fuentes de una forma razonablementesimple. Usando una herramienta de este tipo sería, por lo tanto, posible,suplir las carencias de las herramientas analizadas, aunque a costa deintroducir un nuevo lenguaje en el proceso de modelado.

Cardinalidad de las tareas: Los building blocks están formados por tareasmás simples que permiten construir mensajes, transformarlos, enrutar-los o interactuar con los canales. En nuestra experiencia, es habitual quealgunas tareas necesiten información contextual proveniente de algunaaplicación para poder tratar los mensajes que le llegan; un ejemplo cla-ro es cuando los mensajes procesados incluyen algún identificador y espreciso consultar a una aplicación qué datos corresponden al mismo. Pordesgracia, ninguna de las tecnologías examinadas permite tareas con va-rias entradas, mientras que Camel y Spring Integration sí que permitentareas con varias salidas. El caso de ServiceMix es un poco especial pues,como comentamos antes, las tareas son proporcionadas por un compo-nente JBI externo; en cualquier caso, este componente tan sólo permitetareas con una entrada aunque pueden tener varias salidas.

Cardinalidad de las localidades: El término localidad hace referencia a laubicación física sobre la que se implementa un canal, e.g., una carpetaen un sistema de archivos o un servidor de correo electrónico. Con laexcepción de BizTalk, todas las soluciones estudiadas permiten que va-rios building blocks lean o escriban mensajes desde/en una localidadcompartida. Generalmente es interesante distinguir entre dos tipos delectura: con competencia (Comp), en cuyo caso tan sólo uno de los buil-ding blocks puede leer en cada momento de una determinada localidad,o con replicación (Repl), en cuyo caso todos los building blocks puedenleer al mismo tiempo. Todas las soluciones implementadas permiten lec-tura con competencia, pero ninguna la lectura con replicación.

Correlación de mensajes: Dado que no podemos asumir sincronía alguna en-tre las aplicaciones integradas, es muy común que los mensajes lleguena los building blocks de forma desordenada, por lo que es responsabi-lidad de los mismos correlacionarlos de forma que aquellos mensajesque son complementarios sean tratados siempre de forma conjunta. Estanecesidad es mucho más imperiosa en aquellos casos en que es posiblediseñar building blocks o tareas con múltiples entradas, por lo que no es

2.2. Problemas 19

de extrañar que tan sólo BizTalk soporte directamente la correlación demensajes.

Tipos de puertos: Una solución de integración puede tener dos tipos de puer-tos, a saber: puertos de datos (PD) y puertos de mensajes (PM). Los puer-tos primeros se encargan de conectar una aplicación con un wrapper através de una localidad; los datos que fluyen por estos puertos perte-necen a la aplicación que los produce o los consume. Los puertos demensaje, por el contrario, son aquellos que forman parte exclusiva de lassoluciones de integración y los datos que fluyen por ellos tienen un for-mato de mensaje bien definido, es decir, incluyen cabeceras y posiblesadjuntos además de los datos en sí. Un ejemplo claro de información decabecera es el tipo del mensaje, la dirección de retorno, la lista de buil-ding blocks por los que debe pasar en caso de soportar el patrón Rou-tingSlip [17], el identificador de secuencia, etcétera. Al permitir que doso más building blocks se puedan comunicar mediante puertos de men-sajes se consigue que toda esta información extra fluya de forma naturalentre los mismos, lo que, entre otras cosas, facilita la trazabilidad. Pordesgracia, sólo ServiceMix y BizTalk ofrecen puertos de mensaje, aun-que con limitaciones dado que en el primer caso sólo pueden conectar abuilding blocks que se encuentran dentro de la misma máquina y en elsegundo caso sólo permiten comunicación síncrona entre los mismos.

Adaptadores en puertos: La posibilidad de que un puerto tenga múltiplesadaptadores le permite recibir/enviar información desde/a dos o máslocalidades. La ligadura de un puerto con múltiples localidades ayudaa mantener el modelo sencillo e intuitivo, puesto que, en caso que sólose pueda ligar un puerto a una localidad, el modelado de un buildingblock puede resultar más complejo. Un ejemplo claro es cuando el buil-ding block puede recibir información desde dos fuentes. En estos casossi el puerto no permite múltiples adaptadores, habrá que modelar dospuertos, uno para cada fuente. Además, la estructura interna del buil-ding block también tendrá que ser modificada de forma que haya unatarea al principio sólo para recibir los mensajes de los puertos y darlepaso a la próxima tarea. Por desgracia, sólo BizTalk permite tener puer-tos con múltiples adaptadores y con algunas limitaciones ya que estosólo es posible en el caso de los puertos de entrada.

Puertos bidireccionales: Los puertos bidireccionales permiten un modeladomás sencillo y directo, especialmente, en los casos que un building blo-ck envía un mensaje a otro y espera una respuesta. Dichos puertos per-miten que la petición y la respuesta sean tratadas en el mismo puerto,el que también permite, hacer la correlación de los mensajes en el pro-pio building block que las ha procesado de forma más sencilla. El hecho


de no haber puertos bidireccionales obliga a usar dos puertos diferen-tes, uno de entrada y otro de salida, lo que también dificulta la tarea decorrelación del mensaje original con la respuesta. Por desgracia, de lastecnologías estudiadas sólo ServiceMix y BizTalk permiten puertos bidi-reccionales.

Pipeline en puertos: Un pipeline permite a un puerto ejecutar un pre/posprocesamiento en serie sobre el mensaje antes y/o después de que lastareas internas a un building block lo procesen. El pipeline de los puer-tos de entrada suele preparar el mensaje para que las tareas internas albuilding block puedan procesarlo, mientras que el pipeline de los puer-tos de salida suele dejar el mensaje en un formato que se pueda transmi-tir al próximo building block. El hecho de no soportar pipelines en lospuertos obliga a añadir tareas al principio y/o al final del building blockpara hacer dichos pre/pos procesamientos. Ejemplos claros de preproce-samientos en un pipeline de un puerto de entrada son la decodificación odescompresión de los mensajes recibidos, la validación de los mismos, laautentificación del remitente, etcétera. Un procesamiento común y exclu-sivo a los puertos de datos, tanto en un pipeline de los puertos de entradacomo en un de los de salida, es el mapeo de datos brutos a mensajes yviceversa. Entre las herramientas estudiadas, Mule, Spring Integration yBizTalk son las que ofrecen algún soporte al concepto de pipeline, sien-do BizTalk la que incluye un modelo de pipeline más elaborado y máscomponentes para construirlos.

Building blocks con estado: Un building block puede necesitar guardar in-formación útil en próximas ejecuciones del mismo. Esto permite, e.g.,guardar una lista de los últimos mensajes recibidos que evite procesar enel futuro mensajes que son semánticamente equivalentes; en otras oca-siones puede servir para guardar resultados que son costosos de calcular,evitando así que al recibir un mensaje parecido los cálculos se tengan querepetir. Por lo tanto, es deseable que los building blocks puedan guardarestado, pero por desgracia ninguna de las herramientas estudiadas losoporta directamente.

Tareas con estado: De la misma forma que para los building blocks, permitirque todas las tareas puedan guardar su estado, puede resultar interesan-te. Una tarea puede guardar información de estado persistiendo su con-texto de ejecución o guardando un mensaje con información contextual.Un ejemplo común de tarea que puede guardar estado es el agregadory el resecuenciador [17]. El agregador se encarga de volver a unir doso más mensajes, mientras que el resecuenciador recibe mensajes desor-denados y los ordenada. Ambos tipos de tareas tienen que guardar los

2.2. Problemas 21


Modelo ejecución 1 : 1 1 : 1 1 : 1 1 : 1 1 : 1

Mensajes tipados No No No No Sí/No

Mensajes anómalos Sí No No Sí Sí

Descargar ejecución No No No No Sí

Patrón de comunicación Sí† No Sí No No

Soporte para pruebas Sí No No No Sí

Adjuntos No Sí Sí No Sí

Diseño de adaptadores No No No No Sí

Sistema de gestión Sí Sí Sí No Sí

Soporte comercial Sí Sí Sí Sí Sí† No permite definir nuevos tipos de MEPs.

Tabla 2.3: Propiedades de carácter técnico.

mensajes que reciben hasta que se pueda procesarlos. Entre las herra-mientas estudiadas tan sólo Camel, Mule, ServiceMix y Spring Integra-tion ofrecen algunas tareas que pueden guardar estado, pero sólo en for-ma de mensajes.

Diseño de tareas: Cuando una herramienta no soporta un determinado tipode tarea, generalmente hay que recurrir a una tarea general y configurar-la mediante código ad-hoc. El problema es que estas tareas generales nohacen explícita la intención del diseñador, lo que puede resultar un pro-blema añadido a la hora de entender los modelos. Desde este punto devista es deseable que la herramienta ofrezca soporte al diseño de nuevastareas reutilizables, haciendo explícita su intención. Por desgracia, de lasherramientas estudiadas, sólo BizTalk proporciona una herramienta pa-ra diseñar nuevas tareas; en el resto de los casos es necesario recurrir aprogramación de bajo nivel.

2.2.3. Características técnicas

En esta categoría hemos incluido aquellas propiedades que afectan a la fa-cilidad de programación, al rendimiento o a la gestión de las soluciones deintegración, por lo que su ausencia puede dificultar el despliegue y la ope-ración de las mismas. Entre las más importantes, destacamos las siguientes,cf. Tabla §2.3:


Modelo de ejecución: El modelo de ejecución de los building blocks puedetener un impacto importante en el rendimiento de una solución de in-tegración. El más sencillo consiste en asignar una hebra a cada mensajeo conjunto de mensajes que deben ser tratados de forma conjunta porun building block; por supuesto, las hebras pueden tomarse de un poolpara conseguir de esta forma mantener siempre bajo control la carga to-tal de trabajo del servidor. Este es el modelo que implementan todas lasherramientas estudiadas, pero presenta una deficiencia que creemos quepuede afectar de forma negativa a la escalabilidad de las soluciones. Elproblema está relacionado con el hecho de que cuando una instancia deun building block llega a un punto en el que no puede continuar ejecu-tando tareas, e.g., porque es necesario esperar la llegada de un mensaje,la hebra queda ociosa durante un tiempo completamente indetermina-do. De nuestra experiencia concluimos que un modelo capaz de ejecutarde forma asíncrona varias instancias de un mismo building block sobreun pool de hebras sería mucho más efectivo. En la actualidad estamostrabajando en el diseño e implementación de este modelo con el objetivode evaluar ambas alternativas y poder obtener conclusiones.

Mensajes tipados: En soluciones típicas de integración suele ser necesariorealizar decenas de transformaciones a los mensajes; cualquier error enuna de ellas puede dar lugar a un mensaje incoherente, por lo que es muydeseable que estos sean tipados. Por desgracia, salvo en el caso de Biz-Talk, todas las herramientas examinadas asumen que los mensajes sonobjetos Java sobre los que no se realiza ninguna comprobación de tipo;en cualquier caso, también es posible tener mensajes sin tipo en BizTalk.

Mensajes anómalos: Cuando un mensaje presenta algún tipo de anomalíaque hace imposible que sea procesado por un building block, lo nor-mal es que éste produzca una excepción y que el mensaje en cuestiónse almacene de forma que pueda ser analizado por el administrador delsistema. Además, es muy deseable que estos mensajes también puedanser tratados de forma automática de manera que se intente llevar a caboalgún tipo de acción correctiva en el mismo instante en el que se detec-tan. Por desgracia, ni Mule ni ServiceMix ofrecen ningún mecanismo quepermita automatizar el tratamiento de estos mensajes.

Descargar la ejecución: El procesamiento de un mensaje por un building blo-ck puede exigir aguardar la recepción de un segundo mensaje. Un si-tuación común se presenta cuando es necesario enriquecer un mensajecon información que pertenece a una fuente externa. En estos casos laejecución del building block se queda parada durante un tiempo, com-pletamente indeterminado, hasta que no llegue el otro mensaje. Por lotanto, la posibilidad de descargar el contexto de ejecución del building

2.2. Problemas 23

block permite ahorrar recursos que pueden ser fundamentales para lamaquina. Por desgracia, de las herramientas estudiadas, tan sólo BizTalkpermite descargar la ejecución.

Patrón de comunicación: El patrón para intercambio de mensajes (MEPs)permite definir tipos específicos de comunicación [30]. Una solución deintegración puede utilizar distintos tipos de MEPs, como el unidireccio-nal y sin respuesta (InOnly), el bidireccional con una respuesta obligato-ria (InOut), el bidireccional con una respuesta opcional (InOptionalOut),etcétera. El uso de MEPs facilita la correlación entre los mensajes quellegan a un building block y las respuestas obtenidas. Por este motivo,desde un punto de vista técnico, es deseable que la herramienta ofrezcasoporte a dicho patrón y permita definir nuevos tipos de MEPs, ademásde los que ya pueda aportar. En nuestro estudio hemos visto que las úni-cas que soportan este patrón de comunicación son Camel y ServiceMix,aunque sólo ServiceMix permite definir nuevos tipos de MEPs.

Soporte para pruebas: Un soporte para pruebas permite diseñar aplicacionessencillas y enfocadas para ayudar a validar el funcionamiento de unasolución de integración. En nuestra experiencia hemos visto que dise-ñar pruebas desde cero puede resultar complejo para el programador,además de costoso para la empresa. Desde este punto de vista, es desea-ble que las herramientas para la integración ofrezcan algún soporte parapruebas puesto que ayudaría a reducir la complejidad y el coste. De lasherramientas estudiadas, tan sólo Camel y BizTalk ofrecen soporte paradiseñar pruebas.

Mensajes con adjuntos: Un mensaje puede llevar, además de la informaciónde cabecera y cuerpo, otros objetos con información adjunta. La informa-ción adjunta no debe sufrir ningún procesamiento en la solución de inte-gración, es decir, sólo representa información adicional que se transmitejunto con el mensaje. Creemos que el hecho de separar la informaciónadjunta del cuerpo del mensaje permite reducir su tiempo de procesa-miento, puesto que la tarea al tener que acceder al cuerpo no tendrá quetratar los datos de los adjuntos. Además, en caso que los adjuntos esténseparados del cuerpo, se puede utilizar el patrón ClaimCheck [17] paraguardarlos en un medio persistente, mientras se procesa en mensaje, ydespués recuperarlos. De las herramientas estudiadas, las únicas que nosoportan mensajes con adjunto son Camel y Spring Integration.

Diseño de adaptadores tecnológicos: Los adaptadores tecnológicos facilitanla comunicación a bajo nivel con una fuente de datos externa a la solu-ción de integración, e.g, base de datos, fichero XML, canal JMS, etcéte-ra. Todas las propuestas estudiadas aportan varios tipos de adaptadores


tecnológicos para las tecnologías mas conocidas, como JDBC, SQLServer,JMS, POP3, FTP, etcétera. Para los casos que la herramienta de integra-ción no proporciona un determinado tipo de adaptador que se necesite,el programador puede desarrollarlo, aunque esto implique en tener unconocimiento más especializado sobre el tema. Por este motivo, desdeun punto de vista técnico, es deseable que las herramientas aporten re-cursos que permitan crear dichos adaptadores de una forma más sencillae intuitiva. Por desgracia, sólo BizTalk proporciona una herramienta es-pecífica para hacer esto.

Sistema de gestión: Un sistema de gestión proporciona una vista de alto ni-vel de la solución de integración desplegada y que se está ejecutando.Además suele permitir monitorizar en tiempo real la ejecución de losbuilding blocks, las transacciones, el rendimiento, etcétera. Desde estepunto de vista es deseable que las herramientas ofrezcan algún sistemaque permita gestionar la solución de integración. La ausencia de dichossistemas obliga a los programadores diseñar aplicaciones ad-hoc pararealizar la gestión. Entre las herramientas que hemos estudiado, sóloSpring Integration no aporta ningún sistema de este tipo.

Soporte comercial: El soporte comercial ofrecido por las empresas creadorasde las herramientas propietarias, o por aquéllas que están por detrás delos proyectos de herramientas de código abierto, puede resultar de graninterés a quién va a utilizar la herramienta. La totalidad de las herra-mientas estudiadas ofrecen soporte comercial.

2.3. Discusión

Las propiedades que proponemos pueden resultar muy útiles a la hora deevaluar una herramienta, que se quiere adoptar, para diseñar soluciones deintegración. El conocimiento a priori de dichas propiedades y de sus valoresdeseables, permiten a los ingenieros del software comparar propuestas en uncontexto particular y llegar a una buena decisión sobre qué herramienta mejorse adapta para resolver su problema, con una baja inversión en tiempo y coste.En la Tabla §2.4 presentamos todos los valores, que, desde nuestro punto devista, son deseables y por lo tanto ideales para cada una de las propiedades dealcance. Al igual, en las Tablas §2.5 y §2.6 presentamos, respectivamente, losvalores deseables y ideales para las propiedades de modelado y técnicas.

En la actualidad hay una gran variedad de herramientas disponibles, quese proponen a soportar el diseño de soluciones de integración. Aunque hemos

2.3. Discusión 25

Propiedad Valor deseable

Contexto EAI/B2BI/EII/ETL

Patrón arquitectónico Pipes/Filters

Nivel PIM/PSM

Transacciones ST-B/LT-B/ST-S/LT-S

RoutingSlip dinámico Sí

Extensiones Sí

Adaptadores de aplicación Sí

Tipo de modelo O/D-IoC/D-Gráfico y XML

Licencia N/A

Tabla 2.4: Valores deseables para las propiedades de alcance.


Vistas Wrapper/Aplicación/Proceso/Nube/Solución

Cardinalidad de los building blocks N : M

Cardinalidad de las tareas N : M

Cardinalidad de las localidades N : M-Comp/Repl

Correlación Sí

Tipos de puertos PD/PM

Adaptadores en puertos N : M

Puertos bidireccionales Sí

Pipeline en puertos Sí

Building block con estado Sí

Tareas con estado Sí

Diseño de tareas Sí

Tabla 2.5: Valores deseables para las propiedades de modelado.

estudiado, para esta memoria, aquellas que más se destacan en este mundode la integración, podemos concluir que ninguna de ellas llega a ser la herra-mienta ideal para el diseño de soluciones de integración. Por lo tanto, esto eslo que nos motiva a seguir trabajando en esta área y a desarrollar una nuevapropuesta que ofrezca, al máximo posible, soporte a todas estas característicasy valores deseables.



Modelo ejecución N : M

Mensajes tipados Sí†Mensajes anómalos Sí

Descargar ejecución Sí

Patrón de comunicación Sí

Soporte para pruebas Sí

Adjuntos Sí

Diseño de adaptadores Sí

Sistema de gestión Sí

Soporte comercial Sí† Pero también permita mensajes sin tipo

Tabla 2.6: Valores deseables para las propiedades técnicas.

2.4. Sumario

En este capítulo hemos presentado un conjunto de propiedades agrupa-dos en tres categorías distintas y que sirven de apoyo a la hora de evaluaruna herramienta para el diseño de soluciones de integración. Además hemosidentificado algunas deficiencias importantes en las herramientas analizadasy comparadas. Por medio de este estudio llevado a cabo, concluimos que toda-vía las herramientas actuales carecen de algunos recursos esenciales, los quepueden suponer un alto coste a la hora de diseñar una solución de integración.Al final hemos presentado los valores que juzgamos deseables e ideales paracada una de las propiedades analizadas.

Parte II

Revisión de propuestas

Capítulo 3

Herramientas para la integración

E l tema de la integración de aplicaciones es algo novedoso y de enormeinterés por parte de la industria del software. Hay varias herramien-

tas para dar soporte al proceso de diseño de soluciones de integración, queproporcionan un mayor o menor nivel de alcance. En la Sección §3.2 presenta-mos Camel, una de las herramientas ofrecidas por Apache para la integraciónde aplicaciones; en la Sección §3.3, el ESB Mule, proporcionado por Mulesour-ce; en la Sección §3.4, el ESB ServiceMix, otra herramienta de Apache parala integración, pero basada en la tecnología JBI; en la Sección §3.5, la herra-mienta Spring Integration de SpringSource; y, finalmente, en la Sección §3.6,la herramienta BizTalk 2006 de Microsoft.

30 Capítulo 3. Herramientas para la integración

3.1. Introducción

Hay varias herramientas que se proponen a ayudar en el área de integra-ción de aplicaciones, desde bibliotecas de clases hasta complejas infraestructu-ras y tecnologías para la comunicación y la integración, basadas en el conceptode Enterprise Service Bus (ESB). La arquitectura de algunas de estas propues-tas se basa en arquitecturas abiertas y ya conocidas, como Java Business In-tegration (JBI), mientras que otras se basan en una arquitectura propietariay cerrada. Algunas de ellas son comerciales mientras que otras son de licen-cia libre. Las herramientas libres suelen estar en un estado muy incipiente dedesarrollo; por otro lado las comerciales suelen ser más completas y por lotanto avanzadas, pero algunas veces por razones comerciales, no proporcio-nan una documentación técnica y una versión de evaluación del software quepermita estudiarla, sin que haya que comprarla. El que parece ser un puntocomún entre gran parte de las propuestas estudiadas, es el objetivo de sopor-tar al máximo posible los Enterprise Integration Patterns (EIP) [17]. Aunqueni todas las herramientas estudiadas ofrezcan, e.g., soporte directo por me-dio de bloques de construcción a dichos patrones, se puede encontrar en susdocumentaciones referencias y guías para implementarlos.

Debido a la novedad del tema tratado y al enorme interés por parte de laindustria en el mismo, gran parte de las herramientas y resultados actualesno están publicados aún en congresos o revistas o incluso libros, lo que jus-tifica los documentos en la Web que son referenciados en esta memoria. Enel framework de comparación para las herramientas estudiadas, además defacilitar el sitio web de las mismas, el que suele ser la fuente principal de in-formación, hemos evaluado desde nuestro punto de vista la calidad y gradode terminación de la documentación disponible.

Para el estudio en esta memoria, hemos escogido una propuesta comercialy cuatro libres. Por medio de una investigación previa, dichas propuestas sehan mostrado ser las más referenciadas y adecuadas para el momento y tra-bajo que estamos desarrollando. Buscamos, además de algunas herramientasmuy conocidas y por lo tanto significativas en el tema, otras que de algunaforma ofrezcan soporte a los patrones de integración. Durante el desarrollode la tesis se completará el estudio con otras herramientas más, como, e.g.,OpenSyncro [27], OpenEAI [24] y Tibco [29]. Las dos primeras son proyectoslibres, mientras que la última es una de las herramientas comerciales más co-nocidas en el área, pero que hasta el momento no hemos tenido acceso a sudocumentación y al software para poder evaluarla. El interés, también, poraquellas herramientas relacionadas con los patrones de integración, es porqueel trabajo de investigación que estamos desarrollando y el futuro trabajo parala tesis, está al igual muy relacionado con el tema de estos patrones. Se trata

3.1. Introducción 31

Figura 3.1: Conceptos del mundo de la integración.


de una propuesta de un metamodelo independiente de plataforma para dise-ñar soluciones de integración de aplicaciones. Por lo tanto, se han estudiadoen esta memoria las siguientes herramientas: Apache Camel, Mule, ApacheServiceMix, Spring Integration y Microsoft BizTalk.

El vocabulario que hemos encontrado durante el estudio de estas herra-mientas, en el área de integración de aplicaciones, es muy vasto, confuso ysin ninguna estandarización. Esto supone una inversión mayor de tiempo ala hora de evaluar una herramienta, puesto que el conocimiento claro de es-tos conceptos es fundamental para trabajar en dicha tarea. Con el objetivo deminimizar este problema proponemos un vocabulario común para los concep-tos del mundo de la integración de aplicaciones. Se describen dichos concep-tos comunes por medio de un mapa conceptual, cf. Figura §3.1, además deque presentamos para cada una de las herramientas estudiadas una tabla queadapta este vocabulario común al suyo.

El concepto central del mapa es el Integration solution. Este primer con-cepto describe a alto nivel todos los elementos necesarios para integrar unconjunto de aplicaciones. De forma general estos elementos son Wrappers,Processes y Compensation block, y a todos ellos nos referimos como Buildingblocks. Otro elemento importante en una solución de integración es el Inte-gration link, el que permite conectar de forma lógica los Building blocks, paraque puedan comunicarse por medio de Ports. Al hacer el despliegue de la so-lución, el Integration link se transforma en un Channel, que por su vez estacompuesto de uno o más Pipelines y uno o más Adapters. El Pipeline permiteejecutar un conjunto de actividades (e.g., encode, decode, validate, etcétera)sobre el mensaje entrante o saliente. Por otro lado, el Adapter se encarga deleer y/o escribir datos en un recurso real (Actual resource), representado poruna localidad (Location). Los Building blocks están compuestos por Tasks yejecutan lógica de negocio. Task implementa un determinado patrón de inte-gración (Integration pattern), el que define su semántica de procesamiento delos Messages y/o Exchanges que el Building block recibe y envía por mediosus Ports. Se desincronizan las Tasks y Ports internos de los Building blocks pormedio de Slots, que simplemente representan buffers de almacenamiento. LosPorts que forman parte de un Building block pueden ser de dos tipos distintos:Message port o Data port. El primero transfiere exclusivamente mensajes en-tre los Building blocks de la solución y en un formato canónico de la solución,mientras que el segundo recibe y/o envía datos, en un formato externo al dela solución. La transformación de los mensajes que están en el formato de lasolución para el formato externo a la solución, o al revés, se hace por mediodel elemento Mapper.

3.2. Apache Camel 33

Figura 3.2: Modelo conceptual de la arquitectura de Camel.

3.2. Apache Camel

Apache Camel, o simplemente Camel, es un proyecto hijo del proyectode código abierto para el desarrollo de un Message Broker llamado ApacheActiveMQ, mantenido por Apache Software Foundation. El objetivo de Cameles extender ActiveMQ para aportarle la posibilidad de uso de algunos de lospatrones de integración. Camel no esta limitado solamente al ActiveMQ, sinoque también se puede sacar partido los siguientes proyectos de Apache: CXF,MINA y ServiceMix [7].

Los desarrolladores de Camel lo definen como “un framework basado enSpring para diseñar soluciones de integración de aplicaciones” [7]. La versiónque se documenta en esta memoria es la versión 1.2, puesto que la versión 1.3surgió justo al término de la escritura de la memoria; debido a que se trata de


Nuestro vocabulario Vocabulario de Camel

Integration solution Routes + Endpoints

Integration cloud Routes

Integration flow Route

Building block –

Process Route

Wrapper Endpoint + Route

Compensation block –

Message port –

Data port EndpointInteractor

Integration link –

Location Endpoint

Task Service

Simple task Processor

Composite task CompositeProcessor/MulticastProcessor

Slot –

Receive pipeline –

Send pipeline –

Mapper –

Command message in Message

Event message in Message

Response message out Message

System message fault Message

Exchange Exchange

Technology adapter Component

Application adapter –

Channel EndpointInteractor

Tabla 3.1: Vocabulario de la herramienta Camel.

un proyecto de código abierto en un estado incipiente, la documentación esmuy pobre y se decidió posponer el estudio de la versión 1.3 hasta el desarro-llo de la tesis. La versión estudiada de Camel no proporciona una herramientapara diseño gráfico de una solución de integración, es decir, toda su configu-ración y uso de las tareas se hace por medio de código.

En Camel una solución de integración está formada por una o más rutasde integración, que conectan dos o más Endpoints. Su arquitectura, vista desdeun nivel alto de abstracción, cf. Figura §3.2, está compuesta de un CamelCon-


Figura 3.3: Estructura y taxonomía de los mensajes y exchanges en Camel.

text que contiene cero o más Components, Routes y Endpoints, además de unconstructor de rutas llamado RouteBuilder. El Component se utiliza para crearEndpoints, mientras que el RouteBuilder para crear las rutas de mensajes. Paracada tecnología que se va a acceder hay un tipo de componente, e.g., JMS-Component para acceder canales JMS y FileComponent para acceder ficheros.La Tabla §3.1 presenta la equivalencia del vocabulario que se utiliza en Camely el que proponemos como estándar, en esta memoria, para el area de integra-ción.

Hay dos tipos fundamentales de Endpoint: Source y Target. El primero esel que produce mensajes, mientras que el segundo los recibe. Para interactuarcon estos dos tipos, Camel ofrece objetos Producer y Consumer. Service defineuna interfaz de servicio que permite iniciar y parar la ejecución de una tarea,Task representa los tipos de tareas que pueden ser ejecutadas en las rutas.Finalmente, Processor define la interfaz para el procesamiento un Exchange.

3.2.1. Mensajes

Los mensajes se representan en Camel, generalmente, por la interfaz Mes-sage, cf. Figura §3.3. Camel ofrece una implementación de esta interfaz lla-mada DefaultMessage. Por esto cualquier tipo específico de mensajes que ne-cesitamos en una solución de integración, debe ser creado desde la clase baseDefaultMessage. Por ejemplo, para cada tipo de Endpoint que se utiliza a lahora de integrar una aplicación, un tipo específico de mensaje compatible con


la tecnología que se accede debe ser utilizado o creado. Es decir, en caso que elEndpoint esté integrando una aplicación por medio de colas de un sistema demensajería JMS, entonces dicho Endpoint debe generar mensajes de tipo JMS-Message; por otro lado, en caso que el Endpoint esté integrando una aplica-ción por medio de un fichero, el tipo del mensaje generado será FileMessage.En su framework Camel ofrece, para cada uno de los tipos de Component yEndpoint, una implementación específica de DefaultMessage.

La interfaz Message ofrece métodos para leer y modificar la cabeceray el cuerpo del mensaje. El cuerpo del mensaje es un objeto Java de cual-quier tipo, mientras que la cabecera es un mapa de parejas atributo-valor(Map<String,Object>). La jerarquía y estructura de los mensajes en Camel sepuede representar cf. Figura §3.3.

El Exchange representa una estructura que puede llevar tres tipos de men-sajes (request, reply y error), además de definir un patrón de comunicaciónpor medio del ExchangePattern. Se utiliza el Exchange a la hora de comuni-car e intercambiar mensajes entre las aplicaciones integradas en una soluciónde integración diseñada con Camel. Request (el in) representa el mensaje queva desde un Endpoint de origen hacia el Endpoint de destino, mientras quereply (el out) representa la respuesta del destino (en los casos que haya) parael origen y, finalmente, error (el fault) representa un posible error que se hapodido generar durante el procesamiento llevado a cabo por un Endpoint. Aligual que con los mensajes, la interfaz Exchange representa de forma generalun Exchange, pero para cada tecnología que se va a acceder se debe utilizarun tipo específico, como, e.g., el JMSExchange o el FileExchange. El Exchan-gePattern permite a Camel definir patrones más complejos de intercambio demensajes, llamados Message Exchange Patterns (MEPs) [30]. Es decir, es elobjeto MEP que lleva el Exchange el que va a definir si la comunicación es,e.g., unidireccional y sin respuesta (InOnly), bidireccional con una respuestaobligatoria (InOut), bidireccional con una respuesta opcional (InOptionalOut),etcétera.

En una solución de integración diseñada con Camel, los objetos que se vana transferir de un Endpoint a otro(s) son de tipo Exchange, que a su vez pue-den contener en su estructura tipos específicos de Message y definen un de-terminado patrón de comunicación (ExchangePattern). Las tareas que compo-nen la ruta de integración de una solución siempre aceptan mensajes de tipoExchange, o sea, no se puede definir un tipo específico de mensaje para unatarea. En los casos que una tarea o Endpoint reciba un mensaje de un tipo queno puede procesar por alguna razón, debe generar una excepción en tiempode ejecución. Cómo está diseñada la arquitectura de Camel y la estructura delos mensajes, cualquier excepción también puede ser añadida a un objeto Ex-


change como si fuera un mensaje normal.

3.2.2. Modelo

El modelo de Camel permite diseñar soluciones de integración de aplica-ciones. El diseño de toda una solución se hace por medio de código utilizandosu API de programación o de forma declarativa. La construcción y configu-ración de las rutas se puede hacer de forma declarativa, por medio de fiche-ros XML, u operativa, por medio de un lenguaje específico de dominio (DSL)ofrecido por el framework. Desde un punto de vista global la solución de in-tegración resultante tiene una topología de grafo y una estructura distribuida,es decir, las rutas conectan fuentes de mensajes y las transfieren hasta su des-tino. Estas rutas de integración tienen forma de árbol y son monolíticas. No esposible, e.g., descomponerlas en subprocesos de integración. Pueden, además,ejecutar un procesamiento sobre los mensajes, como, e.g., transformaciones deformato, enriquecimiento de contenido, filtrado, etcétera.

Las tareas ejecutadas en una ruta de integración tienen una entrada des-de la que reciben mensajes entrantes y suelen tener una salida para enviar ala tarea siguiente de la ruta el mensaje saliente. Las tareas de enrutamientollamadas RecipientList y Choice son un caso especial, puesto que tienen la ca-pacidad de enrutar un mensaje entrante para uno o más destinos en la ruta,ofreciendo entonces, al contrario de las demás, una o más salidas.

El soporte a transacciones se da a nivel de rutas, puesto que una transac-ción puede empezar en un Endpoint de origen y terminar en un Endpoint dedestino. Camel no ofrece soporte directo para las transacciones y lo deja a car-go del contenedor que va a ejecutar la solución, e.g., Spring. Éste, a su vez, esel que ofrece todo el soporte para la creación de Endpoints transaccionales. Ala hora de diseñar las rutas transaccionales, hay que tener en cuenta que éstassolamente pueden ser implementadas cuando todos los Endpoints que formanparte de la ruta sean del mismo tipo y su tecnología soporte transacciones, co-mo, e.g., la tecnología Java Message Service (JMS).

3.2.3. Puertos

El concepto de puerto como punto de entrada o salida de mensajes paraprocesos que forman parte de una solución de integración no existe directa-mente en Camel. De todas formas se puede hacer una comparación entre elconcepto de puertos de datos y el concepto de Producer/Consumer que hay


en Camel. Desde este punto de vista, los objetos productores se encargan deescribir datos en un Endpoint, mientras que los consumidores se encargan deleer datos desde el Endpoint y producir un mensaje para la ruta de integración.Desde otro punto de vista estos objetos productores/consumidores represen-tan también canales para escritura/lectura en los Endpoints. Se puede conectarel Endpoint a uno o más canales de escritura, permitiendo entonces que dos omás productores puedan escribir información en él. Además puede haber unoo más canales de lectura para el mismo Endpoint, pero en estos casos los obje-tos consumidores van a competir por la información disponible.

En Camel es el propio Endpoint el que se encarga de crear sus objetos pro-ductores y consumidores para recibir/enviar mensajes. Dichos objetos son es-pecíficos para acceder a una tecnología, la que es, a su vez, definida por eltipo del Endpoint. Es decir, los Endpoints son dependientes de tecnología, y secrean por medio de un Component, también, específico para una tecnología.Los tipos de Components soportados por el framework y utilizados para creardichos Endpoints, e.g., son: ActiveMQ, Bean, CXF, File, FTP, HTTP, JDBC, JBI,MSMQ, etcétera.

3.2.4. Tareas

Las tareas ofrecidas por Camel para soportar algunos de los patrones deintegración se llaman, de forma genérica, Service. Estos servicios suelen im-plementar el comportamiento de un Processor, el que define la interfaz deprocesamiento de un Exchange. Las tareas de tipo BatchProcessors tienen supropio comportamiento para procesamiento, puesto que, diferente de las de-más, necesitan procesar dos o más Exchanges a la vez. De acuerdo con [7], laversión que hemos estudiado de Camel soporta 29 patrones de integración. LaFigura §3.4 presenta la estructura y taxonomía de algunas de estas tareas.

En Camel todas las tareas son servicios que se pueden iniciar o parar, ade-más de procesar algo. La capacidad de procesamiento es aportada por la in-terfaz Processor y permite, e.g., el Splitter procesar un Exchange entrante re-cibido de una tarea anterior y enviar el resultado a la próxima tarea del flujo.Un BatchProcessor puede recibir un conjunto de Exchanges para procesar-los todos a la vez, y de igual forma enviar el resultado en adelante. Tal tipode tarea, además de la diferencia con las otras por no implementar la inter-faz Processor, tiene su uso limitado. Esto se debe a que sólo se puede tenerun BatchProcessors como la primera tarea de la ruta, y no en el medio o alfinal de la ruta. El Aggregator es un ejemplo, recibe una colección de objetosExchange como entrada directamente desde el Endpoint en el que empiezala ruta, los agrega en un único Exchange y lo envía en adelante a otra tarea.


Figura 3.4: Estructura y taxonomía de las tareas de Camel.


Mientras la interfaz Processor define el comportamiento básico para que unatarea pueda procesar un Exchange que reciba, AsyncProcessor define un ti-po más complejo de Processor que tiene la capacidad de procesar de formaasíncrona un Exchange. Además de las tareas que están en un primer niveldebajo de Task en la jerarquía, hay otros tres subtipos que sirven de base parala construcción de otros tipos de tareas. El primer grupo, el DelegateProces-sor, además de poder procesar los Exchanges puede delegar el procesamientoa otros Processors anidados que tengan; por otro lado el grupo, representadopor MulticastProcessor, puede tener varias tareas internas y procesar de for-ma asíncrona, como, e.g., el Pipeline. En el Pipeline un Exchange entrante deuna tarea es el Exchange saliente de otra, además de que el procesamiento delas tareas se hace de forma asíncrona. Desde otro punto de vista los Multicast-Processors, al igual que los CompositeProcessors son tareas compuestas, quepueden ejecutar internamente dos o más Processors.

Cualquier tarea o Endpoint permite añadir interceptores delante de su en-trada o luego después de su salida. Los interceptores son objetos que permitenejecutar algún tipo de procesamiento antes o inmediatamente después de laejecución de la tarea. Estos interceptores no son pre o pos condiciones para lastareas, sino que acciones que se van a ejecutar en conjunto con la acción deprocesamiento de la tarea. A toda esta flexibilidad de configuración y uso deuna tarea, se añade la posibilidad de extender cualquier tarea predefinida delframework y crear nuevas tareas más específicas en caso que haya necesidad.

3.2.5. Despliegue

Camel es simplemente una biblioteca de clases e interfaces que se puedeutilizar tanto en una aplicación independiente, como parte de un frameworkcomo Spring o ServiceMix, para crear soluciones de integración de aplicacio-nes. Independientemente de donde se va a utilizar, un proceso que forma par-te de una solución de integración se ejecutará todo en la misma maquina y enmemoria. Esto hace que la comunicación entre dos o más procesos, siempresea por medio de Endpoints en los que un proceso puede escribir informacióny el otro leer. Hay que hacer lo mismo cuando el objetivo es comunicar dos omás procesos que se ejecuten en máquinas diferentes. Esto hace que en la granmayoría de los casos la comunicación entre procesos en Camel sea asíncrona.Por otro lado la comunicación entre las tareas que forman parte de un procesosiempre será síncrona.

Un punto muy importante en las soluciones de integración es el grado dereutilización que se puede hacer de ellas. Para reutilizar una solución diseña-da con Camel, hay que escribir un mensaje en el recurso real que el Endpoint


entrante representa y leer el resultado en el otro recurso real que el Endpointsaliente representa. Al hacer esto estaremos reutilizando todo el procesamien-to de la ruta. Otros recursos muy importantes en las herramientas de integra-ción son los que permiten monitorizar o hacer pruebas sobre los procesos deintegración o sobre toda la solución de integración. Camel ofrece un frame-work llamado Business Activity Monitoring (BAM) que permite, además derealizar pruebas, monitorizar las rutas de integración.

3.2.6. Ejecución

Una solución de integración diseñada con Camel se puede ejecutar, res-petando sus dependencias de bibliotecas, en cualquier máquina virtual Javaversión 5. Aunque el núcleo de Camel dependa solamente de una bibliotecade logging llamada commons-logging.jar, otros módulos tienen más depen-dencias, como es el caso de camel-jms el que requiere un JMS Provider o elcamel-http que a su vez requiere un HTTP Provider. Los proveedores son unaimplementación de los adaptadores utilizados por los Endpoints para accedera una tecnología concreta. De acuerdo con [6], se puede ejecutar una soluciónen el servidor de aplicaciones Spring u otro cualquiera, que esté basado enSpringFramework. El modelo de ejecución de estos contenedores es de tipoInversion of Control [10], el que permite hacer la configuración de los Com-ponents y las Tasks directamente en sus ficheros de configuración XML. Asíla estructura de los Components y las Tasks queda más sencilla y el contene-dor pasa a ser el encargado de inyectar toda la configuración de dependencianecesaria y contenida en los ficheros XML.

Por tratarse de una biblioteca que se puede hacer uso en cualquier aplica-ción Java, una solución diseñada con Camel puede ser depurada fácilmentecon la ayuda del recurso para depuración de la herramienta de desarrollo uti-lizada. Camel también ofrece un framework de clases para diseñar y hacerpruebas sobre la solución de integración creada.

3.2.7. Miscelánea

Camel es distribuido con la licencia Apache License 2.0, la que permite en-tre otras cosas su libre uso. Para estudiarlo, hasta el momento de la escritura deesta memoria, hemos encontrado muy poca información fuera del sitio web deCamel (http://activemq.apache.org/camel), el que hace del sitio la fuente másimportante de información. Además de la documentación encontrada, es po-sible subscribirse a foros de discusión relacionados directamente con esta he-

http://activemq.apache.org/camel


Figura 3.5: Modelo conceptual de la arquitectura de Mule.

rramienta. Su documentación, puede ser clasificada respecto a la terminación,cf. Apéndice §A, cómo ? ?; mientras que la calidad, cf. Apéndice §B, cómo ra-zonable. Camel, cómo muchos otros productos del mundo del software libre,tiene una implementación comercial que es ofrecida por la empresa IONA Te-chnologies (http://www.iona.com). IONA también proporciona en su sitio webdocumentación para esta su implementación de Camel, además de servicio deconsultoría en esta herramienta.

3.3. Mule

Mule es una herramienta cuya arquitectura se basa en el concepto de En-terprise Service Bus (ESB) y se presenta como una nueva alternativa para quelas empresas puedan utilizarla a la hora de diseñar su infraestructura de inte-gración [23]. El desarrollo de Mule empezó con el “Mule Project” y en el año

http://www.iona.com

3.3. Mule 43

Nuestro vocabulario Vocabulario de Mule

Integration solution Services + Endpoints

Integration cloud –

Integration flow –

Building block Service

Process Service

Wrapper Endpoint


Message port Endpoint

Data port Listener


Location EndpointURI

Task Router

Simple task Router

Composite task ChainingRouter

Slot –

Receive pipeline InboundEndpoint

Send pipeline OutboundEndpoint

Mapper Transformer

Command message MuleMessage

Event message MuleEvent

Response message MuleMessage

System message –

Exchange –

Technology adapter Connector/Transport


Channel Listener

Tabla 3.2: Vocabulario de la herramienta Mule.

2006 recibió soporte financiero de algunos grupos de inversión para que fueracreada la empresa llamada MuleSource. Esta es hoy la empresa que esta pordetrás de Mule. Parte de la herramienta sigue siendo distribuida en forma-to “Community”, además de una versión comercial ofrecida por MuleSource.Para esta memoria hemos estudiado la distribución Community versión 2.0de Mule.

Una solución de integración diseñada en Mule se representa por uno o másServices independientes que se comunican por medio Endpoints utilizando


una infraestructura de comunicación proporcionada por Mule o por terceros.Dichos Services también pueden comunicarse con una aplicación externa yaexistente y ejecutar algún procesamiento en los mensajes por medio de Rou-ters. Para comunicarse con la aplicación, ésta debe proporcionar una interfazpor medio de la que se pueda recibir o enviar información. La Tabla §3.2 pre-senta la equivalencia del vocabulario que se utiliza en Mule y el que propone-mos como estándar, en esta memoria, para el área de integración.

La arquitectura de Mule, desde un punto de vista conceptual, se centraen cuatro tipos de componentes: Service, Endpoints, Routers y Connectors,también llamados Transports. La Figura §3.5 presenta estos componentes yalgunos de sus tipos.

Service es el componente central y esta compuesto por uno o cero UMO-Component, el que se encarga de ejecutar cualquier lógica de negocio cuandollegue un MuleEvent al Service. Este componente puede ser cualquier objetoJava (POJO, Spring Bean, JavaBean, etcétera) o servicio web. Service recibeMuleEvents desde un Endpoint, ejecuta alguna lógica de negocio y envía unarespuesta, en caso que haya, a uno o más Endpoints de salida. Además de ini-ciar y parar un Service, se puede pausar y reiniciar. Aunque esté pausado,Service va a seguir recibiendo MuleEvents y almacenándolos en una cola pa-ra que cuando vuelva a ejecutar, se pueda procesarlos. Antes o después deejecutarse el Service, se puede, también, ejecutar uno o más Routers.

Los Routers son procesamientos que se puede hacer sobre la informaciónque se recibe o se envía. La gran mayoría de ellos son implementaciones dealgunos de los patrones de integración y se discuten en más detalles en laSección §3.3.4.

Endpoint es el componente que permite a dos o más Services comuni-carse o incluso, que un Service pueda, comunicarse con una aplicación ex-terna. Todo Endpoint es identificado de forma única por un objeto Endpoin-tURI, que define y representa su localización completa para acceso. El End-point puede ejecutar una o más transformaciones en la información (entran-te/saliente) utilizando Transformers. Dichas transformaciones pueden ser devarios tipos, como, e.g., transformar un objeto Java a XML (o al revés), compri-mir/descomprimir la información, codificar/decodificar, etcétera. El Endpointno lee o escribe los mensajes en los recursos reales directamente, para esto uti-liza objetos Connector.

Connector es dependiente de tecnología, es decir, para cada tecnología quese va a acceder el Endpoint necesita un tipo específico de Connector. Por ejem-plo, en caso que se vaya acceder una base de datos a través del protocoloJDBC, se necesita un JDBCConnector; en caso que se vaya acceder un servi-

3.3. Mule 45

Figura 3.6: Estructura de los mensajes en Mule.

dor de correo electrónico a través de POP3, POP3Connector. Para realizar lasoperaciones en el recurso real, cada tipo de Endpoint tiene que crear un objetode tipo Listener, que pueda enviar y/o recibir datos. El InboundEndpoint creaun objeto MessageReceiver para recibir mensajes, mientras que el Outboun-dEndpoint crea un MessageDispatcher para enviar los mensajes al Endpointde salida. En Mule, hay que tener en cuenta que los InboundEndpoints recibensiempre MuleMessage, pero que los Services solamente reciben y se activancon MuleEvents. Por lo tanto, el InboundEndpoint debe crear un objeto Mu-leEvent y añadirle el MuleMessage recibido, para que pueda enviarlo hacia elService.

3.3.1. Mensajes

El mensaje en Mule es la estructura utilizada para la comunicación entrelos Services por medio de sus Endpoints, además de ser utilizado por el UMO-Component para enviar una respuesta que pueda producir en su procesamien-to. En la Figura §3.6, MuleMessage representa el mensaje y su estructura. ElUMOComponent, al igual que el Service, solamente recibe y procesa MuleE-vents. Por otro lado, toda la respuesta producida por el UMOComponent essiempre un MuleMessage. El MuleEvent además de almacenar el MuleMessa-ge con todas sus partes, almacena la información respecto al Endpoint que lorecibió; por otro lado, es el MuleMessage el que almacena los datos originalesque fueron utilizados para crearlo, además de los datos que eventualmentesufran algún procesamiento por los Routers, la información de cabecera y losficheros adjuntos.

Los mensajes en Mule no llevan ningún tipo y pueden almacenar cual-


quier tipo de dato, en realidad cualquier objeto Java. Inicialmente se recibeny almacenan estos datos en objetos Payload y OriginalPayload. OriginalPay-load almacena una copia de los datos originales recibidos y los mantiene, sinningún cambio mientras exista el mensaje, para que cuando sea necesario sepueda recuperar el contenido original recibido. Por otro lado Payload repre-senta realmente el cuerpo del mensaje que puede ser accedido y modificadopor los Routers. La información de cabecera se almacena en un objeto de tipoMap, en el que cada atributo de la cabecera es una pareja atributo-valor y pue-de almacenar cualquier tipo de objeto Java como valor. El mensaje tambiénpuede llevar cero o más datos adjuntos, representados en la Figura §3.6 por elelemento Attachment.

3.3.2. Modelo

El modelo de Mule permite diseñar soluciones de integración de aplica-ciones. Dicho modelo no hace una separación clara del diseño de la solucióny su implementación, es decir, todo se hace directamente en código por me-dio de un framework Java. La configuración de los Routers utilizados en lasolución también se puede hacer de forma declarativa, por medio de ficherosde configuración XML. Además de la vista de solución de integración propor-cionada por el conjunto de Services, Mule ofrece una vista de proceso, la querepresenta el Service y sus Routers.

El elemento central del modelo, el Service, se comunica con uno o másServices o aplicaciones por medio de sus Endpoints. Esto permite que se tengauna solución de integración distribuida y con una topología en forma de grafo.Aunque parezca que dos o más Services (o un Service y una aplicación) es-tén fuertemente acoplados por este estilo de comunicación, en realidad estándesacoplados puesto que el Endpoint de salida envía el mensaje a un recursoreal desde el que otro Endpoint de entrada puede leerlo. Se identifican estosrecursos por medio de los EndpointURI, y pueden ser compartidos por dos omás Endpoints (el de salida y el de entrada). Al fin y al cabo, es el recurso reales responsable de la desincronización de la comunicación. Este recurso realpuede ser, e.g., un fichero o un canal de un sistema de mensajería como JMS,o aún del propio framework de mensajería/integración proporcionado porMule. Solamente habrá un fuerte acoplamiento en los casos que se utilice uncanal síncrono de comunicación, como, e.g., el HTTP. Un Service que formaparte de una solución de integración puede contener en su UMOComponentcódigo con cualquier lógica de negocio para ejecutarlo al recibir el MuleEvent.Esto permite escribir, incluso, una aplicación entera directamente dentro dela solución de integración. Esta posibilidad amplia el papel principal de una

3.3. Mule 47

solución de integración, el que deja de ser solamente conectar dos o más apli-caciones externas a la solución para también permitir crear aplicaciones quepertenezcan a la solución. Tanto en el caso que se escriba un proceso de ne-gocio complejo o incluso una aplicación entera en el UMOComponent, comopara los casos que se esté integrando aplicaciones externas a la solución, noquedan claras qué aplicaciones se están integrando.

El soporte para transacciones se da, principalmente, entre el Endpoint deentrada y el de salida de un mismo Service. En este escenario el Endpointde entrada (InboundEndpoint) es el encargado de empezar la transacción quedebe ser terminada en el Endpoint de salida (OutboundEndpoint). Se puedeimplementar las transacciones utilizando el mecanismo de transacciones dela tecnología de los Connectors, en los casos que soporten transacciones, opor medio del envío de un mensaje ack al origen para que sea confirmada ocancelada la transacción. Además, un Endpoint de entrada para un Servicepuede escoger formar parte de una transacción de un mensaje entrante quereciba de otro Service. Por lo tanto vemos que Mule soporta transacciones deltipo short-term tanto a nivel de proceso cómo inter-proceso.

3.3.3. Puertos

En Mule el concepto de puertos para los procesos de una solución de inte-gración no existe directamente. De todas formas es posible, desde un punto devista conceptual, comparar los dos tipos de objetos Listener con el concepto depuertos de datos, cf. Figura §3.5. Aunque esto se pueda hacer, hay que teneren cuenta que tanto MessageReceiver como MessageDispatcher son objetosdependientes de tecnología cuyo objetivo es proporcionar un canal de acce-so a un recurso real, leer o escribir datos. Cada uno de estos objetos Listenersestá relacionado solamente con un Endpoint y por lo tanto no podrán, e.g.leer o escribir en dos o más localidades. Lo que sí que es posible es que unalocalidad sea compartida por uno o más objetos Listener. En estos casos pue-de haber dos o más MessageDispatchers escribiendo en la misma localidad odos o más MessageReceivers recibiendo de la misma localidad. Para el Mes-sageReceiver, en los casos que hayan dos o más, la lectura de los datos seráen forma de competición. Desde otro punto de vista, en los casos en que dosServices se comunican directamente uno con el otro, en la misma maquina yen memoria, por medio de sus Endpoints, se puede ver estos Endpoints comopuertos de mensajes.


Figura 3.7: Tipos de tareas de Mule.

Figura 3.8: Tareas en el flujo de entrada de un servicio en Mule.

Figura 3.9: Tareas en el flujo de salida de un servicio en Mule.

3.3.4. Tareas

Las tareas en Mule se llaman, de forma genérica, Routers. De acuerdo conla Figura §3.7, hay dos grupos de Router, InboundRouter y OutboundRouter.Los InboundRouters se encargan de preparar el MuleMessage entrante, quese ha añadido al MuleEvent generado en el InboundEndpoint, para que puedaser ejecutado por el UMOComponent. De lo contrario, los OutboundRouterspermiten ejecutar algunas tareas sobre el mensaje saliente antes de enviarloal Endpoint de salida. En la Figura §3.8 se presenta algunas de las tareas quese pueden ejecutar después de recibir el mensaje en el Endpoint de entrada;por otro lado, en la Figura §3.9 se presentan tareas que se pueden ejecutar an-tes de que un mensaje llegue al Endpoint de salida. Hay que tener en cuentaque, además de estas tareas que forman parte del flujo entrante/saliente deinformación, los Endpoints de entrada/salida también pueden ejecutar algún

3.3. Mule 49

pre y pos procesamiento, como, e.g., el filtrado y transformación. La diferen-cia entre la tarea Transformer de la Figura §3.9 y los transformadores que sepuede tener en los Endpoints, cf. Figura §3.5, es que mientras los primeros sonpara hacer transformaciones de formato del mensaje, el último es para hacertransformación de tipo de mensaje (e.g., XML a objeto Java). Respecto a losfiltros, hemos encontrado ambigüedad en la documentación. Mientras en ladocumentación del sitio web de Mule, en [23] dicen que los filtros de los End-points se puede ejecutar tanto por los Endpoints de entrada como los de salida,en la documentación Javadoc de los fuentes disponible en [22], dicen que sólose puede ejecutar en los Endpoints entrantes, aunque en el código fuente Javadel OutboundEndpoint haya filtro.

Solamente algunas de las tareas se ejecutan en el flujo que va hacia el Servi-ce, como, e.g., el Aggregator y el WireTap, mientras otras solamente se ejecutanen el flujo que va desde el Service hacia el Endpoint de salida. Como ejemplopara este último grupo tenemos Splitter y todos los tipos de enrutadores so-portados por Mule, como, e.g., el RecipientList y el MulticastingRouter. Por lotanto, todas las tareas de tipo InboundRouter tienen siempre una entrada y unasalida, mientras que los de tipo OutboundRouter siempre tienen una entradapero pueden tener dos o más salidas.

No se obligan los Services a ejecutar un UMOComponent. En estos casosdespués de ejecutar los InboundRouters que forman parte del InboundRouter-Collection el Service debe pasar directamente a la ejecución de los Outboun-dRouters que forman parte del OutboudRouterCollection. Para los casos queService tenga un UMOComponent hay dos posibles escenarios. El primero escuando el UMOComponent recibe un MuleEvent, lo consume y no produceningún MuleMessage de salida; el segundo, y más común, es cuando recibeun MuleEvent, lo consume y produce un MuleMessage de respuesta.

El soporte y uso de interceptores se puede encontrar en algunas de las de-más propuestas analizadas y incluso en la versión 1.x de Mule. En la versión2.x de Mule no se recomienda el uso de estos interceptores, incluso de acuerdocon la documentación Javadoc de Mule disponible en [22], la versión 2.x ya noproporciona soporte para los mismos.

3.3.5. Despliegue

El despliegue de una solución de integración es bastante flexible, puestoque, además del propio Mule poder ejecutarla de forma independiente con suservidor, otros servidores o incluso una aplicación independiente Java puedentambién ejecutarla.


En todos estos escenarios los Services que forman parte de una solución deintegración pueden comunicarse de forma asíncrona, pero también en algunoscasos de forma síncrona. La reutilización en la herramienta Mule se da a nivelde Service, puesto que se puede escribir datos en la localidad de lectura delInboundEndpoint y leer la salida en la localidad del OutboundEndpoint.

Mule ofrece una herramienta que permite visualizar un RouteCollection,pero que no permite editarlo. Además de esta herramienta, Mule aporta otrapara monitorizar las transacciones llamada Mule Saturn; otras dos para ges-tionar las aplicaciones desplegadas llamadas Mule HQ y JMX Agent; y, final-mente, una para controlar la infraestructura de Mule llamada Mule Galaxy.Al igual que la mayoría de los ESBs, Mule también proporciona una infraes-tructura para transportar mensajes, además de un motor de ejecución para susaplicaciones.

3.3.6. Ejecución

La biblioteca ofrecida por Mule para construcción de las soluciones de in-tegración es una biblioteca de clases Java, la que independientemente del tipode despliegue debe acompañar la solución creada a la hora de su ejecución.Es decir, en los casos que la solución va a ser embebida en una aplicación Javaindependiente, la biblioteca debe ser añadida al paquete de instalación gene-rado; por otro lado cuando se va a ejecutar la aplicación en servidores, se debeinstalar también en el servidor. Además del servidor proporcionado por Mulepara ejecución de las soluciones, también se puede desplegarlas/ejecutarlasen otros servidores compatibles, como, e.g., JBoss, Geronimo, Oracle AS, We-bLogic, etcétera. Dado que Mule soporta el modelo Inversion of Control [10],otros contenedores que dan soporte a esto tipo de ejecución, como Spring yPicoContainer, también pueden ser utilizados para la ejecución [23].

El diseño de Mule permite hacer, en su servidor de ejecución, la actualiza-ción de una solución en caliente, es decir, sin que haya la necesidad de parar laejecución actual para poder actualizarla. Cada proceso va a ejecutar por mediode su propia hebra, de forma que la solución de integración sea formada porvarias hebras en ejecución.

3.3.7. Miscelánea

Mule es distribuido con la licencia Common Public Attribution LicenseVersion 1.0 (CPAL) en el sitio web http://mule.mulesource.org. Además en este

http://mule.mulesource.org

3.4. Apache ServiceMix 51

Figura 3.10: Modelo conceptual de la arquitectura de ServiceMix.

sitio web se puede acceder a una documentación sobre la herramienta paraempezar a estudiarla y/o subscribirse en foros de discusión relacionados di-rectamente con el tema. Su documentación, puede ser clasificada respecto a laterminación, cf. Apéndice §A, cómo ? ? ?; mientras que la calidad, cf. Apén-dice §B, cómo buena. La empresa Mule Source (http://www.mulesource.com),que esta detrás de la herramienta Mule, además de ofrecer una versión comer-cial de la herramienta, también ofrece servicio de consultoría.

3.4. Apache ServiceMix

Apache ServiceMix es otra herramienta gratuita que ofrece Apache Soft-ware Foundation. Sus desarrolladores definen ServiceMix como un EnterpriseService Bus (ESB) distribuido basado en la tecnología Java Business Integra-tion (JBI) de Java [8]. Para este estudio hemos escogido la versión 3.2.1 de laherramienta, la que describiremos más detalladamente a lo largo de la sección.

Gran parte de la arquitectura de ServiceMix se basa en la tecnología JBI,así que el diseño de una solución de integración queda muy influida por estatecnología, cf. Figura §3.10. En esta arquitectura una solución de integraciónpuede estar formada por un conjunto de JBIComponents que ejecutan tareasque se exponen por medio de los Endpoints. Además, se puede crear un Flowpara definir el flujo de integración y orden de ejecución de algunas de los End-points expuestos. Dicho Flow tendrá una lista de Endpoints por donde se debe

http://www.mulesource.com


Nuestro vocabulario Vocabulario de ServiceMix

Integration solution JBIComponents + NMR

Integration cloud –

Integration flow Flow

Building block JBIComponent

Process JBIComponent

Wrapper JBIComponent


Message port DeliveryChannel

Data port JBIComponent

Integration link NMR

Location Endpoint

Task Endpoint

Simple task Endpoint

Composite task –

Slot –

Receive pipeline –

Send pipeline –

Mapper –

Command message NormalizedMessage

Event message NormalizedMessage

Response message NormalizedMessage

System message Fault

Exchange MessageExchange

Technology adapter JBIComponent


Channel –

Tabla 3.3: Vocabulario la herramienta ServiceMix.

enrutar un MessageExchange. Cada JBIComponent suele ejecutar una tarea,aunque no esté limitado y pueda ejecutar varias, para esto debe exponer másque un Endpoint. JBIComponent suele representar un proceso de integraciónqué provee y también puede consumir servicios de forma local o remota pormedio de Endpoints. Es decir, al ejecutar un JBIComponent que provee un ser-vicio, éste puede necesitar consumir otro servicio de un JBIComponent parafinalizar el suyo. La comunicación entre los Endpoints (proveedores y consu-midores) se hace por medio del Normalized Message Router (NMR), mientrasque la comunicación entre el JBIComponent y el NMR se hace por medio de


DeliveryChannels. Aunque se suele comparar el JBIComponent con un pro-ceso, éste también puede desempeñar, a veces, el labor de un wrapper. LaTabla §3.3 presenta la equivalencia del vocabulario que se utiliza en Service-Mix y el que proponemos como estándar, en esta memoria, para el área deintegración.

El elemento central de la arquitectura es el NMR. Este router es uno de loselementos más importantes en el entorno de JBI (JBIEnvironment) puesto quees el encargado, entre otras cosas, de gestionar todos los tipos de JBICom-ponents y sus Endpoints, los Flows y los DeliveryChannels. Hay dos tipos deJBIComponent, el primero es el que contiene la lógica de negocio a nivel local(ServiceEngine, conocido simplemente por SE) y el segundo (BindingCompo-nent, o simplemente BC) es el que permite exponer dichas reglas al mundoexterior, además de permitir también los SEs ejecutar algún procesamientoremoto. Todos los JBIComponents utilizan un canal bidireccional, el Delivery-Channel, para enviar o recibir MessageExchanges del NMR.

Los BCs actúan como proxies para servicios remotos mientras que los SEsejecutan localmente una regla de negocio. Estos dos tipos de JBIComponentpueden actuar no solamente como proveedores o consumidores, sino como losdos a la vez. Para esto exponen las operaciones que pueden ejecutar por mediode objetos Endpoints y una definición WSDL de dicha interfaz. WSDL, entreotras cosas, lleva el nombre y la URI del Endpoint. Además actúa, junto conel Endpoint como una interfaz del JBIComponent. Hay dos tipos de Endpointque permiten comunicar con un JBIComponent, a saber: ProviderEndpoint yConsumerEndpoint. ProviderEndpoint expone al NMR una lista de operacionesque el router puede llamar en un BC o en un SE. Sólo se permite utilizar Con-sumerEndpoint en los BCs, y éste expone al mundo exterior, también, una listade operaciones que pueden ser llamadas por el NMR en cualquier proveedorque él conozca (local o remoto). Es decir, una llamada externa podrá ser aten-dida por un SE o incluso un BC. Los SEs, en los casos que sean consumidores,también pueden hacer llamadas a proveedores por medio del NMR.

En el modelo conceptual de la arquitectura de ServiceMix, cf.. Figura §3.10,se puede ver dos elementos especiales, a saber: EIPComponent y EIPEndpoint.Se tratan de elementos que sirven para extender el modelo de ServiceMix afin de proporcionar soporte a algunos de los patrones de integración. EIP-Component representa un tipo de JBIComponent que ejecuta localmente unservicio (SE) dentro del ServiceMix. Por otro lado EIPEndpoint representa untipo especial de Endpoint, y expone una interfaz para soportar un determina-do patrón de integración. Se utiliza el EIPComponent para definir un procesode integración que pueda ejecutar sobre el MessageExchange entrante uno omás patrones de integración. Para esto se define uno o más EIPEndpoints, en


Figura 3.11: Estructura y taxonomía de los mensajes en ServiceMix.

el que cada EIPEndpoint representa un determinado patrón.

3.4.1. Mensajes

Los mensajes se representan, en ServiceMix, por medio de la interfaz Nor-malizedMessage. NormalizedMessage esta compuesto por un elemento Body,un Header y cero o más Attachment. Body representa el cuerpo del mensaje; enél se almacenan en formato XML los datos que se van a trasmitir. Header re-presenta la cabecera y almacena parejas atributo-valor, en que cada atributo serepresenta mediante una cadena y sus valores son objetos Java de cualquier ti-po. Finamente, Attachment, representa los datos adjuntos que se pueden trans-mitir con el mensaje. Para almacenar los fallos que se puedan producir en unacomunicación, ServiceMix ofrece un tipo de mensaje que especializa Normali-zedMessage, que se llama Fault.

Toda la comunicación entre los Endpoints se hace enviando objetos Messa-geExchange por medio del NMR. En ServiceMix hay cuatro tipos de Messa-geExchange diseñados de acuerdo con los patrones de comunicación MessageExchange Pattern (MEP) [30], a saber: InOnly, InOut, InOptionalOut y Robus-tInOnly. Aunque haya solamente estos cuatro tipos, el modelo de ServiceMixpermite definir otros tipos de MEPs. Un MessageExchange, además de llevarun NormalizedMessage (que representa una petición o una respuesta), puedellevar un mensaje de fallo (Fault), un error de tipo Java para representar dichofallo, o el Endpoint al que se destine el MessageExchange.


3.4.2. Modelo

El modelo de ServiceMix permite diseñar soluciones de integración deaplicaciones. Es un modelo específico para una plataforma (PSM), muy en-focado en la tecnología Java, puesto que su fuente de inspiración es JBI. La so-lución de integración resultante está compuesta por un conjunto de procesospor los que se enruta un MessageExchange. La topología de dichas solucioneses en forma de grafo, pero no proporciona ninguna vista.

ServiceMix proporciona una biblioteca que se puede utilizar para crear so-luciones de integración por medio del uso directo de sus clases Java en cual-quier aplicación independiente o servidora. Además de este lenguaje operati-vo, hay un lenguaje declarativo que permite crear los Endpoints para exponerlas funcionalidades de los JBIComponents, además de permitir definir flujospara el enrutamiento de los MessageExchanges. Todo esto se hace por me-dio de ficheros de configuración XML en ServiceMix. No hay acoplamientoentre los JBIComponents y sus Endpoints, puesto que para intercambiar Mes-sageExchanges, hacen uso de un DeliveryChannel. Por otro lado toda la co-municación entre los Endpoints, se hace por medio del NMR.

El modelo de ServiceMix siempre hace uso de JBIComponents para cual-quier procesamiento, o comunicación con un recurso externo al JBIEnviron-ment. En los casos en que se hace uso de un JBIComponent para acceder a unrecurso externo, como, e.g., un fichero que representa la capa de comunicaciónde una aplicación, dicha capa accedida queda documentada por medio de tipode JBIComponent que se ha utilizado. Por otro lado no queda documentadala aplicación que se ha integrado. Respecto a la transacción, ServiceMix ofrecesoporte tanto a nivel de procesos como a nivel de solución de integración, sinembargo la tecnología de todos los JBIComponents involucrados debe sopor-tar transacciones.

3.4.3. Puertos

Todo JBIComponent envía y/o recibe MessageExchanges por medio desu propio canal DeliveryChannel (o simplemente DC) que mantiene con elNMR. Por lo tanto, DC actúa como un puerto de mensajes bidireccional paralos JBIComponents. Además de este tipo de puerto, aquellos JBIComponentsque proveen acceso a un recurso real externo al JBIEnvironment (como, e.g., elservicemix-file, el servicemix-jms, el servicemix-ftp, etcétera) tendrán objetosespecíficos y dependientes de tecnología para leer/escribir datos en estos re-cursos. Aunque no sean realmente puertos, se puede comparar estos objetos,


Figura 3.12: Taxonomía de los mensajes en ServiceMix.

de una forma conceptual, con los puertos de datos de otras propuestas paraintegración de aplicaciones. No hay ningún control por parte del ServiceMixrespecto al acceso de dos o más JBIComponents al mismo recurso real. Porlo tanto esto permite dos o más JBIComponents escribir y/o leer del mismorecurso. En el caso de la lectura, hay que tener en cuenta que siempre que unJBIComponent lee un dato del recurso real, el dato es borrado del recurso. Es-to hace que todos los JBIComponents que acceden el mismo recurso compitanpor los datos.

Se distribuyen varios tipos de JBIComponent junto con la herramienta Ser-viceMix, e.g., File, FTP, HTTP, JMS, TrueZip, etcétera. Además de estos, variosotros se han desarrollado por terceros y están disponibles en el sitio web deServiceMix. Una gran ventaja que tiene ServiceMix por haber inspirado su ar-quitectura en la tecnología JBI, es que se puede ejecutar cualquier componentedesarrollado de acuerdo con la especificación JBI en ServiceMix. En la Subsec-ción §3.4.4 tratamos el tipo especial de JBIComponent, el que permite aportaral ServiceMix patrones de integración.

3.4.4. Tareas

En la arquitectura de ServiceMix se representa una tarea, de forma general,con un Endpoint expuesto por un JBIComponent. Los JBIComponents repre-sentan procesos que pueden formar parte de una solución de integración. Hayque tener en cuenta que ServiceMix gestiona todos los JBIComponents des-plegados y ninguno de ellos pertenece exclusivamente a una solución. Dichosprocesos suelen ejecutar al menos una tarea, a nivel local (SE) o remoto (BC),y la exponen al NMR por medio de un ProviderEndpoint para que éste puedaejecutar el proceso. Por lo tanto no hay un límite de tareas/procesos en Ser-


viceMix, cualquiera puede crear un JBIComponent que represente un procesode integración y, además, crear sus propias tareas.

En esta subsección de la memoria vamos a estudiar el JBIComponent, detipo SE, llamado EIPComponent. Dicho componente permite diseñar proce-sos de integración formados, exclusivamente, por patrones de integración. Pa-ra crear un proceso, e.g., se define de forma declarativa en el fichero XMLde configuración de ServiceMix un conjunto de EIPEndpoints proveedores deservicios. Al elemento EIPEndpoint se ha añadido la posibilidad de contenerExchangeTargets, que representan los próximos Endpoints a los que hay queenviar el MessageExchange (cf. Figura §3.12). Por lo tanto, el MessageEx-change que se envía al proceso, lleva inicialmente el nombre y la URI de laprimera tarea del proceso. Dicha tarea recibe el MessageExchange, lo procesay entonces cambia el atributo provider del MessageExchange para que éstesea el Endpoint siguiente en proceso. Dicha información se hace disponible enel atributo targets del propio EIPEndpoint que ha procesado, puesto que enun EIPComponent cada EIPEndpoint conoce el próximo (o los próximos) alque hay que enviar el MessageExchange. La Figura §3.11 presenta el provi-der que el mensaje puede llevar en su estructura, mientras que la Figura §3.12presenta la lista de objetos ExchangeTarget que el EIPEndpoint lleva. Por lotanto después de hacer este cambio de destino en el MessageExchange, elEIPEndpoint actual envía el MessageExchange al DeliveryChannel, desde elque el NMR va a leerlo y enrutarlo al EIPEndpoint siguiente. La Figura §3.12presenta una lista completa de las tareas aportadas por ServiceMix.

Lo normal para una tarea es recibir un MessageExchange, procesarlo yluego enviarlo hacia adelante. Es decir, el EIPEndpoint tendrá solamente unobjeto ExchangeTarget en su lista. Pero algunas tareas cómo es el caso delStaticRecipientList pueden necesitar enviar el MessageExchange a dos o másEIPEndpoints. En estos casos, el StaticRecipientList tendrá una lista de Mes-sageTargets, y enviará al DeliveryChannel copias del MessageExchange ori-ginal para cada uno de los MessageTargets de la lista.

Tareas cómo SplitAggregator, almacenan estado para ejecutar su funciona-lidad. Se han diseñado dos tareas teniendo en cuenta una posible extensión,a saber: AbstractSplitter y AbstractAggregator. Para estos dos tipos abstractos,se ha definido en ServiceMix dos tipos concretos, aunque cualquiera puedeextenderlas y crear otros tipos. Los que se ha creado son: XPathSplitter y Spli-tAggregator. Se tratan de tareas muy específicas, la primera es para partir unNormalizedMessage utilizando expresiones XPath, mientras que la segundaes un aggregator solamente para NormalizedMessages que han sido partidaspor un AbstractSplitter. Aunque se pueda extender tareas a bajo nivel por me-dio de programación, ServiceMix no aporta ninguna herramienta que permita


diseñar nuevas tareas a un nivel de abstracción superior.

3.4.5. Despliegue

Se puede empaquetar una solución de integración diseñada en Service-Mix en un archivo de tipo Web Application Archive (WAR) y desplegarla encualquier servidor Java EE (e.g., JBoss) o Java Web Container (e.g., ApacheTomcat). ServiceMix también puede ejecutar soluciones de integración en supropio servidor ESB. Los JBIComponents desplegados, y que forman parte dela solución de integración, se comunican de forma asíncrona por medio delNMR y del DeliveryChannel.

Los JBIComponents qué componen una solución de integración, aunqueparezca que pertenecen exclusivamente a ella, al ser desplegados en el servi-dor se pueden reutilizar en otras soluciones de integración. Es decir, al final to-dos los JBIComponents representan servicios ejecutando en un servidor, queproveen o consumen otros servicios por medio de los MessageExchanges.Con esto se puede decir qué la reutilización se da a nivel de JBIComponent.Si consideramos el caso específico del EIPComponent, que permite exponerdos o más Endpoints y llamarlos en separado, se puede decir que la reutiliza-ción se da a nivel de tarea. Es decir, podríamos enrutar un MessageExchange,directamente, a uno u otro Endpoint. ServiceMix ofrece una herramienta paragenerar un imagen y representar gráficamente un Flow que esté configurado,pero no permite editarlo. Además de este recurso se puede utilizar una herra-mienta llamada ServiceMix JMX Console para gestionar los JBIComponentsdesplegados en el servidor.

3.4.6. Ejecución

El modelo de ServiceMix también soporta la ejecución de la solución encontenedores que implementan el modelo Inversion of Control [10], comoSpring. Es decir, el contenedor puede crear y configurar los JBIComponentsde acuerdo con las configuraciones XML que se han hecho en el fichero deconfiguración de la solución. La actualización de dicha solución en el servidorde ServiceMix se puede hacer tanto a nivel de proceso, cómo a nivel de so-lución. Para esto la herramienta proporciona un mecanismo de actualizaciónen caliente de los JBIComponents o del archivo WAR. Hay que tener en cuen-ta que la ejecución y la actualización de la solución cuando es desplegada enotros servidores que no sea el de ServiceMix, depende de las características decada servidor. Forma parte de ServiceMix, un plug-in para desarrollo y confi-

3.5. Spring Integration 59

guración de los JBIComponents en el Eclipse IDE. Además este plug-in ofrecela posibilidad de depurar remotamente un JBIComponent o una solución deintegración diseñada con ServiceMix.

3.4.7. Miscelánea

ServiceMix, igual que otras herramientas de Apache Software Foundation,es distribuido con la licencia Apache License 2.0. Se puede descargar el Ser-viceMix en el sitio web oficial, en el enlace http://servicemix.apache.org. En elmismo sitio web se puede acceder a una documentación, además de foros ylistas de discusión para estudiar la herramienta. Su documentación, puede serclasificada respecto a la terminación, cf. Apéndice §A, cómo ? ? ?; mientras quela calidad, cf. Apéndice §B, cómo razonable. El estudio de esta tecnología tam-bién supone una inversión mayor de tiempo, puesto que involucra, además dela herramienta ServiceMix, la tecnología JBI. Al igual que para la herramientaCamel, la empresa IONA Technologies (http://www.iona.com) está por detrásde ServiceMix ofreciendo, en este caso, servicios de soporte y consultoría enla herramienta.

3.5. Spring Integration

Spring Integration es un producto que forma parte de SpringFramework(o simplemente, Spring). Todavía se encuentra en fase inicial de desarrollo,puesto que lo sacaron a fines del año 2007 y aun se encuentra en la versión1.0 Milestone 3. Su objetivo es extender el modelo de programación de Springpara el dominio de mensajería, es decir, permitir el uso de mensajes en el fra-mework Spring. Además de esto, Spring Integration proporciona el uso devarios patrones de integración.

Una solución de integración diseñada con Spring Integration está com-puesta por uno o más MessageEndpoints que pueden realizar algún proce-samiento sobre los mensajes que reciben, MessageChannels que permiten lacomunicación asíncrona en un flujo de integración y ChannelAdapters que po-sibilitan leer o escribir en los recursos que representan las capas de las aplica-ciones integradas. La Tabla §3.4 presenta la equivalencia del vocabulario quese utiliza en Spring Integration y el que proponemos como estándar, en estamemoria, para el área de integración.

La arquitectura de Spring Integration esta inspirada, entre otras cosas, enel patrón Pipes and Filters [17], en el que los pipes se representan con los Mes-

http://servicemix.apache.org

http://www.iona.com


Figura 3.13: Modelo conceptual de la arquitectura de Spring Integration.

sageChannels y los filters con los MessageEndpoints. En la Figura §3.13 sepresenta la arquitectura conceptual de esta herramienta, además de estos doselementos. Para entender la arquitectura de Spring Integration es importanteconocer, además de estos elementos, otros dos: el MessageBus y el ChannelA-dapter.

Un canal de comunicación se presenta de forma abstracta en Spring Inte-gration con el MessageChannel. Los MessageEndpoints y ChannelAdaptersutilizan estos canales para comunicación. Hay dos tipos de canales, a saber:PointToPoint y PublishSubscribe. Mientras que a un canal PointToPoint se en-vía un mensaje y se permite solamente un elemento receptor (MessageEnd-point o ChannelAdapter), el PublishSubscribe representa un canal al que doso más elementos interesados pueden subscribirse para recibir una copia delmensaje. Se permite en uso de ChannelInterceptors en dichos canales, de for-ma que se puede hacer intervenciones antes y/o después de transmitir unmensaje.

MessageEndpoint representa un elemento que tiene la capacidad de subs-cribirse a un MessageChannel para recibir mensajes y ejecutar una o más ta-reas de procesamiento. El mensaje resultado se envía a uno o más canales desalida. Las tareas en un MessageEndpoint se ejecutan internamente por ele-


Nuestro vocabulario Vocabulario de Spring Integration

Integration solution MessageEndpoints + MessageChannels + ChannelAdapters

Integration cloud MessageEndpoints + MessageChannels

Integration flow MessageEndpoints + MessageChannels

Building block Endpoint

Process MessageEndpoint

Wrapper ChannelAdapter


Message port –

Data port ChannelAdapter

Integration link MessageChannel

Location Resource

Task MessageHandler

Simple task MessageHandler

Composite task MessageHandlerChain

Slot –

Receive pipeline InputAdapter

Send pipeline OutputAdapter

Mapper MessageMapper

Command message GenericMessage

Event message GenericMessage

Response message GenericMessage

System message ErrorMessage

Exchange –

Technology adapter Adapter


Channel ChannelAdapter

Tabla 3.4: Vocabulario de la herramienta Spring Integration.

mentos de tipo MessageHandler, aunque el propio MessageEndpoint sea untipo de MessageHandler. En realidad, de acuerdo con la documentación deSpring Integration en [28], MessageEndpoint extiende MessageHandler pa-ra permitir definir un contenedor de MessageHandlers. Un MessageEndpointsuele ejecutar un único MessageHandler sobre el mensaje que recibe, como,e.g., el MessageFilter, que puede aplicar un determinado filtro sobre el mensa-je entrante (cf. Figura §3.15 para otros tipos de tareas). Aunque se pueda tenersolamente un único MessageHandler por MessageEndpoint, se puede ejecu-


tar internamente dos o más tareas. Esto se hace utilizando un MessageHand-lerChain en el MessageEndpoint. Con estos dos elementos se proporciona laejecución de dos o más tareas. En caso que se produzca un error durante laejecución de un MessageEndpoint, se añade dicho error en un mensaje y seenvía por medio de un objeto ErrorHandler a un canal específico de errores.Un MessageEndpoint subscrito a un MessageChannel puede tener uno o másMessageSelectors a fin de garantizar que solamente se van a recibir determi-nados mensajes seleccionados del MessageChannel.

ChannelAdapters son objetos que permiten comunicarse tanto con los ca-nales de la solución de integración, como con los recursos reales que repre-sentan las capas de las aplicaciones que se están integrando. Hay dos tipos deChannelAdapter, a saber: InputAdapter y OutputAdapter. El InputAdapter per-mite leer datos de la aplicación que se esta integrando, transformarlos con untipo específico de MessageMapper a un mensaje y enviar el mensaje a un Mes-sageChannel entrante de la solución. Por otro lado, OutputAdapter se encargade recibir/leer un mensaje de un MessageChannel de la solución de integra-ción y transformarlo, por medio de otro MessageMapper, en un formato quese pueda enviar/escribir en el recurso que representa la capa de la aplicaciónintegrada.

MessageBus es el elemento central de la arquitectura, puesto que, desdeun punto de vista general, es el encargado de gestionar todos los Message-Channels y MessageEndpoints que forman parte de la solución de integración.Cuando haya un mensaje en un canal, también es el responsable a enviarlo losMessageEndpoints subscritos e interesados en procesarlo, o al igual, recibirun mensaje que representa el resultado de un MessageEndpoint y enviarloa un MessageChannel. Para estas operaciones, hay que tener en cuenta si eltipo del canal es PointToPoint o PublishSubscribe. En realidad es el Messa-geBus el que proporciona al desarrollador la posibilidad de centrarse en eldiseño/configuración de las tareas de procesamiento que se hacen sobre losmensajes, sin que haya que preocuparse por la implementación de un meca-nismo que permita a los mensajes fluir entre dichas tareas y canales de comu-nicación.

3.5.1. Mensajes

La interfaz Message representa de forma general los mensajes en la herra-mienta Spring Integration. En esta herramienta, un mensaje es simplementeun contenedor para llevar objetos Java de cualquier tipo de un Endpoint a otro.La Figura §3.14 presenta la estructura y taxonomía de los mensajes. El men-saje contiene un objeto Java cualquier tipo para representar su cuerpo, que


Figura 3.14: Estructura y taxonomía de los mensajes en Spring Integration.

se llama payload. Además del cuerpo, la estructura también lleva un objetoMessageHeader que representa la cabecera del mensaje. Este objeto esta com-puesto de parejas atributo-valor, en que cada atributo se representa medianteuna cadena y sus valores, de nuevo, son objetos Java de cualquier tipo. Alcontrario que en otras herramientas para diseñar soluciones de integración deaplicaciones, Spring Integration no permite que los mensajes lleven adjuntos.

Spring Integration proporciona una clase llamada GenericMessage queextiende la interfaz Message, que a su vez sirve de implementación base paratodos los tipos de mensajes. De igual forma, la herramienta proporciona dostipos específicos de mensajes, a saber: StringMessage y ErrorMessage. String-Message es un contenedor para los mensajes que deben transportar objetosJava de tipo String en su cuerpo, mientras que ErrorMessage lleva un objetoJava de tipo Throwable que representa un error que se ha producido, e.g., enel procesamiento de un MessageEndpoint. Se envían dichos errores a cana-les creados/configurados especialmente para recibir este tipo de mensaje, yel modelo de Spring Integration permite diseñar procesos para que se puedaconsumirlos.

3.5.2. Modelo

El modelo de Spring Integration permite diseñar soluciones para integra-ción de aplicaciones. Para esto proporciona una biblioteca que se puede uti-lizar en cualquier aplicación Java que se puede ejecutar en Spring. Dicha bi-blioteca está formada por clases e interfaces que se pueden extender y/o di-


rectamente utilizar en el código fuente de una aplicación, aunque también sepueda utilizar de forma declarativa por medio de XML y/o anotaciones. De-bido a esta característica, se puede decir que el modelo proporcionado porSpring Integration es altamente dependiente de tecnología y de bajo nivel. Deforma abstracta y conceptual también se puede decir que una solución de in-tegración diseñada con esta herramienta, nos ofrece además de la vista de lasolución de integración, una vista de proceso y wrapper.

Los procesos tienen topología en forma de árbol, puesto que las tareas queejecutan internamente están encadenadas en un flujo secuencial de ejecuciónel que empieza cuando el MessageBus envía un mensaje a un MessageEnd-point para que lo procese. Las soluciones de integración documentan qué capade la aplicación se esta accediendo para integrarla, pero no queda documen-tado qué aplicación se esta integrando.

El modelo aporta, además de los MessageHandlers y MessageEndpointspara procesar los mensajes, otros objetos con la capacidad de manipular men-sajes, como, e.g., el MessageStore y el ChannelPurger. El MessageStore per-mite guardar y recuperar mensajes desde una base de datos persistente o enmemoria, mientras que el ChannelPurger se utiliza para eliminar mensajes nodeseados de uno o más MessageChannels. Aunque haya la posibilidad deguardar mensajes, los procesos no pueden almacenar su estado.

3.5.3. Puertos

No se han diseñado puertos en la arquitectura de Spring Integration quepuedan recibir y/o enviar mensajes. En esta herramienta el mensaje que lle-ga a un MessageChannel se envía, por medio del MessageBus, a un Messa-geEndpoint para procesarlo. Es decir, el MessageBus es el elemento responsa-ble de transferir los mensajes internamente en la solución de integración. Porotro lado se puede comparar el ChannelAdapters a un puerto de datos, puestoque éste accede el recurso real (Resource), que representa la capa de la aplica-ción, para leer/escribir datos, los que envía/recibe desde un MessageChan-nel. Se puede conectar un ChannelAdapter a solamente un MessageChannelpara enviar/recibir Messages, aunque se pueda tener dos o más ChannelA-dapters conectados al mismo MessageChannel. De esta manera compiten porel Message. La relación que puede haber entre los ChannelAdapters y el Re-source es la misma. Es decir, cada ChannelAdapter sólo accede a un determi-nado Resource, pero el Resource puede ser compartido por dos o más Chan-nelAdapters. Para los casos en que hayan dos o más ChannelAdapters leyendodatos del Resource, entonces compiten por los datos.


Figura 3.15: Taxonomía de las tareas de Spring Integration.

3.5.4. Tareas

La interfaz MessageHandler define el comportamiento común para todaslas tareas, es decir, para todas las implementaciones de MessageHandler quehay en Spring Integration. Aunque esto sea verdad, hay que tener en cuentaque la herramienta también ofrece algunas implementaciones de los patronesde integración, pero que no implementan esta interfaz. Se tratan de algunospatrones que, como, e.g., el MessageMapper, el MessageStore, el Message-Selector y el ChannelPurger, se pueden utilizar en otros elementos del fra-mework. La Figura §3.15 presenta algunos tipos de tareas que implementanMessageHandler; por otro lado, en la Figura §3.13 se puede ver un ejemplo deuso del patrón MessageMapper por el ChannelAdapter, y el MessageSelectorpor el MessageEndpoint.

En general se recibe en las tareas un mensaje entrante, lo procesa y se loenvía hacia adelante. Hay que recordar que las tareas se ejecutan dentro deMessageEndpoints, y que, además, la tarea MessageHandlerChain es una ta-rea especial puesto que permite tener varias tareas internas en secuencia pa-ra ejecutar en el mismo MessageEndpoint. La clase AbstractRoutingMessa-geHandler implementa una tarea que representa un router general y abstractoque sirve como base para los dos grupos de routers soportados por SpringIntegration, a saber: MultiChannelRouter y SingleChannelRouter. El primerorepresenta todos aquellos tipos de router, que como el RecipientListRouter,pueden distribuir un mensaje entrante a varios MessageChannels. Por otrolado SingleChannelRouter representa todos aquellos routers que, como el Pay-loadTypeRouter, acceden la estructura del mensaje entrante para decidir a quéMessageChannel de salida se debe enviar.


Para aquellas tareas que forman parte de una secuencia dentro de unMessageHandlerChain, se puede hacer uso de objetos interceptores entre lastareas. Este recurso es soportado por la tarea llamada InterceptingMessa-geHandler, que también es un tipo de MessageHandler. Además de soportarinterceptores para las tareas, Spring Integration soporta interceptores en losMessageChannels. En este caso se pueden registrar interceptores para ejecu-tar una acción antes de que se envíe o se reciba un mensaje en el Message-Channel, e.g..

3.5.5. Despliegue

La biblioteca aportada por Spring Integration para soportar mensajería yalgunos de los patrones de integración en Spring, permite crear soluciones deintegración que sólo se pueden desplegar y ejecutar en el servidor de Spring.La arquitectura que se adoptó en Spring Integration para transportar y co-municar los procesos de integración (MessageEndpoints), permite una comu-nicación totalmente asíncrona entre dichos procesos. Por otro lado la comu-nicación entre dos o más MessageHandlers ejecutados en un mismo procesosiempre se hace de forma síncrona, puesto que al termino de su ejecución elpropio MessageHandler llama directamente al MessageHandler siguiente y leenvía el Message que él ha procesado.

En Spring Integration, se puede hacer reutilización a nivel de solución, otambién, indirectamente, de proceso (MessageEndpoint). A nivel de procesose hace en los casos en que la solución de integración esté formada solamentepor un MessageEndpoint. Para ello, dos soluciones deben compartir el mis-mo recurso físico (Resource), cada una con su propio ChannelAdapter. Porejemplo, una solución escribe un mensaje en un Resource, desde el que otrasolución puede leer. No se puede reutilizar directamente ningún proceso owrapper de una solución de integración diseñada y desplegada, en otra solu-ción. Cuando el servidor de Spring ejecuta una solución de integración, creaun contexto para la misma. En este contexto contiene, e.g., los canales Messa-geChannels virtuales (en memoria), el MessageBus, los MessageEndpoints,etcétera. Los canales para comunicación son virtuales y no están implementa-dos sobre una tecnología de mensajería, e.g., JMS o MSMQ.

Por tratarse se una simple biblioteca, Spring Integration no ofrece herra-mientas extra para la gestión de la solución ni para visualización de los flujosde integración. Tampoco aporta recursos para autenticación o ejecución de lassoluciones. Esto todo se hace cargo el servidor Spring.

3.6. BizTalk 2006 67

3.5.6. Ejecución

El diseño de Spring Integration se hizo de forma que las aplicaciones querepresentan las soluciones de integración se ejecuten en el servidor Spring. Esel servidor Spring el que se hace cargo de toda la infraestructura de ejecu-ción y, entre otras cosas, del mecanismo de actualización, seguridad, etcétera.Spring es un servidor cuya arquitectura esta muy influida por el modelo In-version of Control [10], y por lo tanto la creación de los objetos que formanparte de la solución de integración se va a hacer de acuerdo con este modelo.En este punto vale la pena recordar el elemento MessageBus, que juega unpapel muy importante en este modelo de ejecución, puesto que es el encarga-do de gestionar de forma transparente para el usuario toda la ejecución de lastareas y el envío y/o recepción de mensajes a/desde los canales. Por lo tanto,para entender a fondo el modelo de ejecución de Spring Integration, se hacenecesario estudiar el servidor Spring, lo que queda fuera de los objetivos deesta memoria.

3.5.7. Miscelánea

Spring Integration, al igual que el servidor Spring, se distribuye con la li-cencia Apache License 2.0. Se puede descargar desde el sitio web oficial delproyecto en http://www.springframework.org/spring-integration. En el mismositio hay una documentación, todavía en fase incipiente de desarrollo, llama-da “Spring Integration Reference Manual”. Dicha documentación fue la únicaque hemos podido encontrar para estudiar esta herramienta. Además, hemosestudiado los códigos fuentes y su documentación Javadoc. Su documenta-ción, puede ser clasificada respecto a la terminación, cf. Apéndice §A, cómo? ?; mientras que la calidad, cf. Apéndice §B, cómo buena. La empresa Spring-Source (http://www.springsource.com) ofrece soporte comercial a Spring Inte-gration. Además de esta empresa, hay listas de discusión y foros en los quese puede participar. Toda la biblioteca, y al igual que los demás productos deSpring, como, e.g., el servidor, se han diseñado para la plataforma Java.

3.6. BizTalk 2006

La herramienta BizTalk 2006 es el producto que Microsoft ofrece para dise-ñar, desplegar, ejecutar y administrar soluciones de integración. Los módulosde diseño y despliegue de las soluciones se integran en el entorno de desarro-llo de aplicaciones Visual Studio, y los demás se ejecutan de forma indepen-

http://www.springframework.org/spring-integration

http://www.springsource.com


Figura 3.16: Modelo conceptual de la arquitectura de BizTalk.

diente, aunque el despliegue también se puede hacer por medio del módulode administración, es decir fuera del entorno de desarrollo.

Una solución de integración en BizTalk puede estar formada por uno omás OrchestrationProcesses, compuestos de .NETComponents, encargadosde procesar todos los mensajes entrantes recibidos por medio de los Recei-vePorts y producir mensajes salientes, que se envían a otros procesos o aplica-ciones por medio de los SendPorts. A pesar de parecer que hay una ligaduradirecta entre los puertos y el proceso de orquestación, generando un acopla-miento directo, en realidad los puertos y proceso de orquestación están des-acoplados. Esto se hace por medio de una base de dados SQL Server llamadaMessageBox, en la que tanto los puertos como los procesos de orquestaciónescriben/leen mensajes de forma asíncrona, cf. Figura §3.16. Todos los proce-sos de orquestación se quedan alojados y se ejecutan en el servidor de BizTalk,representado en la Figura §3.16 por el BizTalkHost. Además, esto no impideque se pueda hospedar diferentes procesos en diferentes hosts y que se comu-niquen entre ellos. La Tabla §3.5 presenta la equivalencia del vocabulario quese utiliza en BizTalk y el que proponemos como estándar, en esta memoria,para el área de integración.

El MessageBox es uno de los componentes más importantes de la arqui-tectura de BizTalk, puesto que es el recurso que se utiliza para intercambiarmensajes. Este componente no solamente almacena los mensajes sino que fun-ciona como un router basado en contenido capaz de distribuir mensajes en-trantes a uno o más interesados. Como ya hemos comentado, no se conectandirectamente los procesos a los puertos para recibir y enviar mensajes, sino

3.6. BizTalk 2006 69

Nuestro vocabulario Vocabulario de BizTalk 2006

Integration solution OrchestrationProcesses + MessageBox + Ports

Integration cloud OrchestrationProcesses + MessageBox

Integration flow –

Building block –

Process OrchestrationProcess

Wrapper Physical port

Compensation block CompensateComponent

Message port Port

Data port Physical port


Location Location

Task .NETComponent

Simple task .NETComponent

Composite task GroupComponent

Slot –

Receive pipeline ReceivePipeline

Send pipeline SendPipeline

Mapper Mapper

Command message Message

Event message Message

Response message Message

System message –

Exchange –

Technology adapter TechnologyAdapter

Application adapter ApplicationAdapter

Channel Transports

Tabla 3.5: Vocabulario de la herramienta BizTalk 2006.

que deben subscribirse al MessageBox. De esta forma cuando el MessageBoxrecibida un mensaje, lo envía al proceso interesado que cumpla su condiciónde subscripción para el mensaje. Lo mismo pasa con los propios puertos, esdecir, un puerto de salida debe subscribirse al MessageBox para que cuan-do haya un mensaje que cumpla dicha condición de subscripción, el puertopueda recibir el mensaje y transferirlo como un mensaje saliente. De acuerdocon [19] cuando hayan dos o más subscripciones (de procesos y/o puertos desalida) para el mismo mensaje, se envía una copia a todas ellas. Esto nos mues-tra claramente que el MessageBox puede funcionar como un simple router,


Figura 3.17: Estructura y taxonomía de los mensajes en BizTalk.

conectando dos o más aplicaciones por medio de puertos y sin ningún proce-so de orquestación. En los casos en que haya la necesidad de hacer algo másentre las dos aplicaciones (el que representa la mayoría de las soluciones deintegración), se puede diseñar un proceso de orquestación que se ejecuta entrelos puertos de entrada y salida de la solución y haga uso de todos los recursosy componentes para los procesos que BizTalk ofrece.

3.6.1. Mensajes

Los mensajes representan los objetos transferidos en una solución de in-tegración, y al llegar a un puerto, permiten activar el proceso de orquesta-ción para procesarlos. El formato más común para los mensajes es XML, peroBizTalk no está limitado solamente a este formato, sino que también permitetransferir mensajes en formato binario u otros que se basan en texto. Aun-que se pueda hacer uso de mensajes en formato binario, se pierde gran partede los recursos ofrecidos por la herramienta BizTalk, como, e.g., el uso delMapper para hacer el mapeo de un formato de datos al otro [19]. Así que lorecomendable es siempre que sea posible utilizar mensajes en formato XML.

La estructura de un mensaje es sencilla, puesto que está compuesta de uncuerpo, un contexto, además de poder contener partes y también poder llevarun tipo. En el cuerpo del mensaje, que es obligatorio, se almacenan los datosque se quieren transferir y sobre los que se puede hacer algún procesamiento,como, e.g., encode, decode, mapper, etcétera. BizTalk también permite que losmensajes lleven adjuntos. Esto permite procesar el cuerpo independientemen-te de los adjuntos, que se ignoran mientras el cuerpo es procesado. La idea deseparar del cuerpo los posibles ficheros adjuntos es, de acuerdo con [19], unabuena practica para disminuir el gasto de procesamiento del mensaje. Ademásde esto, permite el uso de forma más sencilla y directa de algunos formatos es-tándares como, e.g., el Multipurpose Internet Mail Extensions (MIME), el quepermite a los mensajes contener adjuntos.

3.6. BizTalk 2006 71

De acuerdo con la Figura §3.17, un mensaje puede no llevar tipo. Aunqueesto pueda parecer extraño, es totalmente posible puesto que los tipos de losmensajes se representan por los esquemas de datos creados por los usuariosa la hora de definir la estructura del mensaje en formato XML. Es decir, alcrear un esquema de datos para describir un mensaje, su tipo será definidopor el esquema de datos. Por lo tanto como BizTalk permite mensajes tambiénen formato binario, estos mensajes no tendrán tipos. Generalmente se usanmensajes binarios cuando se usa BizTalk como un canal para transmitir datosde un sitio al otro.

Un concepto muy importante en BizTalk es el de inmutabilidad para losmensajes, es decir, después de creados los mensajes no se puede cambiarlos.Se considera el mensaje creado después de que el puerto de entrada lo escribeen el MessageBox. Por lo tanto en caso que haya la necesidad de cambiar elmensaje, se debe crear un nuevo mensaje del mismo tipo y utilizarlo desdeeste punto en adelante. La creación de un nuevo mensaje se puede hacer pormedio de un .NETComponent en el proceso de orquestación. Al definir losmensajes, BizTalk permite promover propiedades y exponerlas en el contextoque va siempre asociado al mensaje, así que los cambios que se quiere hacer enel mensaje ahora se hacen sobre el contexto. Esto permite mantener, duranteel flujo, siempre el mensaje original, además de que se pueden escribir otraspropiedades y valores en el contexto. Por lo tanto el proceso tiene acceso di-recto solamente a las propiedades promovidas que estén en el contexto, y noal mensaje original, el que se queda almacenado en el MessageBox. BizTalktambién hace uso del contexto asociado al mensaje para almacenar alguna in-formación que pueda resultar de interés, como, e.g., el nombre y la direcciónoriginal del fichero leído por el adaptador de ficheros. Esta información quedadisponible en el contexto y puede ser accedida y utilizada más adelante en elpropio pipeline, o en el proceso de orquestación.

3.6.2. Modelo

El modelo para integración proporcionado por BizTalk permite al usuariocentrarse en el diseño del proceso de integración a un nivel de abstracción al-to, sin tener en cuenta casi ningún detalle técnico. Estos detalles, como, e.g.,la tecnología concreta para acceder a las aplicaciones, se proporcionan másadelante en el proceso de despliegue de la solución. Es en este proceso que seindica la capa y aplicación que se va a integrar. Se puede utilizar el procesode orquestación de BizTalk con el objetivo de integrar aplicaciones o solucio-nes Business to Business Integration (B2BI). Este proceso puede ser diseñadode forma visual por medio de un conjunto de .NETComponents ofrecido por


la herramienta, y suele interactuar con puertos de entrada y salida, los quetambién forman parte de la solución. Para esto utiliza dos tipos de .NETCom-ponents especiales, a saber: Receive y Send. El Receive permite recibir unmensaje entrante, mientras que, el Send permite escribir un mensaje salienteen el MessageBox, donde queda aguardando otro proceso o puerto que pue-da recibirlo. Dentro del proceso, se conectan los componentes unos a los otrosen una topología de árbol.

Los puertos y procesos de orquestación, se desacoplan por medio del Mes-sageBox, aunque un proceso puede llamar directamente al otro por medio delos componentes CallOrchestration o StartOrchestration. Mientras el primerocomponente llama otro proceso de orquestación y queda aguardando en elmismo punto de llamada el término del otro proceso, StartOrchestration sim-plemente empieza la ejecución del otro proceso y sigue adelante. Todos loscomponentes tienen una entrada por medio de la que reciben un mensaje yuna salida por la que pueden enviar el mensaje saliente. En el caso que sea ne-cesario enviar el mensaje saliente de un componente a dos o más componentesentonces BizTalk proporciona un componente llamado ParallelActions.

BizTalk soporta transacciones en los puertos, en el proceso de orquestacióny en los .NETComponents. En los puertos, permite crear transacciones (paralos tipos de adaptadores que soportan transacciones) para garantizar que lainformación leída desde la localidad de origen por el adaptador, y procesadapor el pipeline de entrada, sea almacenada con éxito en el MessageBox. Sola-mente en caso que no haya ninguna excepción en este camino, se borra la in-formación de la localidad. Entre el MessageBox y el proceso de orquestacióntambién se puede crear una transacción para garantizar que la informaciónsea borrada del MessageBox si el proceso de orquestación se ejecuta sin nin-gún problema. Para los casos en que haya fallo en la ejecución del proceso, elmensaje seguirá a disposición de otra instancia del proceso o incluso de otroproceso subscrito al MessageBox. BizTalk también permite crear transaccio-nes atómicas en un .NETComponent o asociarle una acción de compensación.Todos los .NETComponents ofrecidos por BizTalk soportan estos dos tipos detransacciones [19].

El modelo de BizTalk para la integración se ha extendido para cinco do-minios específicos de negocio. Dichas extensiones en la herramienta BizTalkse llaman accelerators y dan soporte a ciertos estándares definidos para al-gunos dominios, como, e.g., el acelerador Health Insurance Portability andAccountability Act (HIPAA), el Health Level 7 (HL7), el RosettaNet, etcétera.El primero y el segundo aportan un conjunto de tareas y recursos, a la he-rramienta, enfocados en el diseño de soluciones de integración para el área desalud; mientras que RosettaNet esta enfocado en el área de comercio electróni-

3.6. BizTalk 2006 73

Figura 3.18: Estructura y taxonomía de los puertos de BizTalk.

co. Estos aceleradores facilitan mucho el diseño de una solución de integracióndentro de tales dominios.

3.6.3. Puertos

La estructura de los puertos en BizTalk es compleja. Pueden tener varioscomponentes asociados y hacer algún procesamiento sobre la información,además de transmitirla. Cuatro conceptos son importantes a la hora de en-tender los puertos y su funcionamiento, a saber: Location, Adapter, Pipeline yMapper. Location representa el sitio físico sobre el que se puede implementarun canal para leer o escribir datos. Es decir, es algo físico y pasivo identifica-do siempre por medio de una URI que puede representar, e.g., una direcciónde un sistema de ficheros, base de datos, sistema de mensajería, servidor decorreo electrónico, etcétera. Por otro lado el Adapter es el componente depen-diente de tecnología (File, MSMQ, SOAP, etcétera) que permite crear lectorespara leer datos desde un tipo de localidad, o en el caso de los puertos de sa-lida, que no tienen localidad, crear escritores para escribir directamente losdatos en la URI. Es decir, Adapter es el software que permite crear los cana-les para leer o escribir datos en URIs. Los Pipelines se ejecutan en los canalesque conectan el recurso real y el puerto, y, ofrecen la posibilidad de hacer unprocesamiento extra en los mensajes. Los mensajes entrantes pasan por el pi-


peline de recepción (ReceivePipeline), mientras que mensajes salientes pasanpor el de envío (SendPipeline). Finalmente, el concepto de Mapper represen-ta la posibilidad de ejecutar una transformación de los mensajes entrantes aotro formato antes de publicarlos en el MessageBox, o al igual, transformarlos mensajes salientes a otro formato antes de enviarlos con el SendAdapter.Estas transformaciones que se hacen con el Mapper son transformaciones debajo nivel, es decir, se transforma el formato del mensaje que se recibe/envíaa un formato que el destino (próximo elemento que va recibirlo) pueda enten-der y procesarlo. Por otro lado están las transformaciones de alto nivel que sehacen en los procesos de orquestación, las que se encargan de transformar laestructura de los mensajes.

Los puertos de entrada, cf. Figura §3.18, se componen de una o más lo-calidades y cero o más objetos de mapeo. Se puede conectar una localidadsolamente a un canal, pero el modelo de puertos de entrada de BizTalk per-mite conectar un puerto a varias localidades por medio de canales distintos.Cada localidad tiene su propio pipeline de entrada para realizar un procesa-miento específico. Las actividades que se pueden ejecutar en un pipeline deentrada son: Decode, Disassemble, Validate y ResolveParty. Decode es la ac-tividad responsable por, e.g., decodificar o descomprimir el mensaje y dejarloen un formato que pueda ser procesado en los pasos siguientes del pipeline.Disassemble, en caso que sea necesario usarlo, convierte el mensaje al formatoXML, dejando a cargo del Validate la tarea de validarlo frente a un esquemaXML. Finalmente, el ResolveParty, que se utiliza para identificar al remitentedel mensaje recibido [19].

Los puertos de salida no tienen localidades como las que tienen los puer-tos de entrada, y se conectan directamente a una URI por medio de su canalde escritura proporcionado por el adaptador. Aunque esto sea así, desde unpunto de vista conceptual, se puede decir que los puertos de salida escribensolamente en una localidad, representada aquí simplemente por la URI. Lointeresante en estos puertos es que, al contrario de los puertos de entrada,dos puertos pueden compartir la misma URI para escribir. Al igual que en lospuertos de entrada, los puertos de salida tienen en su estructura un Mappery ejecutan su pipeline de salida sobre el mensaje. Los mismos tipos de adap-tadores disponibles en los puertos de entrada, también están disponibles paralos puertos de salida. El pipeline de salida tiene solamente tres actividades,a saber: PreAssemble, Assemble y Encode. La actividad PreAssemble ejecutacualquier procesamiento que sea necesario para permitir que el mensaje puedaser procesado por las próximas tareas del pipeline. El Assemble es una tareatotalmente simétrica al Disassemble, es decir, transforma el mensaje de forma-to XML a cualquier otro formato, como, e.g., texto puro. Finalmente, Encode,que codifica o comprime el mensaje antes de enviarlo.

3.6. BizTalk 2006 75

Figura 3.19: Tipos básicos de .NETComponents en BizTalk.

Los dos tipos de puertos proporcionados por BizTalk (ReceivePort y Send-Port) tienen una vista lógica y una vista física. A la hora de diseñar el procesode orquestación, BizTalk permite diseñar dichos puertos de forma lógica, esdecir, a un nivel alto de abstracción, sin que haya que configurar los detallesde la forma y tecnología que los puertos van a usar.

Se conectan estos puertos a los .NETComponents del proceso de orquesta-ción para que el proceso pueda recibir y/o enviar mensajes durante su ejecu-ción. Se puede decir que los puertos lógicos siempre transmiten mensajes, en-trantes o salientes. Por otro lado los puertos físicos representan el desplieguede los puertos lógicos, es decir, tienen toda la configuración sobre qué tecno-logía (fichero, base de datos, HTTP, SOAP, etcétera) y cómo se debe acceder aella por medio del adaptadores.

Como hemos presentado en esta sección, los puertos suelen tener una úni-ca dirección, que es o de entrada o de salida. Pero en caso que vayamos autilizar adaptadores que soportan SOAP/HTTP, la herramienta BizTalk ofre-ce la posibilidad de crear un puerto que sea tanto de lectura como de escritura.Para todos los demás tipos de adaptadores, los puertos siempre tendrán unaúnica dirección.

3.6.4. Tareas

Se representan las tareas en BizTalk 2006, de forma genérica, con los .NET-Components. En esta memoria hemos clasificado estos componentes en dostipos: los componentes simples y los compuestos. Un componente simple esaquél que ejecuta una única tarea, mientras que los compuestos son contene-dores de tareas. La Figura §3.19 presenta una jerarquía conceptual de los .NET-Components, mientras que la Figura §3.20 presenta la jerarquía de todos loscomponentes simples y la Figura §3.21 los compuestos. En total, BizTalk pro-porciona 22 componentes para diseñar procesos de orquestación. En generalson específicos para ejecutar una tarea muy concreta y no representan direc-


Figura 3.20: Componentes simples de BizTalk.

Figura 3.21: Componentes compuestos de BizTalk.

tamente los patrones de integración. Sin embargo, cf. Hohpe y Tham en [16],por medio de la combinación de componentes simple y compuestos, se puedellegar a nuevos componentes más complejos o hasta implementar algunos delos patrones de integración.

3.6.5. Despliegue

Se puede desplegar una solución de integración diseñada en BizTalk, bá-sicamente, de dos formas. La primera, quizá la más sencilla para el desarro-llador, sea desplegarla directamente desde la herramienta de diseño integradaen Visual Studio. La segunda es por medio de la herramienta BizTalk ServerAdministration que forma parte del paquete BizTalk. Ambas alternativas des-pliegan la solución con la tecnología .NET en el servidor BizTalk.

En la herramienta de diseño se pueden hacer todas las configuraciones dedespliegue tanto para los puertos (entrada y salida) como para el proceso deorquestación. Después de hacer dichas configuraciones, la herramienta per-mite empaquetar toda la solución en un fichero .msi que se puede desplegardirectamente en el servidor BizTalk. Los desarrolladores suelen utilizar este

3.6. BizTalk 2006 77

tipo de despliegue en fase de pruebas, puesto que les permite rápidamenterealizar la tarea y probar la solución. La herramienta también permite empa-quetar la solución de integración sin que haya terminado de hacer todas lasconfiguraciones de despliegue. En estos casos antes de poder ejecutar dichasolución, se debe terminar el proceso de despliegue en la herramienta BizTalkServer Administration. Esta herramienta también permite iniciar y parar unasolución que esté desplegada y ejecutando, además de cambiar las propieda-des de despliegue y volver a desplegarla y ejecutarla.

Para los casos que se va a hacer el despliegue en el servidor de producciónde la empresa, la segunda opción de despliegue es la más utilizada puesto quepermite transportar y desplegar fácilmente la solución. Para esto el adminis-trador del servidor debe recibir un fichero .msi e importarlo en la herramientaBizTalk Server Administration. En caso que la solución de integración empa-quetada esté con la configuración de despliegue terminada y correcta, se pue-de arrancarla en el servidor. Con esta herramienta se puede, también, exportaruna solución que ya esté desplegada en el servidor directamente en un fichero.msi.

Además de estas herramientas, BizTalk ofrece otra para gestión de las solu-ciones, llamada Business Activity Monitoring (BAM). De acuerdo con [19] estaherramienta proporciona una vista avanzada de la solución de integración alos desarrolladores, administradores y a los demás participantes involucradosen el proceso de negocio representado por la solución de integración. La he-rramienta BAM permite definir, para cada uno de estos perfiles, una vista afin de proporcionar una visión particular de la ejecución de la solución. Se al-macenan en una base de datos SQL Server los datos recogidos por BAM y sepuede consultarlos, fácilmente, con cualquier aplicación externa. Además delBAM, BizTalk proporciona un bus de mensajería, representado en gran partepor el MessageBox. La herramienta esta diseñada para que cuando una apli-cación externa que se quiere integrar exija autenticación, se pueda hacer estode forma sencilla simplemente configurando los adaptadores.

El servidor de BizTalk ejecuta una o más soluciones de integración a lavez. Una solución desplegada puede estar compuesta de uno o más procesosde orquestación. La comunicación entre dos o más procesos de orquestaciónque formen parte de la misma solución puede ser síncrona o asíncrona. En loscasos síncronos un proceso llama directamente el otro por medio de un .NET-Component; la comunicación asíncrona se da cuando un proceso escribe enel MessageBox un mensaje de salida que sirve de entrada para otro proceso.Por otro lado, la comunicación entre dos o más procesos de orquestación queforman parte de soluciones de integración diferentes siempre se da de formaasíncrona. En estos casos, el proceso de una solución escribe el mensaje en el


MessageBox y el otro proceso de la otra solución puede recibirlo en caso queesté subscrito al mismo. Los recursos proporcionados por BizTalk permitenla reutilización tanto de los procesos de orquestación directamente, como unasolución de integración que ya esté desplegada. Los puertos físicos de salidapueden ser compartidos por dos o más puertos lógicos de salida, es decir, sepuede desplegar dos o más puertos lógicos de salida sobre el mismo puertofísico cuando se quiere reutilizar la misma URI. La reutilización a nivel de so-lución es posible, puesto que una solución de integración puede ser formadasolamente por un proceso. En estos casos, proceso y solución representan lomismo.

3.6.6. Ejecución

Se puede ejecutar una solución de integración diseñada con BizTalk en elBizTalk Server. El servidor puede detectar cuándo un proceso de orquestaciónno esté ejecutándose y, e.g., esperando un mensaje. En estos casos mantenerel proceso parado en memoria puede consumir muchos recursos. Esto suelepasar en los casos en que un proceso haya hecho una llamada síncrona a otroy, esté aguardando otro mensaje en uno de sus puertos de entrada, o ejecu-tando una tarea Delay. En estos casos, con el objetivo de ahorrar recursos enla maquina, la instancia del proceso de orquestación puede ser descargada yguardada en el MessageBox. A este proceso se le llama deshidratación. Cuan-do llegue el mensaje o pase el tiempo de retraso, la ejecución podrá seguir.Para esto el servidor tendrá que recargar la instancia del proceso de orquesta-ción en memoria. A este proceso se le llama rehidratación.

Los desarrolladores pueden y deben realizar pruebas de las soluciones an-tes de desplegarlas en el servidor. BizTalk ofrece un framework para escri-bir pruebas llamado BizUnit [19]. Las pruebas pueden ser escritas en VisualStudio y ejecutadas en la herramienta Unit Testing o NUnit. En caso que pa-se la prueba la solución puede ser desplegada en el servidor de producción.La actualización de una solución de integración, esa sea total o parcial, exi-ge del administrador parar primero la ejecución para que la nueva versiónpueda ser desplegada. BizTalk también proporciona una herramienta llamadaHealth and Activity Tracking (HAT), la que permite ver cuáles son los men-sajes y procesos de orquestación que en un determinado momento están en elMessageBox. Además, con esta herramienta se pueden ejecutar algunas tareasadministrativas, como, e.g., suspender y terminar una instancia de un procesoo ver el histórico de ejecución del proceso de orquestación y de los mensa-jes. De acuerdo con [19], esta herramienta puede ser utilizada para depurarvisualmente un proceso de orquestación.

3.7. Sumario 79

3.6.7. Miscelánea

La herramienta BizTalk es distribuida con una licencia propietaria de Mi-crosoft en cuatro ediciones, a saber: Enterprise, Standard, Branch y Developer.Una gran diferencia entre ellas está, además del precio, en la cantidad de solu-ciones de integración que se pueden desplegar en el servidor y en la cantidadde procesadores que se puede tener en el ordenador que va a ejecutar el servi-dor. Para el estudio de la herramienta se puede encontrar mucha informacióny de buena calidad en la propia documentación que acompaña el producto, endiversos libros, o en el sitio web oficial del producto. Por lo tanto su documen-tación, puede ser clasificada respecto a la terminación, cf. Apéndice §A, cómo? ? ? ? ?; mientras que la calidad, cf. Apéndice §B, cómo excelente. Además devender el producto Microsoft ofrece servicio de consultoría sobre BizTalk.

3.7. Sumario

En este capítulo hemos analizado algunas de las herramientas más signifi-cativas para diseñar soluciones de integración del tipo Enterprise ApplicationIntegration (EAI), o incluso, Business to Business Integration (B2BI). Hemosvisto que se trata de propuestas en algunos casos muy diferentes en diversosaspectos una de la otra, como es el caso, e.g., de Apache Camel y MicrosoftBizTalk 2006. Además de la diferencia que puede haber en las arquitecturas,hay tecnologías que aportan un conjunto variado y completo de herramientaspara soportar todo el proceso de diseño, prueba, despliegue, ejecución, ges-tión, etcétera, de la solución de integración.

Parte III

Nuestra propuesta

Capítulo 4

Metamodelo Guaraná

G uaraná es una propuesta de un metamodelo para diseñar solucionesde integración de aplicaciones. Su objetivo es resolver las deficiencias

encontradas en las principales herramientas actuales estudiadas. En la Sec-ción §4.2, presentamos la estructura de una solución de integración diseña-da con Guaraná; en la Sección §4.3, presentamos la estructura y la taxonomíade los mensajes; en la Sección §4.4, presentamos los bloques de construcciónque forman parte de la solución; en la Sección §4.5, presentamos los puertospropuestos por este metamodelo; en la Sección §4.6, presentamos el conjun-to de tareas que implementan patrones de integración; finalmente, en la Sec-ción §4.7, un ejemplo de un diseño de solución de integración para un estudiode caso real.

84 Capítulo 4. Metamodelo Guaraná

Figura 4.1: Niveles y vistas en Guaraná.

4.1. Introducción

El metamodelo Guaraná se ha diseñado para dar soporte al diseño de so-luciones de integración de aplicaciones. Está compuesto por varios elementos,que de forma conjunta describen en detalle la arquitectura de una soluciónde integración de aplicaciones. Guaraná trata aspectos relativos a las posiblesvistas que se puede tener en una solución de integración, a los mensajes quese intercambian y que permiten a las aplicaciones comunicarse, a los tipos debuilding blocks que representan unidades capaces de procesar los mensajes,a los puertos y tareas que forman parte de dichas unidades, etcétera. Para es-ta memoria de investigación, hemos escogido las partes más importantes delmetamodelo, con el objetivo de dar una visión general de la propuesta.

4.2. Estructura de la solución de integración

Una solución de integración diseñada con Guaraná puede ser dividida entres niveles, que proporcionan cinco vistas, cf. Figura §4.1. En el primer nivel,y más abstracto de todos, se encuentra la vista de la solución de integración;en el segundo nivel, están las vistas de las aplicaciones integradas y de la nubede integración; y, finalmente, en el nivel más bajo, se encuentran las vista dewrapper y proceso. Estos niveles y vistas son lógicos, y los proponemos paraayudar a entender y diseñar una solución de integración. La Figura §4.2 pre-senta en más detalle la estructura de una solución de integración, descrita porel metamodelo.

4.2. Estructura de la solución de integración 85

Figura 4.2: Estructura de la solución de integración en Guaraná.

IntegrationSolution es el elemento del metamodelo que representa toda lasolución de integración. Una solución de integración está formada por unaúnica nube de integración, representada por IntegrationCloud, y un conjuntode Wrappers. Los Wrappers permiten conectar una aplicación y/o fuente dedatos externas a la solución de integración; mientras que la nube de integra-ción aglutina la parte más destacada de una solución de integración, es decir,los procesos (Process) que se han diseñado para esta solución, otros proce-sos ya desplegados que forman parte de otras soluciones y que pueden serreutilizados como servicios (ServiceProxy), y, finalmente, los canales (Integra-tionLinks) que permiten conectar de forma lógica procesos y servicios. Integra-tionFlow representa todo el flujo que hay entre un Wrapper que conecta unaaplicación fuente (desde la que se lee información), hasta otro(s) Wrapper(s)que conecta(n) la(s) aplicación(es) destino (a la que se envía la información).Desde este punto de vista, se puede decir que es un subconjunto de la nube deintegración, puesto que la nube puede estar formada por varios flujos.

De acuerdo con nuestra experiencia, el diseño de una solución, para resol-ver un problema de integración en una empresa, suele involucrar en la vistade nube varios elementos Process y ServiceProxy conectados por Integration-Links. Además, tantos Wrappers como sea necesario para conectar las aplica-ciones involucradas. Aunque una buena parte de las soluciones de integraciónestén de acuerdo con esta percepción, hay que tener en cuenta que una solu-ción también puede ser muy pequeña y sencilla. La solución más pequeñay sencilla que se puede diseñar con Guaraná, está formada apenas por dosWrappers y un IntegrationLink en la nube que los conecta, permitiendo así sucomunicación.


Figura 4.3: Mensajes y exchanges en Guaraná.

4.3. Mensajes

En una solución de integración diseñada con Guaraná, todo lo que fluyeentre las aplicaciones integradas son objetos de tipo TransferObject. El Transfe-rObject, cf. Figura §4.3, es la representación más general para cualquier tipo deMessage y Exchange, y por lo tanto reúne todo que hay de común entre ellos.En especial, TransferObject lleva una referencia a un objeto de tipo Header. Eseobjeto representa su cabecera y puede contener una variedad de atributos coninformación sobe el objeto que se transfiere, como, e.g., un identificador úni-co del objeto, un identificador de correlación, la dirección de retorno, etcétera.Además de estos atributos, se puede destacar el compensator y el parents. Elprimero lleva una referencia a un servicio que se ha diseñado y desplegadopor separado para tratar de compensar un eventual error en el procesamientodel TransferObject; el segundo lleva una lista de otros objetos TransferObjectque puedan haber dado origen al objeto actual. En las soluciones de integra-ción es común crear un TransferObject a partir de la agregación de otros, oincluso, romperlo para crear a partir de uno, dos o más TransferObjects.

Message representa un tipo ya más específico de TransferObject. En su es-tructura, define un cuerpo (Body) y una colección de adjuntos (Attach). Mien-tras el cuerpo lleva información que puede sufrir algún procesamiento en lasolución, la información que se almacena en los adjuntos no sufre ningún pro-

4.3. Mensajes 87

cesamiento. Message sirve de base para otros tres tipos más específicos demensaje, a saber: ActionMessage, ResponseMessage y SystemMessage.

ActionMessage Un mensaje de acción representa un objeto que se envía des-de un punto al otro con dos objetivos. El primero es transmitir informa-ción de notificación sobre algo que ha pasado, lo que se hace por mediode un tipo más específico de mensaje llamado EventMessage. El segun-do objetivo es enviar un mensaje que representa una petición para quese ejecute algo en el destino, lo que se hace por medio de un Command-Message.

ResponseMessage La petición enviada por medio de un CommandMessa-ge puede exigir del destino el envío de una respuesta. Para esto el meta-modelo proporciona el tipo de mensaje ResponseMessage. Sólo se pro-duce este tipo de mensaje como una reacción de respuesta a una peticiónhecha por medio de un tipo de CommandMessage.

SystemMessage Este tipo de mensaje representa de forma general cuatro ti-pos concretos que se utilizan a nivel de infraestructura de la solución deintegración. ErrorMessage representa un error que se ha producido enla ejecución de un building block de la solución de integración. Se in-terrumpe el procesamiento del TransferObject que ha generado el error.WarningMessage representa un mensaje de aviso que se ha producido alejecutar un building block, pero no se interrumpe el procesamiento delTransferObject. La solución de integración puede estar configurada paraproducir en determinados building blocks, información sobre su ejecu-ción y añadirla en un mensaje de tipo InformationMessage. Finalmente,un building block puede estar configurado para en caso de que produzcaun error en el procesamiento de un TransferObject, enviar un mensaje detipo CompensationMessage al ServiceProxy configurado en la cabeceradel mensaje en el atributo compensator. CompensationMessage permiteactivar y ejecutar las acciones de compensación.

Guaraná proporciona soporte al uso de Message Exchange Patterns(MEPs) [30], por medio de los elementos Exchange y ExchangePattern, cf. Fi-gura §4.3. El Exchange es un tipo de TransferObject, pero a su vez permitellevar en su estructura cero o más mensajes de entrada (in) de tipo ActionMes-sage, cero o más mensajes de retorno (out) de tipo ResponseMessage y ceroo más mensajes de sistema (sys) de tipo SystemMessage. Aunque el Exchan-ge permita llevar todos estos tipos de mensajes, el uso de ellos depende detipo de MEP que se va a implementar para la comunicación. ExchangePatternrepresenta un determinado tipo de MEP.


Figura 4.4: Building blocks en Guaraná.

Figura 4.5: Representación gráfica de los wrappers en Guaraná.

4.4. Building blocks

Uno de los elementos centrales de la arquitectura del metamodelo es elBuildingBlock, cf. Figura §4.4. Dicho elemento representa, de forma general,un bloque de construcción que forma parte de una solución de integración.Estos bloques contienen internamente una tarea (Task), capaz de ejecutar ló-gica de negocio sobre mensajes (Sección §4.6). Para recibir y enviar mensajes,

4.4. Building blocks 89

Figura 4.6: Representación gráfica de los procesos en Guaraná.

Figura 4.7: Representación gráfica de los service proxies en Guaraná.

los BuildingBlocks tienen puertos de mensajes, al menos uno de entrada (En-tryPort) y/o de salida (ExitPort). Un BuildingBlock también puede estar aso-ciado a elementos StateStores que le permiten guardar su estado en mediospersistentes de almacenamiento. Guaraná proporciona tres tipos concretos deBuildingBlock, a saber: CompensationBlock, Wrapper y Process.

CompensationBlock representa un proceso que se ha diseñado, exclusiva-mente, para consumir mensajes de tipo CompensationMessage, y por lo tantoejecutar una acción de compensación para otro BuildingBlock (Wrapper o Pro-cess) que forma parte de la solución de integración. Incluso permite, aunqueque no sea el uso más frecuente, ejecutar una acción de compensación para unposible fallo en la ejecución de otro CompensationBlock. Esta posibilidad sedebe a que todos los tipos de BuildingBlocks pueden llevar una referencia a unCompensationBlock, cf. Figura §4.4.

El Wrapper es el segundo tipo de BuildingBlock proporcionado por Gua-raná. Cómo ya sabemos, los Wrappers permiten conectar una aplicación, ofuente de datos externa, a la solución de integración. La comunicación entreestos recursos externos y el Wrapper se hace por medio de puertos de datos.En un Wrapper hay que tener por lo menos un puerto de datos y un puerto demensaje. Los puertos de datos son una característica exclusiva de los Wrapper,y pueden ser de tres tipos, a saber: SinkPort, SourcePort y RequestReplyPort.La Figura §4.5 presenta la representación gráfica de un Wrapper con un puer-to de datos y un puerto de mensaje. En la Sección §4.5, se presentan en los


Figura 4.8: Tipos de puertos en Guaraná.

detalles estos tipos de puertos.

Los procesos que forman parte de una solución de integración, y, que sehan diseñado para ejecutar la lógica de negocio de la solución, se representanpor medio de bloques de tipo Process. Mientras la intención de un Compen-sationBlock es representar un proceso para tratar fallos, la del Wrapper conec-tar un recurso externo (aplicación o fuente de datos) a la solución, la inten-ción de un Process es ejecutar uno o más procesamientos sobre los mensajesque fluyen en la solución de integración. Los Processes forman parte del flujonormal de ejecución de un mensaje en la solución y se comunican con otrosProcesses y Wrappers por medio de puertos de mensaje e IntegrationLinks.La representación gráfica de un Process se puede ver en la Figura §4.6. Lamisma representación se utiliza para los CompensationBlocks. Por otro ladola representación gráfica de un ServiceProxy, que permite utilizar un Processo CompensationBlock ya desplegado en una solución de integración, se la en-seña en la Figura §4.7.

4.5. Puertos

En Guaraná, toda la información que se recibe de un recurso externo, fluyeinternamente y se envía a otro recurso externo, pasa por puertos. Estos puer-tos están representados, de forma general, por el elemento Port, cf. Figura §4.8.Este elemento, a su vez, da origen a dos tipos distintos de puertos, uno cen-trado en la comunicación con los recursos externos que se están integrando yotro enfocado a la comunicación entre los BuildingBlocks que forman parte dela solución de integración. DataPort representa los puertos encargados de estacomunicación con los recursos externos a la solución y por lo tanto transfieresolamente datos. Consideramos un dato la información que esta fuera de lasolución de integración, es decir, los datos brutos que se leen o que se escri-ben en una localidad. Por otro lado, MessagePort es el encargado de toda la

4.5. Puertos 91

Figura 4.9: Puertos de mensajes en Guaraná.

comunicación que hay internamente en la solución de integración.

Los MessagePorts se pueden usar en todos los tipos de BuildingBlocks, lle-van tipo y sólo transfieren objetos concretos de tipo TransferObject. En Gua-raná, el término mensaje se refiere a cualquier tipo de TransferObject, aunquehaya un tipo de TransferObject también llamado Message. El tipo de un puer-to se puede usar para limitar los mensajes que se reciben en un BuildingBlocko incluso para implementar el patrón Selective Consumer [17] en un bloque.En cualquier caso, el tipo de un puerto puede ser TransferObject y entoncespermite que se reciba o envíe cualquier tipo de mensaje. En estos casos, elcomportamiento es semejante al de las herramientas que no ofrecen puertostipados. Hay dos tipos concretos de MessagePort, a saber: EntryPort y Exit-Port.

Los EntryPorts reciben mensajes desde uno o más Processes y/o Wrappersy los escriben en Slot. El Slot representa un buffer interno que se utiliza en losBuildingBlocks para desincronizar la ejecución de dos tareas, o una tarea y unpuerto. Los Slots son pasivos, y, simplemente, almacenan los mensajes mien-tras la próxima tarea o puerto no puede procesarlos. Un puerto de mensaje deentrada escribe un mensaje entrante en un Slot, desde el que la primera tareainterna lo lee; por otro lado el puerto de salida lee desde un Slot un mensajesaliente que se ha producido por la última tarea del BuildingBlock. Dentro deun BuildingBlock pueden haber tantos Slots como sea necesario. Un EntryPortpuede ser pasivo o activo. Cuando es activo, es responsable de chequear losIntegrationLinks, a los que está conectado para ver si hay nuevos mensajes para


Figura 4.10: Comunicación entre puertos en Guaraná.

recibir; mientras que si es pasivo, entonces solamente aguarda que le envíenmensajes. El ExitPort se encarga de enviar mensajes a uno o más Processesy/o Wrappers. De igual forma puede ser activo o pasivo. Cuando es activo,automáticamente envía los mensajes a los IntegrationLinks con los que está co-nectado; mientras que en los casos en que es pasivo aguarda que otro puertoconsuma sus mensajes.

Un IntegrationLink representa la conexión lógica entre puertos de mensajede entrada (EntryPort) y de salida (ExitPort), cf. Figura §4.10. Un puerto demensaje de entrada puede estar ligado a varios puertos de mensaje de salida,lo que le permite recibir mensajes de dos o más BuildingBlocks distintos. Inte-grationLink sólo existe en el modelo independiente de plataforma (PIM) de lasolución de integración. En el modelo dependiente de plataforma (PSM), esteelemento se transforma en un canal físico y real de comunicación, además deuna localidad en la que se almacenan los mensajes para desincronizar dichacomunicación entre los BuildingBlocks. En este caso, la localidad representaun recurso real creado especialmente para la solución de integración, y no unrecurso externo que se esta integrando por medio de la solución.

Los DataPorts sólo existen en los Wrappers y siempre están asociados a unelemento decorador de tipo ApplicationLayer, cf. Figura §4.11. Este elementorepresenta el recurso externo que se está integrando por medio de la soluciónde integración, y, por lo tanto, permite documentar de forma clara qué capay aplicación se integra. Aunque una aplicación no haya sido diseñada tenien-do en cuenta la integración, consideramos que las principales capas que sepuede acceder en estos casos son: la capa de interfaz de usuario, la capa con-troladora de una aplicación diseñada de acuerdo con el patrón Model ViewController (MVC) [9], la capa reglas de negocio, la capa de acceso a los da-

4.5. Puertos 93

Figura 4.11: Puertos de datos en Guaraná.

tos, la capa de datos, y, finalmente, los canales de un sistema de mensajeríaque sirven de capa de comunicación con la aplicación. La comunicación conestos recursos externos está basada, tan sólo, en la lectura y/o escritura dedatos brutos. Además, no hay, como en los MessagePorts, una comunicaciónentre dos o más DataPorts. Tampoco hay comunicación directa entre un Data-Port y un MessagePort, puesto que, el propósito de los DataPorts es tan sólopermitir esta comunicación de los Wrappers con el recurso externo. Guaranáproporciona tres implementaciones de DataPort, a saber: SinkPort, SourcePorty RequestReplyPort.

Antes de describir en detalle las distintas implementaciones de DataPorts,es muy importante entender el sentido del flujo de mensajes en dos de estostipos de puertos, además de lo representan para un Wrapper. Para dejar estoclaro, utilizamos la metáfora de un fregadero, cf. Figura §4.12. En esta me-táfora, el Washbasin representa un Wrapper de una solución de integración;Source tap, representa la pieza que permite al Washbasin recibir agua desdesu exterior. En este caso, el agua siempre fluye para dentro del Washbasin, yel Source tap sirve de fuente de agua para el Washbasin. Para enviar el aguaque se encuentra en un Washbasin hacia su exterior, se utiliza un Sink. Estapieza simplemente transfiere el agua de dentro del Washbasin para el exterior,proporcionando al Washbasin un flujo únicamente de salida. En el mundo dela integración, podemos comparar el Source tap al SourcePort; el Sink al Sink-Port; y, el Water a los mensajes.


Figura 4.12: Metáfora de un fregadero.

SinkPort es el tipo de puerto que se utiliza para enviar datos a un recursoexterno. Para esto el puerto lee mensajes desde un Slot interno al Wrapper,pasa los mensajes por un pipeline de salida (SendPipeline) que, entre otrascosas, transforma la información que se lleva en el mensaje a un formato dedatos compatible con el recurso y los escribe en el recurso. La transformaciónse lleva a cabo por medio de un Mapper, el que se encarga de transformardatos en mensajes y viceversa [17]. Por otro lado, la escritura de los datos sehace por medio de un Adapter, totalmente dependiente del tipo del recurso.Los ApplicationAdapters permiten una comunicación de más alto nivel, consistemas grandes enteros, como, e.g., con el ERP Peoplesoft; mientras que losTechnologyAdapters proporcionan una comunicación de más bajo nivel conlos recursos externos y permiten realizar operaciones de bajo nivel. Aunqueproporcionan niveles diferentes para la comunicación, ambos escriben datosen el mundo exterior de la solución de integración. El SendPipeline proporcio-na la ejecución de un procesamiento en serie sobre la información saliente, quesuele empezar con el mapeo hecho por el Mapper y terminar con el envío dedatos que se hace por medio del Adapter. Aunque estas sean las operacionesmás comunes, el SendPipeline también permite otras, como, e.g., codificacióno compresión de la información, validación, autentificación del remitente, et-cétera.

De forma simétrica a SinkPort, SourcePort proporciona una entrada de in-formación para la solución de integración. Los datos leídos o recibidos pasanpor un ReceivePipeline, que al principio les transforma en mensaje, ejecutacualquier otro pre procesamiento sobre el mensaje y al final el puerto escribe

4.6. Tareas 95

Figura 4.13: Tipos de tareas en Guaraná.

el mensaje en un Slot interno del Wrapper, desde el que alguna tarea puedaleerlo. Cada SourcePort sólo escribe el mensaje entrante con los datos origina-les en un Slot. En caso que se necesite replicación, el metamodelo aporta tareasespecíficas para esto, descritas en la Sección §4.6.

El tipo de puerto RequestReplyPort representa un puerto bidireccional,compuesto internamente por un SinkPort y un SourcePort. El propósito deese puerto es ofrecer soporte a las comunicaciones que involucren una peti-ción y una respuesta síncronas que se hace y se debe recibir en el mismo puer-to. En estos casos el puerto RequestReplyPort lee un mensaje que representala petición al recurso externo desde un único Slot interno al Wrapper, lo en-vía por medio de un SendPipeline al recurso externo y se queda aguardandola respuesta. El puerto no puede procesar otro mensaje saliente de petición,mientras no se recibe la respuesta del recurso externo. Por lo tanto todos losdemás mensajes salientes de peticiones se quedan almacenadas en el Slot. Alrecibir la respuesta, se pre procesa por medio del ReceivePipeline y al final seescribe el mensaje resultado en otro Slot interno del Wrapper. En función desu comportamiento, un puerto RequestReplyPort utiliza dos pipelines y dosSlots.

4.6. Tareas

Las tareas en Guaraná, a las que se representa de forma general por Task,cf. Figura §4.13, son las que proporcionan el diseño de lógica de negocio den-


Figura 4.14: Grupos de tareas simple en Guaraná.

tro de los BuildingBlocks que forman parte de la solución de integración. Unatarea puede leer mensajes desde uno o más Slots, ejecutar procesamiento so-bre el mensaje y luego escribir el/los mensaje(s) saliente(s) en uno o más Slotsde salida. Además, una tarea puede ejecutar una pre/pos condición, repre-sentada en el metamodelo por medio de la relación entre Task y Condition. Enel segundo nivel de clasificación de Task, se encuentran SimpleTask y Com-positeTask. Mientras SimpleTask representa una tarea que puede ejecutar unprocesamiento atómico sobre un mensaje, se ha introducido CompositeTaskpara proporcionar soporte al patrón composite [14] y, por lo tanto, permitirque una tarea pueda ejecutar dos o más procesamientos. Eso es lo que repre-senta la asociación que hay entre CompositeTask y Task.

El metamodelo divide SimpleTask en tres subgrupos distintos de tareas,aunque no esté limitado, y, por lo tanto, permite añadir nuevos subgruposa la jerarquía. Los subgrupos aportados por Guaraná son Router, Transfor-mer y Constructor, cf. Figura §4.14. En el grupo de los Routers se encuentranaquellas tareas que de forma general tienen el comportamiento de enrutar unmensaje entrante a cero o más Slots de salida. Algunas de ellas, para ejecu-tar su funcionalidad, pueden necesitar guardar estado entre una y otra ejecu-ción. Tales tareas implementan la interfaz Stateful. Por otro lado, se marcanlas tareas que no pueden guardar estado con la implementación de la inter-faz Stateless. Forman parte del grupo de los Routers nueve tareas concretas,cf. Figura §4.15, y se presentan sus iconos en la Tabla §4.1. Las tareas del gru-po de los Transformers son tareas que permiten hacer transformaciones en losmensajes entrantes. Dichas transformaciones pueden ser a nivel de contenidodel cuerpo, cambio en la cabecera del mensaje o, incluso, descargar/recargartemporariamente parte del contenido del cuerpo, cabecera y/o adjuntos. Lasseis tareas que forman parte de este grupo implementan la interfaz Stateless,cf. Figura §4.16. En la Tabla §4.2 se presentan sus iconos. Finalmente, el grupode los Constructors reúne tareas que después de su ejecución, producen uno omás nuevos mensajes de salida, es decir, mensajes que llevan un nuevo iden-

4.7. Ejemplo 97

Figura 4.15: Tareas de tipo routers en Guaraná.

Icono Nombre Icono Nombre

Distributor Resequencer

Filter RoutingSlip

IdempotentTransfer SmartProxy

Merger Synchronizer

Replicator

Tabla 4.1: Iconos de las tareas routers en Guaraná.

tificador. Este grupo esta formado por cuatro tareas, de las que dos puedenguardar estado, cf. Figura §4.17. En la Tabla §4.3 se presentan sus iconos. Elmetamodelo Guaraná no limita estos grupos a las tareas proporcionadas demomento, sino que esta diseñado de forma que se pueda crear nuevas tareasatómicas desde los grupos y tareas actuales, o incluso, se crear nuevas tareascompuestas que puedan ser reutilizadas en forma de plantilla.

4.7. Ejemplo

La Figura §4.18 presenta una solución de integración de cinco aplicaciones,que forman un ecosistema software real de gestión de llamadas telefónicas de


Figura 4.16: Tareas de tipo transformadores en Guaraná.


ClaimCheckEnricher HeaderEnricher

ClaimCheckReducer Slimmer

ContentEnricher Translator

Tabla 4.2: Iconos de las tareas transformadoras en Guaraná.

Figura 4.17: Tareas de tipo constructores en Guaraná.

4.7. Ejemplo 99


Aggregator Splitter

CustomTask Timer

Tabla 4.3: Iconos de las tareas constructoras en Guaraná.

Figura 4.18: Ejemplo de diseño de solución de integración con Guaraná.

la Universidad de Ijuí (UNIJUÍ). En esta universidad los empleados que tie-nen una clave pueden acceder cualquier terminal telefónico, en cualquiera delas ciudades donde está la universidad y hacer una llamada. Se registran to-das las llamadas en la base de datos del Call Center System (CCS), y al fin delmes el empleado tiene que, por medio de otro sistema que no se presenta eneste ejemplo, decir cuáles fueron hechas por razones de trabajo y cuáles fue-


ron llamadas privadas. Las privadas tendrán que ser pagas por el empleadoal fin del mes. Forman parte de este ecosistema, aplicaciones muy distintas ydesarrolladas con diferentes tecnologías. Nuestro objetivo en este caso ha sidodiseñar una solución de integración para hacer que todas las llamadas telefó-nicas registradas por CCS en su base de datos y que tengan algún coste parala universidad, sean también, registradas en el sistema de gestión de costosde la universidad, el Debit System (DS). Además de registrar dichas llamadasen el DS, algunas informaciones de la llamada (e.g.: coste, hora de la llamada,ciudad y número de destino) son enviadas por SMS y/o correo electrónico alusuario que la hizo.

Destacamos tres aspectos importantes de este ecosistema:

Aplicaciones: La característica común de todas las aplicaciones integradas esque constituyen sistemas independientes que fueron desarrollados sinpensar nunca en la posibilidad de que tuvieran que ser integrados conotros. Esto implica que no proporcionan interfaces de programación, porlo que en el caso del Human Resource System (HRS) es necesario accederdirectamente a su base de datos, mientras que en el caso del Call CenterSystem, que es un sistema propietario, es necesario interactuar a travésde su interfaz de usuario usando un sistema de wrapping [1].

Brechas: Las principales brechas a salvar están relacionadas con la tecnología,los modelos de datos y la representación de los mismos. En este ecosiste-ma, hemos encontrado una amplia variedad de tecnologías, desde basesde datos a las que se puede acceder mediante JDBC hasta interfaces deprogramación que utilizan protocolos propietarios. No es de extrañar,pues, que los modelos de datos usados sean completamente dispares ysean necesarias con frecuencia transformaciones tanto en el esquema co-mo en la representación de los datos.

Restricciones: Las aplicaciones integradas no han sufrido ningún cambio. Es-ta restricción ha sido motivada en unos casos por el hecho de tratarse deaplicaciones propietarias como el Call Center System; en otros porqueel coste de la reingeniería necesario para que ofreciesen una interfaz deprogramación más adecuada era inasumible. Otra restricción importan-te ha sido mantener las aplicaciones integradas completamente desin-cronizadas con el objetivo de que puedan continuar siendo operadas yadministradas de forma completamente independiente.

Todas las aplicaciones se conectan a la solución de integración por mediode Wrappers. El decorador (20) simplemente documenta qué aplicaciones seestá integrando y qué capa de la aplicación se está accediendo. Hay dos tipos

4.7. Ejemplo 101

de líneas en el diseño de la solución: continuas y discontinuas. Las continuasrepresentan los IntegrationLinks; mientras que las discontinuas, los Slots.

El flujo de integración para esta solución de ejemplo, empieza en el Wrap-per de la aplicación CCS. En este conector la tarea Timer (1) se ejecuta auto-máticamente a cada 2 minutos, crea un menaje de activación que se lo envía alSlot que comunica con el puerto de datos RequestReplyPort (2). El objetivo deeste mensaje es hacer que el puerto de datos consulte la aplicación CCS y leatodas aquellas llamadas almacenadas en su base de datos interna. El retornodel puerto de datos es un único mensaje que puede contener varias llamadasde varios usuarios. El puerto escribe este mensaje en el otro Slot que lo conectaal Splitter (3). Esta tarea rompe el mensaje original y produce para cada llama-da un nuevo mensaje, que se lo envía al puerto de mensaje ExitPort (4), pormedio del Slot que los conecta.

La comunicación entre el Wrapper de la aplicación CCS y el Process cen-tral (5), se hace por medio de un IntegrationLink. En este caso el proceso centralrecibe el mensaje por medio de su EntryPort, lo escribe en un Slot interno, des-de el que la tarea Filter (6) va a leerlo. Esta tarea elimina los mensajes entrantesque no tienen coste para la universidad y sólo deja pasar aquéllas que repre-sentan algún coste, que hay que guardar en el sistema DS. La próxima tarea enel flujo a recibir mensajes es el Replicator (7). Esta tarea se encarga de realizaruna copia del mensaje y enviar a dos Slots de salida, uno que se comunica conel puerto de mensajes ExitPort y el otro se que comunica con la proxima tareainterna del proceso, el Synchronizer (10). El mensaje que sale por el puertoExitPort va hacia la aplicación HRS, con el propósito de buscar más informa-ciones que se pueda añadir y enriquecer el contenido del mensaje original,que, a su vez, aguarda en el otro Slot de salida del Replicator. Esta interaccióncon el HRS busca los siguientes datos del empleado: nombre y apellidos, de-partamento al que pertenece, dirección de correo y el número de su teléfonomóvil. Toda la comunicación entre el proceso central y el Wrapper que conectael HRS a la solución se hace por medio de puertos de mensajes EntryPorts yExitPorts (8). En este Wrapper, la tarea CustomTask (9) produce un mensaje desalida que representa una consulta a la base de datos del sistema HRS y se loenvía al puerto de datos RequestReplyPort del Wrapper para que la ejecute.Al recibir la respuesta de la consulta, el puerto de datos la escribe en el Slotque lo conecta al puerto de mensajes ExitPort del Wrapper. Este puerto envíael mensaje al proceso central (5), en el que se sigue el flujo de procesamien-to por el Synchronizer (10). El Synchronizer, ahora, puede aplicar un patrónde sincronización y dar paso al mensaje original y al resultado de la consulta.Mientras no llegue el mensaje con la respuesta de la consulta, el Synchronizerno permite pasar el mensaje original. Por lo tanto, se da paso a los dos mensa-jes y la próxima tarea, Merger (11), se encarga de leer los dos mensajes desde


sus Slots de entrada y escribirlos en un único Slot de salida, que sirve de en-trada para el ContentEnricher (12). Esta última tarea es la que se encarga deañadir los datos que se han recibido por medio de la consulta al HRS, al men-saje original con la llamada. El mensaje producido por el ContentEnricher (12)se envía al puerto de mensaje ExitPort (13). Éste lo distribuye a las demás apli-caciones conectadas al puerto. En este caso, este puerto de salida actúa comoel patrón Recipient List [17].

La primera copia del mensaje fluye en dirección al DS, por medio del In-tegrationLink que conecta el proceso central (5) al Wrapper de esta aplicación.En el Wrapper, la primera tarea que procesa el mensaje es un Translator (14).Esta tarea produce cambios en la estructura de la información del mensaje,para adaptarlo a un formato que el DS pueda recibir. Se hacen cambios, como,e.g., la unión del código del país, de la región y el número del teléfono quese ha llamado, en un único campo. El mensaje transformado se lo envía a laaplicación DS por medio del puerto de datos SinkPort.

El otro IntegrationLink conecta el proceso central (5) al Wrapper de la apli-cación SMS Notifier (SMS-N). Esta aplicación permite enviar mensajes SMS ateléfonos móviles. En el Wrapper, lo primero que se hace es eliminar los men-sajes que no lleven el número del teléfono móvil del empleado. Esto se hacepor medio del Filter (15). La próxima tarea, el Slimmer (16), se encarga de re-ducir el contenido del mensaje, dejando sólo la información más importantepara ser enviada al teléfono móvil. La última tarea del Wrapper, el Transla-tor (17), adapta la estructura del mensaje a un formato especial para envío alteléfono móvil. Finalmente, el puerto de datos SinkPort envía el mensaje a laaplicación.

La tercera copia del mensaje se envía al Wrapper de la aplicación MS. Eneste Wrapper, la primera tarea que procesa el mensaje es un Filter (18). Supropósito es eliminar los mensajes que lleguen y que no lleven una direcciónde correo electrónico para el que se puede enviar el mensaje. En los casos enque el mensaje pase por el Filter, el Translator (19) lo recibe y se encarga deadaptar su estructura a un formato para enviarlo al MS. Al igual que en todoslos demás casos, el envío a la aplicación se hace por medio de un puerto dedatos de tipo SinkPort.

4.8. Sumario

En este capítulo hemos presentado una descripción de nuestra propuestade metamodelo para diseñar soluciones de integración de aplicaciones. De

4.8. Sumario 103

ello, hemos proporcionado una descripción general de algunas de las par-tes más importantes del metamodelo, explicando sus elementos y relaciones.Además, presentamos un ejemplo de diseño de una solución para resolver unproblema real de integración de la Universidad de Ijuí (UNIJUÍ), utilizando lapropuesta Guaraná.

Parte IV

Consideraciones finales

Capítulo 5

Conclusiones

En este trabajo de investigación hemos analizado el mundo de la integra-ción, enfocando nuestros esfuerzos, especialmente, en el área de la integraciónde aplicaciones. El estudio llevado a cabo, de algunas de las herramientas ac-tuales más referenciadas, nos permitió encontrar deficiencias importantes quepueden influir negativamente en el diseño de una solución de integración.Además hemos identificado un conjunto de propiedades que nos han permi-tido diseñar un framework de comparación para herramientas cuyo objetivoes resolver problemas de integración. En este framework hemos clasificadolas propiedades de acuerdo con el impacto y coste que pueden provocar en unproyecto de integración, resultando en los siguientes grupos: alcance, modela-do y técnico. A parte de eso, hemos relacionado dichos grupos de propiedadescon los perfiles profesionales involucrados en un proyecto de integración. Asíque, las propiedades del grupo alcance, suelen servir de base para la toma dedecisiones de los jefes de proyecto y se trata de propiedades cuya ausenciapuede dificultar enormemente e incluso invalidar el uso de una herramienta;el grupo de modelado, representa propiedades que no son tan críticas comolas anteriores, y están relacionadas con el trabajo de los arquitectos software;y, finalmente, el grupo de propiedades técnicas son aquellas que afectan a lafacilidad de programación, al rendimiento o a la gestión de las soluciones deintegración.

Sobre la base de este estudio realizado, hemos decidido desarrollar unapropuesta para el diseño de soluciones de integración de aplicaciones, deno-minada Guaraná. Con esta propuesta intentamos dar lo mejor soporte posi-ble a todas aquellas propiedades de alcance, modelado y técnicas que hemosidentificado. Para esto, el lenguaje proporcionado por Guaraná permite, e.g.,crear soluciones de integración a un nivel alto de abstracción sin que hayaque conocer los detalles y la tecnología de despliegue; ofrece varias tareas queimplementan patrones de integración y que soportan varias entradas/salidas;

108 Capítulo 5. Conclusiones

un modelo de mensajes amplio y extensible, que proporciona soporte tantoa comunicación simple, como a tipos más complejos por medio de MEPs; ti-pos diferentes de bloques de construcción que permiten una clara documen-tación de su intención dentro de la solución de integración; un modelo ricode puertos, tanto de mensajes como de datos, que permiten por medio de suestructura además de simplemente recibir/transmitir un mensaje, ejecutar al-gún pre/pos procesamiento; etcétera.

El estudio de las herramientas, la elaboración del framework y el resulta-do que hemos podido lograr con el esbozo de nuestra propuesta, nos sirvede base y al mismo tiempo nos motiva a seguir el trabajo en el mundo de laintegración.

Parte V

Apéndices

Apéndice A

Terminación de la documentación

A continuación describimos de la forma más objetiva posible los gradosde terminación de la documentación que utilizamos en las secciones de mis-celánea del Capítulo §3. Cada grado acumula las propiedades de los demásgrados que lo preceden.

? Sólo hay los fuentes o una pequeña documentación de la biblioteca aportadapor la herramienta; para buscar información y estudiar la herramientahay que participar en listas y foros de discusión; en el sitio web sólo sefacilita la biblioteca y el acceso a las listas y foros; se indica la intenciónde crear una sección con un documentación que no sea la de la biblioteca.

? ? En el sitio web de la herramienta hay una sección específica para la do-cumentación; se facilita una documentación completa de prácticamentetoda la biblioteca; hay algunos ejemplos no ejecutables sobre el uso deunos elementos de la herramienta; hay documentación textual de la ar-quitectura y otros aspectos importantes.

? ? ? Se facilita una documentación completa de toda la biblioteca; en el si-tio web de la herramienta se puede encontrar referencia a otros sitioscon más documentación; hay algunos tutoriales sobre el uso de la he-rramienta, pero son muy generales; hay documentación gráfica de la ar-quitectura y otros aspectos importantes de la herramienta; hay ejemplossencillos de código, pero completos que se puede reproducir y ejecutar.

? ? ? ? Se puede encontrar al menos un libro publicado sobre la herramienta;hay varios tutoriales que cobren aspectos generales y específicos de laherramienta; hay ejemplos complejos que se puede bajar e ejecutar; hayartículos técnicos publicados sobre la herramienta.

112 Apéndice A. Terminación de la documentación

? ? ? ? ? Se puede encontrar varios libros publicados sobre la herramienta; laherramienta aporta un manual completo y detallado sobre todos los ele-mentos que la componen; hay artículos científicos publicados sobre laherramienta; hay vídeos oficiales del fabricante presentando aspectostécnicos, importante, e.g., la arquitectura y ejemplos de uso de la herra-mienta.

Apéndice B

Calidad de la documentación

A continuación describimos de la forma más objetiva posible los gradosde calidad de la documentación que utilizamos en las secciones de misceláneadel Capítulo §3. Cada grado acumula las propiedades de los demás gradosque lo preceden.

Bajo Ejemplos no comentados y aislados de contexto; la documentación quehay es muy abstracta, ambigua y difícil de se relacionar con ejemplosprácticos.

Razonable La documentación proporciona una idea general de la utilidad delos elementos pero no entra en detalles; la documentación se refiere aversión actual pero hay partes que todavía se refieren a la versiones an-teriores que hay que actualizar; no hay un orden definido para estudiode la documentación.

Bueno La documentación proporciona una buena idea del uso y algunos de-talles técnicos del elemento; se comentan, de forma general, partes de al-gunos ejemplos y tutoriales; la documentación se refiere a versión actual;se estructura la documentación de acuerdo con las partes de la arquitec-tura.

Excelente La documentación proporciona, de forma clara, una idea completadel uso de los componentes, además de aplicados a ejemplos prácticos;la documentación proporciona todos los detalles de la herramienta res-pecto a sus los componentes; todos los ejemplos y tutoriales están biendetallados, comentados y se puede ejecutarlos al final; se organiza y seintroduce la documentación de una forma didáctica.

114 Apéndice B. Calidad de la documentación

Bibliografía

[1] C. Chang, M. Kayed, M. Girgis y K. Shaalan. Survey of Web InformationExtraction Systems. IEEE Transactions on Knowledge and Data Enginee-ring, 18(10):1411–1428, 2006

[2] B. Christudas. Service Oriented Java Business Integration. Packt Publis-hing, 2008

[3] R. Corchuelo, R. Frantz y J. González. Un Marco de Referencia para Com-parar ESBs desde la Perspectiva de la Integración de Aplicaciones. EnJornadas de Ingeniería del Software y Bases de Datos (JISBD) (Pendientede evaluación), 2008

[4] J. Davies, D. Schorow y D. Rieber. The Definitive Guide to SOA: Enter-prise Service Bus. Apress, 2008

[5] P. Delia y A. Borg. Mule 2: Official Developer’s Guide to ESB and Inte-gration Platform. Apress, 2008

[6] A. Foundation. Camel Book in One Page, 2008. Disponible en http://activemq.apache.org/camel/book-in-one-page.html

[7] A. Foundation. Camel Home, 2008. Disponible en http://activemq.apache.org/camel

[8] A. Foundation. ServiceMix Home, 2008. Disponible en http://servicemix.apache.org

[9] M. Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002

[10] M. Fowler. Inversion of Control Containers and the Dependency InjectionPattern, 2004. Disponible en http://martinfowler.com/articles/injection.html

http://activemq.apache.org/camel/book-in-one-page.html

http://activemq.apache.org/camel/book-in-one-page.html





http://martinfowler.com/articles/injection.html

http://martinfowler.com/articles/injection.html

116 Bibliografía

[11] R. Frantz. A DSL for Enterprise Application Integration. Int. J. ComputerApplications in Technology, 2008

[12] R. Frantz y R. Corchuelo. Integración de Aplicaciones. En Proceedings ofthe Zoco07 Workshop, páginas 65–75, Salamanca, 2007

[13] R. Frantz, R. Corchuelo y J. González. A DSL for Application Integra-tion. En Jornadas de Ingeniería del Software y Bases de Datos (JISBD)(Pendiente de evaluación), 2008

[14] E. Gamma, R. Helm, R. Johnson y J. M. Vlissides. Design Patterns: Ele-ments of Reusable Object-Oriented Software. Addison-Wesley, 1994

[15] G. Hohpe. Your Coffee Shop Does Not Use Two-Phase Commit. IEEESoftware, páginas 64–66, 2005

[16] G. Hohpe y H.-S. Tham. Enterprise Integration Patterns with BizTalkServer 2004. Informe técnico, 2004

[17] G. Hohpe y B. Woolf. Enterprise Integration Patterns - Designing, Buil-ding, and Deploying Messaging Solutions. Addison-Wesley, 2003

[18] iWay Software. iWay Adapter for PeopleSoft, 2008. Disponible en http://www.iwaysoftware.com/products/adapters/peoplesoft.html

[19] D. Jefford, K. B. Smith y E. Fairweather. Professional BizTalk Server 2006.Wiley, 2007

[20] A. Kleppe, J. Warmer y W. Bast. MDA Explained. Addison–Wesley, 2003

[21] D. Messerschmitt y C. Szyperski. Software Ecosystem: Understanding anIndispensable Technology and Industry. MIT Press, 2003

[22] I. MuleSource. Mule 2.x Javadoc API, 2008. Disponible en http://www.mulesource.org/docs/site/2.0.0/apidocs

[23] I. MuleSource. Mule 2.x User Guide, 2008. Disponible en http://mule.mulesource.org/display/MULE2USER/Home3

[24] OpenEAI. OpenEAI Home, 2008. Disponible en http://www.openeai.org

[25] D. Schmidt, M. Stal, H. Rohnert y F. Buschmann. Pattern-Oriented Soft-ware Architecture, volumen 2. John Wiley, 2000

[26] D. Skeen. A Formal Model of Crash Recovery in a Distributed System.IEEE Transactions on Software Engineering, 9(3):219–228, 1983

http://www.iwaysoftware.com/products/adapters/peoplesoft.html

http://www.iwaysoftware.com/products/adapters/peoplesoft.html

http://www.mulesource.org/docs/site/2.0.0/apidocs

http://www.mulesource.org/docs/site/2.0.0/apidocs

http://mule.mulesource.org/display/MULE2USER/Home3

http://mule.mulesource.org/display/MULE2USER/Home3

http://www.openeai.org

Bibliografía 117

[27] I. Smilehouse. OpenSyncro Home, 2008. Disponible en http://opensyncro.org

[28] I. SpringSource. Spring Integration Home, 2008. Disponible en http://www.springframework.org/spring-integration

[29] I. Tibco. TIBCO Home, 2008. Disponible en http://www.tibco.com

[30] W3C. Web Services Message Exchange Patterns, 2002. Disponible enhttp://www.w3.org/2002/ws/cg/2/07/meps.html#id2612442

[31] C. Walls y R. Breidenbach. Spring in Action. Manning Publications, 2004

[32] J. Weiss. Aligning relationships: Optimizing the value of strategic out-sourcing. Global services report, IBM, 2005

[33] I. Witten y E. Frank. Data Mining: Practical Machine Learning Tools andTechniques. Morgan Kaufmann, 2005

[34] D. Woolston. Foundations of BizTalk Server 2006. Apress, 2007

http://opensyncro.org

http://opensyncro.org



http://www.tibco.com

http://www.w3.org/2002/ws/cg/2/07/meps.html#id2612442

118 Bibliografía

This document was typeset on // using RC–BOOK α. for LATEX2ε.Should you want to use this document class, please send mail to

[email protected].

mailto:[email protected]

R Z. F U S - lsi.us.es · integraciÓn de aplicaciones un lenguaje especÍfico de dominio para el...

Documents

Transcript of R Z. F U S - lsi.us.es · integraciÓn de aplicaciones un lenguaje especÍfico de dominio para el...