INTEGRACIÓN DE APLICACIONES

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 REPORT DR. RAFAEL CORCHUELO JUNIO, 2008

First published in June 2008 by The Distributed Group ETSI Informática Avda. de la Reina Mercedes s/n Sevilla, 41012. SPAIN Copyright c MMVIII The Distributed Group http://www.tdg-seville.info contact@tdg-seville.info 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 and redistribution of the information contained in the documents whose copyright they own. You however are not allowed to take money for the distribution or use of these results except for a nominal charge for photocopying, sending copies, or whichever means you use redistribute them. The results in this document have been tested carefully, but they are not guaranteed for any particular purpose. The publisher or the holder of the copyright do not offer any warranties or representations, nor do they accept any liabilities with respect to them. Categorías (ACM 1998): D.2.11 [Software Architectures]: Domain-specific architectures; 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 (expediente P07-TIC-02602). Parte de esta financiación procede de fondos FEDER.

A mi mujer y a mis padres.

Índice general Agradecimientos...................................... IX Resumen............................................. XI I Prefacio 1 Introducción........................................ 3 1.1 Contexto de investigación.................................. 4 1.2 Propósito de esta investigación.............................. 8 1.2.1 Hipótesis........................................... 8 1.2.2 Tesis............................................... 8 1.2.3 Validación.......................................... 8 1.3 Resumen de contribuciones................................. 9 1.4 Estructura de la memoria.................................. 10 2 Motivación........................................ 11 2.1 Introducción............................................. 12 2.2 Problemas............................................... 12 2.2.1 Alcance de las herramientas.......................... 12 2.2.2 Capacidades de modelado........................... 16 2.2.3 Características técnicas.............................. 21 2.3 Discusión................................................ 24 2.4 Sumario................................................. 26 II Revisión de propuestas

II Índice general 3 Herramientas para la integración..................... 29 3.1 Introducción............................................. 30 3.2 Apache Camel........................................... 33 3.2.1 Mensajes.......................................... 35 3.2.2 Modelo............................................ 37 3.2.3 Puertos............................................ 37 3.2.4 Tareas............................................. 38 3.2.5 Despliegue........................................ 40 3.2.6 Ejecución.......................................... 41 3.2.7 Miscelánea......................................... 41 3.3 Mule.................................................... 42 3.3.1 Mensajes.......................................... 45 3.3.2 Modelo............................................ 46 3.3.3 Puertos............................................ 47 3.3.4 Tareas............................................. 48 3.3.5 Despliegue........................................ 49 3.3.6 Ejecución.......................................... 50 3.3.7 Miscelánea......................................... 50 3.4 Apache ServiceMix....................................... 51 3.4.1 Mensajes.......................................... 54 3.4.2 Modelo............................................ 55 3.4.3 Puertos............................................ 55 3.4.4 Tareas............................................. 56 3.4.5 Despliegue........................................ 58 3.4.6 Ejecución.......................................... 58 3.4.7 Miscelánea......................................... 59 3.5 Spring Integration........................................ 59 3.5.1 Mensajes.......................................... 62 3.5.2 Modelo............................................ 63 3.5.3 Puertos............................................ 64 3.5.4 Tareas............................................. 65 3.5.5 Despliegue........................................ 66 3.5.6 Ejecución.......................................... 67 3.5.7 Miscelánea......................................... 67 3.6 BizTalk 2006............................................. 67 3.6.1 Mensajes.......................................... 70 3.6.2 Modelo............................................ 71 3.6.3 Puertos............................................ 73

Índice general III 3.6.4 Tareas............................................. 75 3.6.5 Despliegue........................................ 76 3.6.6 Ejecución.......................................... 78 3.6.7 Miscelánea......................................... 79 3.7 Sumario................................................. 79 III Nuestra propuesta 4 Metamodelo Guaraná............................... 83 4.1 Introducción............................................. 84 4.2 Estructura de la solución de integración..................... 84 4.3 Mensajes................................................ 86 4.4 Building blocks........................................... 88 4.5 Puertos.................................................. 90 4.6 Tareas................................................... 95 4.7 Ejemplo................................................. 97 4.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......................... 31 3.2 Modelo conceptual de la arquitectura de Camel.................. 33 3.3 Estructura y taxonomía de los mensajes y exchanges en Camel..... 35 3.4 Estructura y taxonomía de las tareas de Camel................... 39 3.5 Modelo conceptual de la arquitectura de Mule................... 42 3.6 Estructura de los mensajes en Mule............................. 45 3.7 Tipos de tareas de Mule....................................... 48 3.8 Tareas en el flujo de entrada de un servicio en Mule............... 48 3.9 Tareas en el flujo de salida de un servicio en Mule................ 48 3.10 Modelo conceptual de la arquitectura de ServiceMix.............. 51 3.11 Estructura y taxonomía de los mensajes en ServiceMix............ 54 3.12 Taxonomía de los mensajes en ServiceMix....................... 56 3.13 Modelo conceptual de la arquitectura de Spring Integration........ 60 3.14 Estructura y taxonomía de los mensajes en Spring Integration...... 63 3.15 Taxonomía de las tareas de Spring Integration................... 65 3.16 Modelo conceptual de la arquitectura de BizTalk................. 68 3.17 Estructura y taxonomía de los mensajes en BizTalk............... 70 3.18 Estructura y taxonomía de los puertos de BizTalk................. 73 3.19 Tipos básicos de.netcomponents en BizTalk................... 75 3.20 Componentes simples de BizTalk............................... 76 3.21 Componentes compuestos de BizTalk........................... 76 4.1 Niveles y vistas en Guaraná................................... 84 4.2 Estructura de la solución de integración en Guaraná.............. 85 4.3 Mensajes y exchanges en Guaraná.............................. 86 4.4 Building blocks en Guaraná................................... 88 4.5 Representación gráfica de los wrappers en Guaraná.............. 88 4.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á.......... 89 4.8 Tipos de puertos en Guaraná.................................. 90 4.9 Puertos de mensajes en Guaraná............................... 91 4.10 Comunicación entre puertos en Guaraná........................ 92 4.11 Puertos de datos en Guaraná.................................. 93 4.12 Metáfora de un fregadero..................................... 94 4.13 Tipos de tareas en Guaraná.................................... 95 4.14 Grupos de tareas simple en Guaraná............................ 96 4.15 Tareas de tipo routers en Guaraná.............................. 97 4.16 Tareas de tipo transformadores en Guaraná...................... 98 4.17 Tareas de tipo constructores en Guaraná......................... 98 4.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....... 13 2.2 Propiedades relacionadas con las capacidades de modelado....... 17 2.3 Propiedades de carácter técnico................................ 21 2.4 Valores deseables para las propiedades de alcance................ 25 2.5 Valores deseables para las propiedades de modelado............. 25 2.6 Valores deseables para las propiedades técnicas.................. 26 3.1 Vocabulario de la herramienta Camel........................... 34 3.2 Vocabulario de la herramienta Mule............................ 43 3.3 Vocabulario la herramienta ServiceMix.......................... 52 3.4 Vocabulario de la herramienta Spring Integration................. 61 3.5 Vocabulario de la herramienta BizTalk 2006...................... 69 4.1 Iconos de las tareas routers en Guaraná......................... 97 4.2 Iconos de las tareas transformadoras en Guaraná................. 98 4.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 la primera piedra. Por lo tanto, puedo decir que en el día 06/09/2006 se colocó la primera 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 prontamente me puso en contacto con la persona encargada. Esto desencadenó una serie de interacciones con el profesor Dr. Rafael Corchuelo, el que propulsó este proyecto. De entonces, no podría olvidar expresar mi gratitud a estos dos profesores, que desde el Viejo Mundo han colaborado a hacer posible un sueño en el Nuevo Mundo. De forma especial, me gustaría expresar mis agradecimientos al profesor Dr. Rafael Corchuelo, hoy mi tutor, por todo el soporte que me ha dado en el periodo de investigación. Todo proyecto demanda un patrocinador. Por esto, de igual forma, expreso mis reconocimientos al Evangelischer Entwicklungsdienst e.v. (EED) por la concesión de la beca de doctorado.

X Agradecimientos

Resumen El área de la integración está cobrando una gran importancia en el contexto de los ecosistemas software actuales y de la alta inversión que requieren para resolver los problemas de integración. Son varios los enfoques que se dan a la integración. El primero, el Mashup, está enfocado en proporcionar la creación de una nueva aplicación por medio de la composición de servicios (llamados también Mashups); EAI enfoca la integración de aplicaciones dentro de la misma empresa, con el objetivo de mantener las aplicaciones funcionando en sincronía y de forma exógena poder integrar sus funcionalidades; B2BI tiene un propósito muy parecido al anterior, pero con la diferencia que las aplicaciones pertenecen a empresas distintas, lo que añade nuevos aspectos que hay que tener en cuenta a la hora de diseñar la solución de integración; EII enfoca la integración de diversas fuentes de datos, de forma que un conjunto de aplicaciones puedan colaborar para ofrecer una vista homogénea y en vivo de los datos; finalmente, ETL cuyo objetivo es extraer datos de fuentes distintas, procesar las transformaciones que se hacen necesarias para almacenarlos en otra base de datos y entonces permitir la ejecución de operaciones de lectura sobre los datos, ofreciendo por medio de esta nueva base una vista homogénea pero offline de los datos. Las herramientas actuales tienen problemas de alcance y aun no son capaces de responder de forma deseable a los problemas planteados por la integración. Al término de la investigación llevada a cabo, creemos que es posible construir una herramienta para EAI que tenga un alcance más amplio que las actuales, y, que por lo tanto, permita diseñar soluciones más directas y sencillas con una menor inversión. En esta memoria describimos nuestra propuesta, denominada Guaraná, para diseñar soluciones de integración de aplicaciones. Con el propósito de tener una primera validación hemos realizado dos proyectos de diseño de soluciones, en colaboración con empresas, para resolver problemas de integración de aplicaciones. En esta memoria también presentamos un resumen de nuestras contribuciones que hemos podido aportar hasta el momento, algunas de ellas ya publicadas y otras en proceso de revisión.

XII Resumen

Parte I Prefacio

Capítulo 1 Introducción Los ecosistemas software actuales demandan una gran inversión a la hora de diseñar soluciones de integración. Las herramientas actuales aun no son capaces de responder de una forma deseable a este problema. En la Secció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 para esto comentamos nuestra hipótesis, tesis y las primeras validaciones que hemos hecho; finalmente, en la Sección 1.3, presentamos un resumen de las contribuciones que hemos aportado, hasta el momento, al área de integración de aplicaciones.

4 Capítulo 1. Introducción 1.1. Contexto de investigación En las empresas actuales es muy habitual que convivan aplicaciones que han sido adquiridas o desarrolladas conforme dichas empresas han evolucionado y han ido descubriendo nuevos requisitos, dando lugar a ecosistemas software que no siempre son fáciles de gestionar [21]. Un problema frecuente en estos ecosistemas es integrar dos o más aplicaciones de forma que los datos que manejan por separado estén sincronizados o que puedan colaborar para ofrecer nueva funcionalidad o nuevas vistas de datos [17]. Según un reciente informe de IBM los gastos de integración superan en una proporción de entre cinco y veinte a los de desarrollo de nueva funcionalidad [32]. No es de extrañar, por lo tanto, la enorme popularidad que las herramientas para construir buses de servicios empresariales (ESBs) están ganando en este contexto, ya que ofrecen la infraestructura necesaria para integrar los sistemas más dispares [4]. El principal objetivo de una solución de integración es mantener las aplicaciones que forman parte de la solución sincronizadas, aportar nuevas funcionalidades y vistas de datos. Dicha solución debe ofrecer al usuario una vista de 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 aplicaciones en forma de funcionalidades o también en forma de vistas de datos que pueden proporcionar información de las aplicaciones integradas. En esta área, además del reto de integrar aplicaciones que han sido desarrolladas por separado sin tener en cuenta la integración, hay que tener en cuenta otros aspectos más específicos que se hacen importantes. Primero, las tecnologías en las que están desarrolladas las aplicaciones pueden ser muy diferentes, como, e.g., una aplicación hecha en Cobol/CSP que se ejecuta en un mainframe IBM S390 y otra hecha en Visual Basic.NET que se ejecuta en una maquina Windows Vista. Dicho entorno tecnológico puede, en algunos casos, hacer más difícil la integración. Otro aspecto importante esta relacionado con el modelo de datos de las aplicaciones involucradas en una solución, puesto que pueden tener modelos muy distintos sobre el mismo concepto, o aun, modelos muy distintos de dominios también muy diferentes, lo que puede dificultar el diseño de una solución. La comunicación con una aplicación, en el mundo 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. Aunque se pueda estar integrando aplicaciones del mismo dominio, dichas capas pueden hacerse muy diferentes por las características expuestas anteriormente, y ofrecer acceso a funcionalidades semánticamente equivalente, pero por medio de interfaces diferentes. Por lo tanto, esto nos permite ver que el hecho de integrar 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 para que una solución de integración sea viable para las empresas. La primera restricción es que después de hacer la integración, las aplicaciones involucradas no deben cambiar. Un cambio en una de estas aplicaciones podrá afectar profundamente o hasta invalidar totalmente otras soluciones de integración, o incluso, los procesos de negocio que soportan esas aplicaciones. La siguiente restricción es que, después de integradas, las aplicaciones deben mantenerse desacopladas las una de las otras como antes de la integración. La solución de integración no debe cambiar las aplicaciones involucradas generando dependencias en ellas que antes no existían. Finalmente, podemos añadir una tercera restricción según la cual la integración no debe ser hecha como parte del proceso de desarrollo de sistemas, sino conforme sea necesario. La ingeniería informática debe proporcionar el soporte para, entre otras cosas, diseñar, implementar y gestionar soluciones de integración, de forma que las dificultades y costes sean reducidos al máximo. Dicho soporte ingenieril debe englobar aspectos como, e.g., un lenguaje específico de dominio (DSL) con el que se puede realizar un modelo conceptual del problema de integración que se pretende resolver. Además, debe aportar herramientas específicas para el área de integración, que permitan desde un nivel más alto de abstracción, hacer uso de tecnologías de más bajo nivel, como, e.g., bibliotecas 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 los proyectos diseñados en la herramienta. Aunque estos aspectos técnicos sean importantes, también hay que tener en cuenta la necesidad de adopción de buenas prácticas enfocadas en la area de integración y metodologías que puedan 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 el lado servidor o en el lado cliente, integración de funcionalidades o información. La integración que se puede hacer en el lado cliente es el más reciente tipo de integración que se puede encontrar y se llama Mashup. Por otro lado los tipos de integración que se pueden hacer en el lado servidor son varios, a saber: Enterprise Application Integration (EAI), Business to Business Integration (B2BI), Enterprise Information Integration (EII) y Extract, Transform and Load (ETL). La tecnología de Mashup permite crear una nueva aplicación por medio de la composición de servicios (llamados también Mashups). Esta aplicación se ejecuta dentro del navegador del cliente y es responsable de orquestar Mashups. Los Mashups están enfocados en la integración de información, desde

6 Capítulo 1. Introducción una o más fuentes de datos. Diversas empresas en la web ofrecen herramientas para diseñar este tipo de solución de integración. Por ejemplo, Google proporciona un editor llamado Mashup Editor en http://www.googlemashups.com, Microsoft proporciona Popfly en http://www.popfly.com y Yahoo proporciona Pipes en http://pipes.yahoo.com/pipes. Además, las empresas que ofrecen soporte a esta tecnología, también, ofrecen por medio de una comunidad de usuarios, un conjunto de Mashups ya listos que uno puede incorporar a su solución. Las soluciones de integración cuyo objetivo es mantener un conjunto de aplicaciones en sincronía, aportar nuevas funcionalidades y que se ejecutan en el lado del servidor, son las EAI. Este tipo de solución suele conectar dos o 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 las aplicaciones conozcan la solución. Es decir, una solución EAI aporta de forma exógena funcionalidad de una aplicación a la otra, o incluso, nuevas funcionalidades, además de mantener las aplicaciones independientes una de las otras y coordinarlas. Una característica importante en este tipo de solución de integración, es que se considera que las aplicaciones que se están integrando pertenecen a la misma empresa. Business to Business Integration (B2BI) representa un tipo de solución de integración muy parecida a las soluciones EAI. La diferencia entre EAI y B2BI está 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 en B2BI hay aspectos que son mucho más críticos e importantes que en el contexto de EAI. El primer aspecto se relaciona con el tema de la seguridad, puesto que el acceso a las aplicaciones de una empresa no queda abierto y libre. Hay que tener autorización y permisión para accederlas, y, por lo tanto, la solución de integración tiene que ser capaz de tratar esto. La autenticación, que en EAI suele ser local, en B2BI puede requerir recurrir a servicios externos, pues es necesario saber, e.g., si un usuario en una organización tiene o no acceso a un recurso de otra organización. Otro aspecto muy importante es la fiabilidad de la infraestructura de mensajería que se utiliza, debido a que es mucho más probable que falle en una solución B2BI que en EAI. Además en B2BI puede haber 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 necesaria la presencia de un notario, pero en B2BI puede ser necesaria para dar fe de que una transacción ha tenido lugar. Finalmente, se suele hacer uso de estándares en B2BI, como, e.g., para el intercambio de datos como OBI (Open Buying on the Internet) o EDI (Electronic Document Interchange), cxml (Commerce XML). Se han pensado dichos estándares para un entorno inter-organizacional

1.1. Contexto de investigación 7 y no un entorno intra-organizacional cómo es el caso de EAI. Por lo tanto, se puede decir que una solución B2BI necesita una infraestructura de integración má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 fuentes de datos suelen ser bases de datos, aunque cualquier canal que la aplicación utilice 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 proporcionar soporte para que un conjunto de aplicaciones puedan colaborar y ofrecer una vista homogénea y en vivo de los datos que pertenecen a dichas aplicaciones integradas. Sobre esta vista, el usuario podrá ejecutar operaciones con un lenguaje de alto nivel que le permita consultar y/o insertar datos en las diversas fuentes de una forma transparente. Una diferencia importante con relación a EAI, es que en EII no hay flujos de datos conectando aplicaciones con el objetivo de mantenerlas sincronizadas, sino que flujos de datos de las fuentes que convergen en las vistas de la solución. Dichas vistas pueden simplemente reflejar otras vistas ya existentes de las fuentes de datos o representar nuevas vistas de datos aportadas por la solución EII. Al igual que EAI e B2BI, este tipo de solución se ejecuta en el lado servidor. Extract Transform and Load (ETL) es otro tipo de solución de integración que se ejecuta en el lado servidor y cuyo objetivo, también, es la integración de información. La diferencia que hay entre ETL y EII está en que, mientras EII proporciona 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, procesar las transformaciones que se hacen necesarias para almacenarlos en otra base de datos, en la que se puede ejecutar operaciones de lectura sobre los datos. Las operaciones que se suelen ejecutar son operaciones que pueden demandar mucho recursos de la maquina en la que está la información, por lo que se hace en una base de datos nueva y no en vivo como en EII. A dichas bases de datos se suelen llamar data warehouses o data marts. Mientras en un data warehouse representa un conjunto de datos con información sobre toda la empresa, los data marts suelen representar un almacén de datos más centrado en algún aspecto especifico de la empresa, como, e.g., los clientes. No es objetivo de esta memoria entrar en detalles sobre los conceptos de data warehouse y data marts, así que no vamos profundizar en estos temas. Como hemos podido ver hay varios tipos de soluciones de integración, cada uno de ellos con sus aspectos particulares. Nuestro trabajo de investigación está centrado en las soluciones de integración de aplicaciones, así que también vamos a centrar esta memoria en este tema.

8 Capítulo 1. Introducción 1.2. Propósito de esta investigación En esta sección demostramos la hipótesis que ha motivado nuestro trabajo de investigación en el contexto de la integración. También presentamos la tesis que 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 ecosistemas software actuales. Las herramientas de EAI tienen problemas de alcance debido a que sus características hacen inviable el diseño de algunas soluciones de integración; en otros casos, sus capacidades de modelado pueden dar lugar a soluciones más artificiales y complejas de lo que sería deseable y por lo tanto más difíciles de mantener; también, se han identificado algunas deficiencias desde el punto de vista técnico que pueden resultar molestas para los programadores y administradores de sistemas. 1.2.2. Tesis Es posible construir una herramienta para EAI con un alcance más amplio que 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 programadores y administradores de sistemas, todo ello con el objetivo de producir soluciones de integración que requieren una menor inversión. 1.2.3. Validación Se ha realizado una prospección participando en dos proyectos, uno relacionado con un sistema de gestión de llamadas de la Universidad de Ijuí (UNIJUÍ), y otro relacionado con un sistema de asesoramiento laboral de la empresa Indisys, S.L. Estos dos proyectos nos han permitido profundizar en EAI, avanzar en el diseño de nuestra propuesta y tener un primer contacto con su validación en casos reales. Se está en negociaciones con la empresa Sytia Informática, S.L. para diseñar un sistema de integración en el entorno sanitario. Este proyecto nos permitirá seguir profundizando y validando nuestra propuesta en el contexto B2BI.

1.3. Resumen de contribuciones 9 En el futuro colaboraremos con alguna empresa para comparar el esfuerzo de desarrollo de alguno de sus proyectos de integración con y sin nuestra propuesta. Los resultados nos permitirán obtener conclusiones sobre su alcance, capacidades de modelado y características técnicas, así como validar o refutar nuestra tesis. 1.3. Resumen de contribuciones El estudio de algunas de las principales herramientas de EAI nos permitió diseñar un framework de comparación, el que puede ayudar una empresa a la hora de evaluar y escoger una herramienta de integración. Durante este trabajo, también hemos producido una documentación técnica sobre varios aspectos relevantes de la arquitectura de estas herramientas, el que puede servir de base para estudiarlas. Todo esto nos ayudó a esbozar un metamodelo que proporciona un lenguaje específico de dominio para diseñar soluciones de integración de aplicaciones. Los resultados de los trabajos anteriores han dado lugar a las siguientes publicaciones: En [12] esbozamos los fundamentos de una herramienta para diseño de soluciones de integración. Para esto, proponemos una división de la solución en niveles y vistas que pueden facilitar el diseño, además de presentar algunos de los building blocks fundamentales para tal actividad. En [11] presentamos nuestra propuesta de un lenguaje específico de dominio para diseñar soluciones de integración de aplicaciones. Hacemos una primera comparación de nuestra propuesta con una de las herramientas actuales más referenciadas en el área de EAI y que implementa los patrones de integración [17]. El artículo [3] ha sido enviado a las JISBD 08 y en él presentamos un framework de comparación para herramientas de integración. Proponemos un conjunto de propiedades, agrupadas en tres grupos distintos, que pueden ayudar a la hora de evaluar y escoger una herramienta para el diseño de soluciones de integración. El artículo [13] ha sido enviado a las JISBD 08 y en él profundizamos la discusión de nuestro lenguaje DSL para la integración de aplicaciones. Para esto presentamos dos ejemplos de casos reales, en los que hemos utilizado el DSL para diseñar dos soluciones de integración. Además,