Integracin de Aplicaciones* o

Rafael Z. Frantz (1), Rafael Corchuelo (2)

(1) Universidade Regional do Noroeste do Estado do Rio Grande do Sul So Francisco, 501. Iju 98700-000 RS (Brasil) a rzfrantz@unijui.edu.br (2) Universidad de Sevilla, ETSI Informtica a Avda. de la Reina Mercedes, s/n. Sevilla 41.012 (Spain) corchu@us.es

o Resumen La integracin de aplicaciones es actualmente uno de los grandes retos de la Ingenier del Software. Segn un reciente informe a u de IBM, los gastos de integracin superan en una proporcin de 5 a 20 o o dlares los de desarrollo de nueva funcionalidad. En este art o culo esbozamos los fundamentos de una herramienta para el desarrollo de soluciones de integracin. Nuestro objetivo es tan slo presentar los conceptos funo o damentales; a partir de esta propuesta continuaremos trabajando con el objetivo de formalizar cada uno de los bloques de construccin preo sentados de forma que se puedan implementar y utilizar para construir soluciones de integracin. Creemos que este trabajo puede ser innovador o puesto que hasta ahora las soluciones que conocemos tan slo ofrecen o patrones de diseo intuitivos. n

1.

Introduccin o

Hoy en d no es dif encontrar empresas que estn ejecutando una cantia cil e dad muy grande y variada de aplicaciones en un entorno distribuido para llevar a cabo su negocio. Estas aplicaciones suelen ser paquetes de software comprados de terceros, hechas a medida para solucionar un problema especico o aplicaciones heredadas. Tal heterogeneidad hace, muchas veces, con que unos procesos de negocio de la empresa tengan que utilizar dos o ms aplicaciones. En nuestra a experiencia, es habitual que estas aplicaciones no estn preparadas para intera actuar entre s automticamente. As que conocer las diferentes aplicaciones, a meter y llevar datos de una a otra y ejecutar funcionalidades en cada una en separado, es tarea de los usuarios, aunque tengan que hacer trabajo doble. Esto suele pasar cuando por lo menos una aplicacin involucrada en un proceso no o fue diseada para trabajar integrada. En las empresas tambin es muy frecuente n e la necesidad de aadir funcionalidades nuevas a las aplicaciones ya existentes, lo n que en muchos casos puede resultar prohibitivo. As que, en este caso, hay dos posibilidades: desarrollar una nueva aplicacin con todas las funciones actuales o
*

Proyecto IntegraWeb (CICYT TIN2007-64119, JA TIC-2602), Evangelischer Entwicklungsdienst (EED)

ZOCO'07 / CAEPIA

65

y aadir las nuevas deseadas o desarrollar otra solamente con las nuevas funn cionalidades e integrarlas. La primera opcin suele ser muy costosa, la segunda o exigir proyectar una solucin de integracin que ofrezca al usuario una visin a o o o de ms alto nivel con la que interactuar. a Al hablar de de integracin, hay que tener en cuenta algunas restricciones o para que una solucin de integracin sea viable para las empresas. La primera o o restriccin es que despus de hacer la integracin, las aplicaciones involucradas o e o no deben cambiar. Un cambio en una de estas aplicaciones podr afectar profuna damente o incluso invalidar totalmente la solucin de integracin. De acuerdo o o con un estudio publicado reciente de IBM [1], por cada dlar gastado con el o desarrollo de una aplicacin, el coste para integrarla es del orden de 5 a 20 veces o ms. La siguiente restriccin es que, despus de integradas, las aplicaciones dea o e ben mantenerse desacopladas las una de las otras como antes de la integracin. o La solucin de integracin no debe cambiar las aplicaciones involucradas geneo o rando dependencias en ellas que antes no exist an. Finalmente podemos aadir n una tercera restriccin segn la cual la integracin no debe ser hecha como parte o u o del proceso de desarrollo de sistemas, sino conforme sea necesario. La solucin de integracin puede estar fundada en una integracin de los o o o datos de las aplicaciones, a partir de un esquema de datos global, o en un ujo de llamadas funcionales entre las aplicaciones por medio de APIs. As que esta solucin de integracin puede ser vista como una nube operativa y/o declarativa. o o La vista es operativa cuando representa una visin funcional, con un ujo de o datos y una API de bajo nivel para la integracin. A esta visin llamaremos o o Enterprise Application Integration (EAI). Si la visin es de un esquema central o de datos ofreciendo una API de consulta a alto nivel, entonces la llamaremos Enterprise Information Integration (EII). La frontera que hay entre EAI y EII, no obstante, suele ser muy difusa. En este art culo trataremos de integracin de aplicaciones con sistemas de o mensajer En [2], los autores proponen varios patrones que ayudan a disear a. n una solucin de integracin de este tipo. Muchos de estos patrones no son ms o o a que una idea abstracta para resolver, de una buena manera, un problema recurrente de software. No obstante, creemos que pueden convertirse en algo mucho ms concreto, en bloques de construccin que pueden ser, directamente, utilizaa o dos/arrastrados al disear la solucin de integracin. As que no los llamaremos n o o patrones, si no Building Blocks. El resto del art culo se organiza as en la seccin 2, presentamos los sistemas : o de mensajer para integracin de aplicaciones, as como los posibles niveles y a o vistas para una solucin de integracin; en la seccin 3 presentamos la jerarqu o o o a de los Building Blocks; en la seccin 4 un ejemplo de integracin utilizando o o Building Blocks y nalmente nuestras conclusiones.

2.

Integracin usando sistemas de mensajer o a

Para empezar esta discusin, deniremos brevemente lo que es un sistema de o mensajer Podemos decir que un sistema de mensajer es un sistema encargado a. a

ZOCO'07 / CAEPIA

66

Figura 1. Niveles y vistas de la solucin de integracin o o

de administrar mensajes que tendr que recibir y enviar a algn destino por mea u dio de canales de comunicacin. Tal como ocurre en las bases de datos, tambin o e debe haber para los sistemas de mensajer una persona encargada de adminisa trarlos, por ejemplo, creando y congurando dichos canales de comunicacin. o Este estilo de integracin de aplicaciones implica directamente que las aplicao ciones involucradas en la solucin de integracin no conozcan expl o o citamente y no puedan acceder directamente a otra(s) aplicacin(es), sino que deben hacerlo o siempre por medio del sistema de mensajer a. Las principales ventajas de una solucin de integracin con sistemas de meno o sajer son: el bajo acoplamiento y la posibilidad de tener una comunicacin a o as ncrona entre las aplicaciones integradas. En este caso entendemos por acoplamiento el conocimiento que una aplicacin involucrada en la solucin debe tener o o con respecto a las dems. Cuanto ms conocimiento necesita una aplicacin, a a o decimos que ms acoplada est, y por lo tanto ms dependiente y vulnerable a a a a los cambios de las dems. Cuando una aplicacin es integrada por una solucin a o o diseada con sistemas de mensajer apenas suele conocer, o incluso puede ni n a, conocer, la solucin de integracin. La aplicacin conocer la solucin de integrao o o a o cin si tiene una capa de software que le permita acceder el sistema de mensajer o a. No tendr tal conocimiento si es una aplicacin que fue desarrollada sin tener a o en cuenta la integracin y ofrece como puerta de entrada solamente su interface o GUI. La solucin de integracin no necesariamente debe ser implementada con o o un unico sistema de mensajer y ejecutarse en un unico ordenador, sino que a puede estar compuesta de varios sistemas de mensajer distribuidos. La comua nicacin as o ncrona permite que una aplicacin pueda enviar un mensaje a otra o sin que la aplicacin destino tenga que estar lista para recibirlo. Esto signica o que cuando tal aplicacin termine, por ejemplo, de ejecutar lo que est haciendo o e pueda acceder al canal y recibir el mensaje. As que una no necesita aguardar la otra para ejecutar su tarea, el sistema de mensajer se encarga de recibir, a transmitir y mantener el mensaje en un canal hasta que su receptor est listo e para recibir y procesarla. 2.1. Niveles de la solucin de integracin o o

De acuerdo con nuestra visin sobre integracin de aplicaciones, una solucin o o o de integracin se puede dividir en, por lo menos, tres niveles y cuatro vistas. o Sobre los niveles distribuimos las siguientes vistas de la solucin: Solucin de o o

ZOCO'07 / CAEPIA

67

Figura 2. Vista de la solucin de integracin o o

Figura 3. Ejemplo de aplicacin y de la nube de integracin o o

Integracin, Nube de Integracin, Aplicacin y Adaptador de Aplicacin. Estos o o o o niveles y vistas son lgicos, y los proponemos para ayudar a entender y disear o n una solucin de integracin. En la gura 1 localizamos las vistas en sus posibles o o niveles de la solucin y a continuacin describimos con ms detalles cada uno de o o a ellos. Solucin de Integracin: El nivel 1 es el ms alto y por lo tanto el ms abstracto o o a a de los tres. En este nivel proponemos, tan solo, representar las aplicaciones involucradas en la solucin de integracin as como los ujos de entrada y/o salida o o entre la aplicacin y dicha solucin. La solucin de integracin se representa por o o o o una nube, que llamamos Nube de Integracin. En la gura 2 se puede ver la o solucin de integracin de tres aplicaciones: application A, application B, y o o application C. La aplicacin A tiene tanto un ujo de entrada como otro de o salida con la nube de integracin y las aplicaciones B y C tienen tan slo o o un ujo de entrada a partir de la solucin de integracin. o o Nube de Integracin: Esta vista presenta los Building Blocks que ejecutan gran o parte de las tareas necesarias para la integracin, adems de ser la vista ms o a a destacada de una solucin de integracin. En la gura 3 (b) vemos dichos Builo o ding Blocks que existen por debajo de la nube de integracin. Tenga en cuenta o que para recibir o enviar datos a las aplicaciones involucradas hay canales de comunicacin. Dichos canales conectan los Building Blocks internos y espec o cos

ZOCO'07 / CAEPIA

68

Figura 4. Ejemplo de adaptador de aplicacin o

de la nube de integracin con las aplicaciones. Ms adelante presentaremos con o a detalles estos Building Blocks. Aplicacin: Si fuera posible hacer clic en la aplicacin A, de la vista de la soluo o cin de integracin, ver o o amos los detalles presentados en la gura 3 (a). En esta vista ya podemos ver que adems de la aplicacin hay dos otros componentes: a o el Gateway y el Adapter. Denimos el Gateway como una capa de software que pertenece exclusivamente a la aplicacin y que la permite enviar o recibir datos o a/de un sistema de mensajer por medio de un Adapter. El Gateway es para el a Adapter la interfaz de comunicacin con la aplicacin y se representa por una o o API bajo nivel o por la propia GUI de la aplicacin. El Adapter es la capa de o software que permite hacer toda la comunicacin con el sistema de mensajer o a. Lo consideramos parte de la solucin de integracin, al contrario que el Gateway. o o Por lo tanto, al disear una solucin de integracin se suele disear, un Adapter, n o o n para cada aplicacin. Puede haber situaciones en que la aplicacin ya tiene un o o Gateway desarrollado especialmente para acceder sistemas de mensajer direca tamente, as que en este caso espec co no tendremos que disear para ella el n Adapter. Pero hay que tener en cuenta que esto no es lo que suele pasar cuando hablamos de integracin de aplicaciones. o Adaptador de Aplicacin: En el tercer nivel est la vista del Adaptador de Aplio a cacin y es aqu donde se puede ver de que est compuesto el Adapter. La gura o a 4 presenta sus detalles; llamamos a sus bloques internos Adapter Blocks. Son ellos realmente los responsables por la funcionalidad del Adapter. Estos bloques no son ms que un conjunto especial de Building Blocks utilizados en el a Adapter, donde unos de ellos, adems de ejecutar procesos internos, permiten a comunicarse con los dems bloques de la nube de integracin o con el Gateway a o de la aplicacin. En [2] estos bloques se llaman de Endpoint. El Adapter suele o tener tambin, adems de los Adapter Blocks propuestos en [2], cdigo ad-hoc e a o escrito en un lenguage/tecnolog espec a ca. La razn es que para comunicarse o con el Gateway de la aplicacin o ejecutar algn proceso interno y espec o u co del Adapter, tendremos que escribir cdigo. As que los bloques de la gura 4 o

ZOCO'07 / CAEPIA

69

Figura 5. Jerarqu de los Building Blocks a

marcados con asterisco, representan un tipo espec co de Adapter Block del que no se habla en [2]. Son bloques de muy bajo nivel y los llamamos Code Block.

3.

Clasicacin de los bloques de construccin o o

Clasicamos los Building Blocks en dos grupos: aqullos utilizados para die sear el ujo de la solucin de integracin, representado en la vista de la Nube n o o de Integracin y aqullos utilizados en el Adaptador de Aplicacin. Hay un Builo e o ding Block bsico y esencial para cualquier solucin de integracin por medio de a o o Messaging, que llamase Message. As que antes de presentar los bloques espec cos de cada grupo vemos la diferencia entre Messaging y Message. En la gura 5 presentamos la jerarqu completa de los Building Blocks que describimos ms a a adelante. Mientras Messaging es la tecnolog (por ejemplo, Java Message Service a (JMS), Microsoft MSMQ o WebSphere MQ) que permite a dos o ms aplicacioa nes comunicarse de forma as ncrona teniendo en cuenta un bajo acoplamiento y una transmisin able (store-and-forward), Message no es ms que una eso a tructura de datos pasiva que viaja de una aplicacin a otra por medio de otros o Building Blocks. Message puede representar un comando, una descripcin de un o evento o sencillamente una informacin, y est compuesto de dos partes: cabeceo a ra y cuerpo. La cabecera contiene meta-informacin que suele ser utilizada por o el sistema de mensajer para saber, por ejemplo, de quin es y a quin debe a e e entregarse el mensaje. El cuerpo contiene la informacin (dato) transmitido y es o ignorado por el sistema de mensajer [2]. a 3.1. Bloques de la Nube de Integracin o

Los bloques de la nube de integracin estn agrupados en: Channels, Routers o a y Message Transformations. El primer grupo contiene varios tipos de canales que permiten a los productores de mensajes (aplicaciones o los dems bloques) a escribir y a los consumidores leer los mensajes del canal. Aqu presentaremos los canales Point-to-Point, Guaranteed Delivery, Datatype y Invalid Message. Ya en el grupo de los Routers estn los bloques de construccin con los cuales es a o

ZOCO'07 / CAEPIA

70

posible cambiar/decidir la ruta de un mensaje, as que presentaremos el Content Based Router, el Recipient List y el Message Filter. Finalmente hablaremos de los Message Transformations, los cuales pueden cambiar el contenido de un mensaje: Message Translator, Canonical Data Model, Content Enricher y Content Filter. Point-to-Point Channel: Es un canal muy sencillo que recibe mensajes de uno o ms productores y puede contener uno (lo ms normal) o ms consumidores. a a a La caracter stica ms importante de este canal es que garantiza que solamente a uno de los consumidores recibir el mensaje. a Guaranteed Delivery Channel: Podemos decir que este y los siguientes canales son una especializacin del Point-to-Point. La diferencia entre el Point-to-Point o y el Guaranteed Delivery es que este ultimo garantiza la entrega del mensaje aunque el sistema de mensajer tenga problemas. Es este canal el que permite a hacer lo que antes llamamos store-and-forward. Datatype Channel: Este canal es util en situaciones en que el productor debe enviar un determinado tipo de mensaje al canal con la garant de que los consua midores conocen tal tipo y podrn procesarlo. La diferencia con el Point-to-Point a es que aqu hay solamente un tipo de mensaje en el canal. Invalid Message Channel: Hay situaciones en las cuales se recibe un mensaje pero no se puede procesar por alguna razn. Por ejemplo, llega un mensaje o en formato texto pero en realidad se aguardaba un mensaje binario. Entonces lo que el receptor debe hacer, en estos casos, es mover el mensaje incorrecto a un Invalid Message Channel. As que dichos canales tendrn mensajes que a representan problemas en la solucin de integracin, siendo por lo tanto una o o especie de log de la solucin. o Content-Based Router: Este Router tiene la capacidad de recibir un mensaje, examinar su contenido y hacer el debido encaminamiento del mensaje a solamente uno de sus consumidores conocidos. Es un Building Block que ayuda disminuir la cantidad de canales de la solucin, aunque puede requerir un mantenimiento o frecuente. Recipient List: Tiene una funcionalidad semejante al anterior, pero es diferente por permitir encaminar una copia del mensaje recibido a todos los consumidores interesados en ella. Una forma de conseguir esto es haciendo que los mensajes incorporen de forma expl cita la lista de destinatarios; otra es que este Building Block la calcule usando reglas o accediendo a alguna base de datos. Message Filter: Lo utilizamos siempre delante de una aplicacin o de otro Builo ding Block con el objetivo de evitar mensajes indeseados. As que basado en un cierto criterio congurado en el Message Filter, un mensaje puede ser fcilmente a rechazado.

ZOCO'07 / CAEPIA

71

Message Translator: Las aplicaciones involucradas en una solucin de integrao cin suelen utilizar internamente formatos diferentes de datos. As que cuando o tengan que comunicarse hay que hacer la traduccin de un formato para otro. o Esta traduccin puede ser hecha en la solucin de integracin por un Message o o o Translator. Canonical Data Model: La idea de haber un traductor entre dos aplicaciones es buena, pero en soluciones de integracin con varias aplicaciones en que una tiene o que comunicarse con varias otras, si seguimos esta idea tendremos demasiados traductores. Adems, si una de estas aplicaciones sufre un cambio en su formato a de datos, tendremos que cambiar todos traductores. Diseando un Canonical n Data Model para la solucin de integracin, tendremos solamente un Message o o Translator para cada aplicacin. Este har la traduccin del formato de datos o a o de la aplicacin para el modelo cannico de la solucin de integracin. As que o o o o cada mensaje ahora es transformado dos veces (formato de la aplicacin/modelo o cannico/formato de la aplicacin), y no ms solamente una, pero la cantidad o o a de transformadores ser mucho menor en dichas soluciones. a n Content Enricher: El objetivo de este traductor es aadir datos al mensaje. Puede que el mensaje no contenga toda la informacin necesaria, entonces, por o ejemplo, con el Content Enricher es posible buscar tal informacin en alguo na fuente de datos externa, en el ambiente de ejecucin de la solucin, o an o o u computar dicha informacin desde el mensaje original. o Content Filter: Algunas veces es necesario quitar de un mensaje ciertos datos, as que esto es lo que hace el Content Filter. El objetivo es quitar datos de un mensaje para simplicarlo ya que no son de inters para los prximos bloques e o del ujo de integracin, reducir el trco de la red o incluso por cuestiones de o a seguridad. 3.2. Bloques del Adaptador de Aplicacin o

El Adaptador de Aplicacin contiene en su interior un tipo especial de Builo ding Block, que llamamos Adapter Block. El principal objetivo del Adaptador de Aplicacin, ya descrito anteriormente con ms detalles, es ejecutar tareas que o a permitan la conexin de una aplicacin al sistema de mensajer En [2] este o o a. adaptador es clasicado como un tipo de Message Channel, llamado Channel Adapter. En este art culo lo llamamos Adaptador de Aplicacin y proponemos o la creacin de un grupo espec o co para l debido a su gran importancia en la e integracin de aplicaciones, adems de ser un contenedor de Adapter Blocks. A o a continuacin presentamos tres Adapter Blocks de este grupo: Polling Consumer, o Messaging Mapper y Code Block. Polling Consumer: Lo que permite este Adapter Block es consumir mensajes de un canal tan slo cuando la aplicacin que tiene que procesarlos est lista para o o e hacerlo. Los mensajes se pueden consumir tanto de forma s ncrona como no s ncrona y, por supuesto, es posible consultar si existe algn mensaje disponible. u

ZOCO'07 / CAEPIA

72

Figura 6. Ejemplo de una solucin de integracin o o

Messaging Mapper: Messaging Mapper permite transformar los objetos de una aplicacin en mensajes del sistema de mensajer con una gran independeno a, cia entre ellos. Este Adapter Block debe contener todas las reglas para hacer tal mapeo, as que ni los objetos ni el sistema de mensajer deben conocer el a Messaging Mapper. a a Code Block: Este tipo de Adapter Block es, quizs, el ms sencillo de todos. Lo proponemos aqu como un bloque que pueda contener cdigo escrito en un o lenguaje/tecnolog espec a ca, y que, junto con los dems Adapter Blocks, pera mitir la conexin de una aplicacin al sistema de mensajer a o o a.

4.

Ejemplo

La gura 6 presenta una solucin de integracin de cuatro aplicaciones, que al o o principio no fueran diseadas teniendo en cuenta la integracin (y que est insn o a pirado en un sistema real que se usa en UNIJUI). Son aplicaciones muy distintas y desarrolladas con diferentes tecnolog El objetivo de esta solucin es hacer as. o que todas las llamadas telefnicas registradas por el Call Center System (CCS) o en su base de datos y que tengan algn coste para la empresa, sean tambin, u e registradas en su Debit System (DS). Adems de registrar dichas llamadas en a el DS, algunas informaciones de la llamada (por ejemplo: coste, hora de la llamada, ciudad y numero de destino) son enviadas por SMS y/o correo electrnico o al usuario que la hizo. En esta empresa los empleados que tienen una clave pueden acceder cualquier terminal telefnico, en cualquiera de las ciudades donde o est la empresa y hacer una llamada. Todas las llamadas son registradas y al n a del mes el empleado tiene que decir cules fueron hechas por razones de trabajo a

ZOCO'07 / CAEPIA

73

y cules fueron llamadas privadas, ya que las privadas tendrn que ser pagas por a a el empleado. La direccin del ujo de mensajes de la solucin est indicada con las echas o o a entre los Building Blocks de la gura 6. As que todo empieza con un mensaje en formato privado (1) desde el CCS que es traducido por un Message Translator (2) a un mensaje en el formato cannico (Canonical Data Model) (3). Despus de o e esta traduccin hay un Message Filter (4) que rechazar todos los mensajes que o a no sean de pago y enviar los dems a un Content Enricher (5) que debe aadir a a n al mensaje datos, como por ejemplo: nombre, telfono, correo, etc. Despus el e e mensaje llegar en un Recipient List (6) que enviar una copia del mensaje a los a a posibles canales de salida. El canal hacia el DS es del tipo Guaranteed Delivery (7) y siempre recibir una copia y los canales hacia el Mail Server (MS) y a el SMS Call Notier (SMS-CN) son de tipo Point-to-Point (8). Estos canales solamente recibirn un mensaje si tiene una direccin de correo y/o un numero de a o mvil. El mensaje hacia el SMS-CN ser ahora traducido a un formato privado o a de mensajes SMS (9) y enviado a un Datatype Channel (10), desde el cual la aplicacin SMS-CN lo leer. El otro ujo hacia el MS quitar del mensaje con un o a a Content Filter (11) informaciones que no sean de inters para enviar por correo. e En caso de que no consigan enviar el mensaje, tanto el MS como el SMS-CN le aadirn una descripcin del problema (12) y, a su vez, lo enviarn a un Invalid n a o a Message Channel (13). Considerando las topolog de integracin de aplicaciones expuestas en [2], as o clasicamos este ejemplo de la gura 6 como Hub-and-Spoke. Aqu el hub ser el Recipient List (6) y los spokes cada una de sus salidas (7 y 8) hacia a las aplicaciones DS, MS y SMS-CN.

5.

Conclusiones

La integracin es una tarea cada vez ms frecuente en las empresas, y que o a adems de tener un alto coste suele consumir muchos recursos. Para tales ema presas la necesidad de integracin es, en gran parte, consecuencia de la evolucin o o natural de su negocio. Enterprise Integration Information (EII) es una metfora a declarativa en la que el objetivo es ver todo el sistema como un gran modelo de datos; por el contrario Enterprise Application Integration (EAI) es una metfoa ra operativa en la que el objetivo es ver todo el sistema como un gran ujo de informacin. Una solucin de integracin usando sistemas de mensajer permio o o a te tener, entre otras ventajas, bajo acoplamiento y comunicacin as o ncrona, las cuales son muy importantes a la hora de escoger un estilo de integracin y dio sear dicha solucin. Los patrones presentados en [2] para el estilo de integracin n o o por medio de sistemas de mensajer aunque muy importantes, son demasiados a, abstractos para permitir su uso ms directo a la hora de disear la solucin de a n o integracin. o As que propusimos, en este art culo, una divisin de la solucin de integracin o o o en tres niveles y cuatro vistas para ayudarnos a disear y entender mejor dicha n solucin. Con esto tambin empezamos un proceso de investigacin, clasicacin o e o o

ZOCO'07 / CAEPIA

74

y formalizacin de todos los patrones para transformarlos en Building Blocks, o y as permitir disear la solucin de integracin arrastrando y conectando tales n o o bloques. Creemos que de momento debemos seguir trabajando hasta lograr este reto.

Referencias
1. Weiss, J.: Aligning relationships: Optimizing the value of strategic outsourcing. Global services report, IBM (2005) 2. Hohpe, G., Woolf, B.: Enterprise Integration Patterns - Designing, Building, and Deploying Messaging Solutions. The Addison Wesley Signature Series. AddisonWesley, Boston (10 October 2003)

ZOCO'07 / CAEPIA

75