MENSAJERÍA EN SISTEMAS DE INFORMACIÓN

Transcripción

1 Instituto de Computación Facultad de Ingeniería Universidad de la República MENSAJERÍA EN SISTEMAS DE INFORMACIÓN Informe de Proyecto de Grado 16 de diciembre de 2008 Montevideo - Uruguay Autores: Marcelo Caponi Pablo Rodríguez Defino Pablo Zamudio Supervisores: Ing. MSc. Leonardo Rodríguez Ing. Diego Rivero

2

3 Resumen La mensajería se ha consolidado como uno de los principales mecanismos de integración de aplicaciones logrando un alto nivel de desacoplamiento entre las partes involucradas. Existe experiencia acumulada en su uso, la cual se ve reflejada tanto en productos maduros que dan soporte a esta tecnología, así como en patrones de diseño específicos (patrones de mensajería) que apuntan a resolver problemáticas recurrentes en el área. Por otra parte, la tecnología de Web Services es un mecanismo de integración que permite comunicación entre aplicaciones sobre plataformas heterogéneas. Se trata de una tecnología madura, que ha evolucionado con la aparición de nuevas especificaciones que proponen soluciones estándares a problemas comunes. Los Enterprise Service Bus (ESB) son una plataforma que combina los modelos de integración antes mencionados, pudiendo lograr soluciones multiplataforma con bajo nivel de acoplamiento. Recientemente han surgido varios frameworks y ESBs que incorporan implementación nativa de algunos patrones de mensajería, ejemplos de estos son: Apache Camel, Spring Integration, Apache ServiceMix y Mule ESB. A su vez, algunos de estos patrones se ven reflejados en estándares que han surgido dentro de la tecnología de Web Services. Este trabajo se centra en el estudio exahustivo de los patrones de mensajería. Se analiza la implementación de éstos en base a las herramientas y tecnologías antes mencionadas, se proponen categorías para agrupar a los mismos y se concluye al respecto. Con el objetivo de evaluar las implementaciones propuestas, se desarrolla un caso de estudio en donde se integran varios componentes de naturaleza heterogénea aplicando patrones de mensajería.

4

5 Índice general 1. Introducción 7 2. Estado del Arte Conceptos Generales de Mensajería Que es Mensajería? Características y consideraciones a tener en cuenta en el uso de mensajería Sistemas de Mensajería Contextos de Aplicación Notaciones para especificar sistemas basados en mensajería Diagramas de propósito general Patrones de mensajería Herramientas para implementar sistemas basados en mensajería Sistemas de Mensajería Comerciales Frameworks Enterprise Service Bus Web Services y especificaciones WS-* Patrones de Mensajería en un contexto Orientado a Servicios Motivación Herramientas y tecnologías de soporte Análisis de Implementación de Patrones de Mensajería en un contexto Orientado a Servicios Patrones implementados usando Web Services Patrones implementables usando estándares WS-* Patrones implementables usando funcionalidades estándares de ESB Patrones implementables mediante la composición de patrones simples Patrones implementables usando componentes con lógica a medida Conclusiones

6 ÍNDICE GENERAL 4. Caso de Estudio: Loan Broker Requerimientos Análisis Modelado del dominio Contexto Proceso de negocio Diseño Decisiones Generales Comportamiento global Estructura de componentes Aspectos de mensajería Interacciones entre componentes Implementación Plataforma elegida Aspectos generales Detalles de la implementación Trazabilidad entre Diseño e Implementación de Patrones de Mensajería Alternativas no implementadas Integridad en facturación y respuesta al cliente de solicitudes resueltas Pérdida de solicitudes de cotizacion de prestamos Conclusiones Conclusiones y Trabajo a Futuro Conclusiones Trabajo a Futuro Bibliografía 91 Glosario 97 A. Gestión del Proyecto 99 A.1. Estado del Arte A.2. Propuesta de Implementación de Patrones de Mensajería en un contexto Orientado a Servicios A.3. Desarrollo de Casos de Estudio A.4. Documentación Final A.5. Cronograma

7 Capítulo 1 Introducción La mensajería propone un modelo en el que se integran aplicaciones a través del intercambio de mensajes de manera desacoplada y confiable. Con el correr de los años se ha consolidado como uno de los principales mecanismos para lograr integración de aplicaciones [53, 59, 65], existiendo en la industria experiencia acumulada en su uso y numerosas implementaciones estables [17, 18, 28, 23, 46, 2, 25]. Por otra parte, la tecnología de Web Services, los estándares WS-* que complementan esta tecnología y los Enterprise Service Bus (ESB) han ganado visibilidad en la actualidad como herramientas importantes para la integración de aplicaciones en ambientes orientados a servicios [90, 77, 89]. La tecnología de Web Services permite la integración de servicios desarrollados en plataformas heterogeneas. Los estándares WS-* surgen para agregar caracteristicas adicionales al uso de Web Services como por ejemplo confiabilidad, transaccionalidad, seguridad, entre otros. Los ESBs brindan una plataforma para la integración de aplicaciones basada en estándares que combina entre otras cosas: mensajería, Web Services, ruteo y transformación de mensajes, con el objetivo de coordinar y conectar aplicaciones de manera confiable. En [59] se intenta consolidar la experiencia en el uso de mensajería como mecanismo para la integración de aplicaciones, relevando un conjunto de buenas practicas y generalizándolas en patrones de mensajería, también conocidos como Enterprise Integration Patterns (EIP). Estos brindan una vista conceptual a problemas recurrentes en soluciones que usan mensajería, y proponen soluciones de referencia. En el capítulo final de [59] se analizan las tendencias en el contexto de integración de aplicaciones, y si bien no se estudia en profundidad la aplicación de patrones de mensajería en estos nuevos contextos, se sugiere que tecnologías como Web Services por ejemplo, podrían evolucionar incorporando muchos de los patrones propuestos como estándares. A su vez, han aparecido frameworks e implementaciones de ESBs que incorporan la implementación de varios de los patrones de mensajería identificados en [59], como por ejemplo Apache Camel [3], Spring Integration [44], Apache ServiceMix [8] y Mule ESB [29]. Este trabajo se centra en el estudio de los patrones de mensajería en un contexto de integración de aplicaciones en ambientes orientados a servicios, así como la factibilidad de su implementación en base a herramientas populares en este contexto, como son Web Services, estándares WS-* y ESBs. De acuerdo con lo planteado anteriormente, los objetivos de este trabajo son los siguientes: Entender soluciones basadas en mensajería. Esto implica entender qué es mensajería, qué aporta su uso en sistemas de información, qué consideraciones se deben tener en cuenta en su utilizacion y en qué contextos aplica su uso. También implica el estudio de qué aspectos son interesantes a la hora de diseñar este tipo de soluciones, qué herramientas existen para su especificación y qué problemas y soluciones recurrentes (patrones de mensajería) se pueden aplicar. 7

8 CAPÍTULO 1. INTRODUCCIÓN Estudiar el uso de patrones de mensajería en un contexto de integración de aplicaciones en ambientes orientados a servicios. Esto implica estudiar la utilidad de la aplicación de patrones de mensajería en este contexto. También implica el análisis de alternativas para la implementación de los mismos y el relevamiento de herramientas disponibles para tal fin. Como resultado del desarrollo de los objetivos planteados, este trabajo realiza las siguientes contribuciones al área de estudio: Relevamiento del estado del arte en lo que respecta a mensjaeria, incluyendo herramientas para modelado y diseño de soluciones basadas en mensajería. Relevamiento de herramientas disponibles para implementación de patrones en un contexto de integración de aplicaciones orientadas a servicios. Propuesta de implementación de patrones en un contexto de integración de aplicaciones orientadas a servicios. Categorización de patrones según su implementación en un contexto de integración de aplicaciones orientadas a servicios. Implementación de un caso de estudio que aborda las problematicas en el área, sobre la plataforma Apache ServiceMix. Se encontraron varios trabajos relacionados vinculados a las temáticas de mensajería, patrones de mensajería, patrones para soluciones orientadas a servicios y sus relaciones. A continuación se los lista, comentando brevemente el aporte de cada uno de ellos y contrastando sus enfoques con el enfoque de este trabajo: SOA Patterns - New Insights or Recycled Knowledge? [56] Este artículo examina el rol que cumplen los patrones de diseño en la adopción de nuevas tecnologías y estilos arquitectónicos, y en particular en la adopción de las arquitecturas orientadas a servicios. Estudia la utilidad de patrones de diseño de áreas relacionadas a las arquitecturas orientadas a servicios, e identifica la necesidad de que se generen nuevos patrones para problemas aún no atacados y que corresponden puntualmente al contexto SOA. En particular, y relacionado con lo estudiado en el presente trabajo, plantea la utilidad de los patrones de mensajería propuestos en [59] para atacar aspectos relacionados con mensajería en este tipo de soluciones. En nuestro trabajo se profundiza en este aspecto, estudiando la utilidad de estos patrones en un contexto de integración de aplicaciones orientadas a servicios y analizando alternativas para la implementación de los mismos. Enterprise Integration Patterns Exemplified in Java Business Integration [55] Este artículo analiza los beneficios de usar patrones de mensajería en un contexto de soluciones orientadas a servicios. Para esto desarrolla un caso de estudio aplicando patrones de mensajería que se implementan luego usando un ESB basado en la especificación Java Business Integration (JBI). Se logra mostrar con buen nivel de detalle como sería la implementación de los patrones identificados en el caso de estudio en base a las herramientas definidas. Sin embargo, el estudio se acota sólo a un número reducido de patrones. En contraposición, en nuestro trabajo se realiza un estudio en amplitud de todos los patrones de mensajería, tomando como herramientas no sólo el ESB, sino también Web Services y los estándares WS-*. Nuestro estudio no llega al nivel de detalle planteado en este artículo, pero brinda lineamientos generales de cómo se desarrollaría, y cubre la totalidad de los patrones de mensajería. Además en este proyecto se desarrolló un caso de estudio sobre una plataforma similar a la elegida en el artículo (ESB basado en JBI + Web Services + estándares WS-*), en el que se logran implementaciones de patrones de mensajería de caracteristicas similares. 8

9 CAPÍTULO 1. INTRODUCCIÓN Implementing Enterprise Integration Patterns Using Open Source Frameworks [57] Esta tesis se enfoca en el análisis de la implementación de los patrones de mensajería propuestos en [59] usando como plataforma frameworks open source como por ejemplo Apache Camel [3], Apache ServiceMix [8] y Mule ESB [29]. Se realiza una comparación de que patrones pueden ser resueltos con cada una de los frameworks antes mencionados, analizando varios aspectos de las implementaciones que se puede lograr con cada uno. Se desarrollan varios casos prácticos para estudiar la dificultad de las implementaciones que se pueden lograr con cada uno de los frameworks elegidos. Nuestro trabajo se enfoca en el mismo objetivo, pero sobre otra opción de plataforma (Web Services, estándares WS-* y ESBs). Mientras el enfoque en la tesis en cuestión es la comparación de las implementaciones de los patrones de mensajería que se pueden lograr usando los frameworks elegidos, sin brindarse descripciones de cómo serían estas implementaciones, nuestro trabajo se enfoca en brindar lineamientos generales de cómo lograr implementaciones de todos los patrones de mensajería sobre la plataforma elegida, sin analizarse posibles alternativas ni comparaciones sobre las mismas. Esta tesis presentada en Abril de este año fue encontrada recientemente, por lo que no fue analizada en profundidad. El resto de este trabajo se divide en cuatro capítulos. En el capítulo 2 se presenta el estado del arte en lo que a mensajería respecta, el cual da una visón general entre otras cosas de: contextos de aplicación, fortalezas y debilidades en su uso, herramientas de modelado, así como productos y estándares existentes, los cuales se requieren para llevar a cabo una solución basada en mensajería. El capítulo 3 estudia la aplicación de mensajería en un contexto de integración de aplicaciones orientadas a servicios. Se estudia la aplicación de patrones de mensajería en este contexto, analizando alternativas para su implementación y clasificándolos según aspectos comunes de éstas. En el capítulo 4 se estudia en detalle un problema concreto en donde la mensajería presenta un enfoque adecuado para su resolución. Se pasa por las etapas de análisis, diseño, e implementación de la solución, de forma de ilustrar los aspectos estudiados en los capítulos anteriores. El capítulo 5 resume el trabajo, presenta las conclusiones del mismo, y comenta las tendencias y posibles líneas de trabajo futuros en el área. Por último, en el apéndice A se describen aspectos de gestión de proyecto de este trabajo. De forma adicional, se incluyen tres documentos complementarios. En [78] se incluye el análisis completo de cómo se implementan cada uno de los patrones de mensajería presentados en [59], así como una categorización de los mismos según aspectos comunes de las implementaciones logradas. En [80] se incluyen resúmenes explicativos de varios de los estándares WS-* utilizados en este trabajo, que complementan las descripciones presentes en el capítulo 2. En [79] se incluye un resumen sobre ESB, que complementa la descripción presente en el capítulo 2. 9

10

11 Capítulo 2 Estado del Arte En este capítulo se introducen conceptos relacionados con mensajería con el objetivo de establecer un marco conceptual que sirva para el entendimiento del resto del documento. El capítulo consta de tres secciones descriptas a continuación. En la sección 2.1 se presenta el concepto de mensajería y conceptos relacionados. Se ilustran también contextos de aplicación de mensajería y se estudian las características y consideraciones que esta tecnología presenta. En la sección 2.2 se presenta un relevamiento de las notaciones existentes para modelar una solución basada en mensajería. Mediante ellas se pueden expresar aspectos interesantes del diseño de este tipo de soluciones. En la sección 2.3 se presentan herramientas existentes para implementar soluciones basadas en mensajería. Éstas van desde soluciones propietarias particulares para ciertas plataformas, hasta soluciones basadas en estándares independientes de la plataforma subyacente Conceptos Generales de Mensajería Que es Mensajería? La mensajería es una tecnología que permite que dos aplicaciones se comuniquen de manera confiable, asincrónica y con alto rendimiento. Al utilizar esta tecnología las aplicaciones se comunican a través de canales enviándose paquetes de datos denominados mensajes, como se muestra en la figura 2.1. Un canal funciona como una colección de mensajes que puede ser compartido por múltiples aplicaciones y utilizado concurrentemente. Las aplicaciones actúan con roles bien definidos en la comunicación: productor y consumidor. Un productor (o emisor) es una aplicación que envía mensajes escribiéndolos en un canal, mientras que un consumidor (o receptor) es una aplicación que recibe los mensajes leyéndolos del canal. En un esquema de este tipo tanto productor como consumidor no tienen que estar necesariamente disponibles al mismo tiempo para poder comunicarse. Esto se debe a que la comunicación en sí misma es llevada a cabo a través de los denominados sistemas de mensajería, que se presentan en la sección Figura 2.1: Dos aplicaciones comunicándose a través de Mensajería. 11

12 CAPÍTULO 2. ESTADO DEL ARTE Los mensajes son simplemente algún tipo de estructura de datos que consta de tres partes: un encabezado, una sección de propiedades y un cuerpo, como se ilustra en la figura 2.2. El encabezado contiene metadata acerca de los mensajes, esto es, quién los envió, su destino, entre otros. Esta información es utilizada por los sistemas de mensajería y en general es ignorada por las aplicaciones. La sección contiene un conjunto de parejas (nombre de propiedad, valor) que son cargadas por las aplicaciones con el objetivo de poder filtrar o rutear mensajes, basado en el valor de dichas propiedades. El cuerpo contiene los datos que se desean transmitir y es usualmente ignorado por los sistemas de mensajería. El formato del cuerpo de los mensajes varía dependiendo de el proveedor de mensajería, pero la mayoría de las implementaciones soportan texto plano, ráfagas de bytes y XML. Figura 2.2: Estructura de mensajes Características y consideraciones a tener en cuenta en el uso de mensajería A continuación se listan características que el uso de mensajería aporta a una solución y consideraciones a tener en cuenta a la hora de su uso tomadas de [59]. Características Bajo acoplamiento Este tipo de soluciones permite que quien envía los mensajes desconozca quien recibirá los mismos, cuál es la ubicación de ese componente o aplicación e inclusive cuándo recibirá dicho mensaje, con lo que reduce el acoplamiento. Comunicación remota El uso de mensajería permite que aplicaciones o componentes se comuniquen e intercambien datos estando distribuidos en distintos equipos de una red de forma transparente. Las aplicaciones se comunican con el sistema de mensajería y éste se encargará de entregar los mensajes a sus respectivos destinatarios. Integración de múltiples plataformas/lenguajes Los sistemas de mensajería por lo general brindan aplicaciones cliente para más de una plataforma, esto hace que aplicaciones desarrolladas en diferentes lenguajes puedan comunicarse. Comunicación Asíncrona El uso de mensajería permite que el emisor de un mensaje se pueda olvidar del mismo, sin tener que esperar a que lo procese el receptor. Esto hace que emisor y receptor no tengan que bloquearse durante el tiempo de su interacción, y por lo tanto podrán comunicarse inclusive en casos de indisponibilidad de alguno de ellos. De hecho, el productor del mensaje sólo espera a que el mensaje sea correctamente entregado al sistema de mensajería, y luego puede continuar con el resto de sus tareas, con la seguridad de que en algún momento el mensaje será entregado al receptor. Esto se conoce en el ámbito de mensajería como Send and Forget [59]. 12

13 CAPÍTULO 2. ESTADO DEL ARTE Comunicación confiable El uso de mensajería provee un mecanismo de envío confiable de mensajes, que otros enfoques más tradicionales como por ejemplo la invocación a métodos remotos no pueden asegurar. Al enviarse un mensaje, el sistema de mensajería lo persiste, para luego intentar enviarlo. Si por algún motivo el envío falla, por ejemplo por indisponibilidad de alguna de las partes, el sistema puede volver a reenviar el mensaje hasta que este sea entregado correctamente. Esto se conoce en el ámbito de mensajería como Store and Forward [59]. Operaciones sin conexión En aplicaciones que necesitan de sincronización de información pero no están conectadas todo el tiempo, puede ser de particular interés la mensajería, ya que permite que los datos que se desean sincronizar sean encolados, hasta el momento en que la aplicación pueda conectarse y sincronizarse. Mediación El sistema de mensajería actúa como mediador entre las aplicaciones que reciben y envían mensajes. Esto permite que las aplicaciones puedan usar al sistema de mensajería como un directorio de aplicaciones, lo cual facilita la integración. Procesamiento en paralelo Si se necesita mejorar los tiempos de respuesta, se puede disponer de varias instancias de un receptor a la espera de mensajes. Evitar la saturación Un problema que se da en la invocación a procedimientos remotos, es la saturación de un recurso ante múltiples llamadas al mismo recurso concurrentemente. Con el uso de mensajería se pueden evitar estos problemas, ya que por mas mensajes que se envíen a un recurso, el receptor los procesará de a uno. Consideraciones Modelo complejo de programación La naturaleza asincrónica de la mensajería implica que las aplicaciones tengan que reaccionar ante la eventual recepción de mensajes o envío de los mismos. Esto va en contraste con el enfoque de la programación flow-driven en donde el flujo de ejecución esta determinado por el programador, esto es, todas las instancias ejecutan el mismo flujo de sentencias. En algunos escenarios al usar mensajería esto no será así, por lo que puede que dificulte la programación, al tener que pensar partes de la aplicación como reacciones a eventos (mensajes) que se generen desde el MOM. Problemas de secuenciamiento En escenarios en donde es relevante el orden de entrega de mensajes pueden existir problemas pues, si bien el sistema de mensajería asegura que los mensajes serán correctamente entregados, no asegura nada respecto al orden. En estos casos se deben tener cuidados especiales para el re-secuenciamiento y procesamiento de los mensajes. Escenarios síncronos No todos los requerimientos se pueden llevar a un enfoque asíncrono. En algunos escenarios para completar una operación es necesario obtener el resultado del procesamiento de un mensaje. En estos casos se debe emular el enfoque síncrono. Rendimiento Interactuar con un sistema de mensajería agrega tiempo extra debido al trabajo necesario para empaquetar mensajes y persistirlos antes de que estos sean enviados. Soporte limitado de plataformas No todos los sistemas de mensajería tienen soporte para todas las plataformas. Incompatibilidad entre distintas soluciones En general las implementaciones de sistemas de mensajería trabajan con protocolos propietarios. Esto lleva a que muchas veces dos soluciones de mensajería de distintos proveedores no puedan interconectarse fácilmente, y se deba realizar trabajo adicional para lograr la interconexión deseada. 13

14 CAPÍTULO 2. ESTADO DEL ARTE Sistemas de Mensajería Las capacidades de mensajería son típicamente provistas por sistemas de software denominados sistema de mensajería o Message Oriented Middleware (MOM). Los MOMs son componentes especializados en el manejo de mensajes. Su principal cometido es participar como intermediario entre la comunicación de aplicaciones, logrando desacoplarlas. Las aplicaciones se comunican con los sistemas de mensajería a través de clientes provistos por los proveedores de MOMs. Estos brindan interfaces mediante las cuales las aplicaciones pueden enviar y recibir mensajes como se ilustra en la figura 2.3. Figura 2.3: Comunicación basada en mensajes a través de un MOM El hecho de que tanto los equipos como las redes que los conectan no son cien por ciento seguros y confiables, hace relevante la existencia de los MOMs. Por citar un ejemplo, puede que no siempre que se envíe un mensaje el destinatario esté activo y disponible, o en caso de que lo esté, podría ser que la red de comunicación presente indisponibilidad. Previo a la aparición de los MOMs, para atacar este tipo de problemática se implementaba manualmente la retransmisión de mensajes hasta asegurarse que el receptor los había procesado. Esto hacía que cada vez que se deseaba usar mensajería se debieran afrontar una y otra vez los mismos problemas. Como respuesta a esto, surgen los sistemas de mensajería, que permiten a quien envía un mensaje olvidarse del mismo luego del envío, delegando al sistema de mensajería la responsabilidad de asegurar la entrega del mensaje a su destinatario. A continuación se enumeran los componentes de un sistema de mensajería así como su responsabilidad según [59]: Canales: Son direcciones lógicas en el sistema de mensajería a las cuales las aplicaciones hacen referencia, y es donde colocan los mensajes para ser entregados. Mensajes: Son las entidades que transporta el sistema de mensajería. Puntos de acceso (endpoints): Es el punto de entrada al sistema de mensajería. Para poder acceder a un canal, las aplicaciones tienen que conectarse al sistema de mensajería, y dicha conexión se da a través de un endpoint. Tubos y filtros (pipes and filters): Son los componentes encargados de procesar mensajes complejos en varios pasos de forma flexible. Enrutador de mensajes (message router): Cuando un mensaje debe ser procesado pasando por varios destinos, o tiene que seguir cierta ruta óptima, los enrutadores de mensajes se encargan de tal problemática independizando a las aplicaciones de este manejo. Componentes de transformación de mensajes: Estos componentes son filtros particulares que se encargan de realizar transformaciones para poder comunicar aplicaciones que utilizan formatos de mensaje diferentes. 14

15 CAPÍTULO 2. ESTADO DEL ARTE El proceso de transmisión de mensajes se descompone en cinco pasos: 1. Crear El emisor crea un mensaje y coloca en el los datos que desea transmitir. 2. Enviar El emisor coloca el mensaje en un canal. 3. Entregar El sistema de mensajería transporta el mensaje logrando que este esté disponible para el receptor. 4. Recibir El receptor lee el mensaje desde el canal. 5. Procesar El receptor extrae los datos del mensaje. La figura 2.4 ilustra los pasos anteriormente descritos, se puede apreciar la aplicación de los conceptos: Send and forget y Store and forward, éstos se dan en los pasos 2 y 3 respectivamente. Observando el paso 2, se puede ver que una vez que la aplicación entrega el mensaje en el canal, puede seguir ejecutando dado que esta delegó la entrega del mensaje al sistema de mensajería. La aplicación confiará en que el receptor recibirá el mensaje, y no esperará hasta que esto ocurra. En el paso 2, en el momento que la aplicación entrega el mensaje en el canal, el sistema de mensajería lo almacena. Luego en el paso 3, el sistema de mensajería entrega el mensaje redirigiéndolo a la computadora destinataria en la que es nuevamente almacenado. Este proceso puede ser repetido varias veces hasta que el mensaje se persista en la máquina destino. Figura 2.4: Pasos para la transmisión de mensajes en un MOM Por lo general los sistemas de mensajería soportan alguno de estos modelos de comunicación: Point-to-Point Este modelo es basado en canales punto a punto. Cuando una aplicación produce un mensaje, lo coloca en un canal de este tipo y un receptor recibirá el mensaje. A este tipo de canales se pueden suscribir varios interesados en recibir mensajes, pero solo uno obtendrá cada mensaje. El sistema de mensajería se encargara de determinar cual de los destinatarios subscritos obtendrá el mensaje. Publish-Subscribe En este modelo se permite que una aplicación pueda enviar mensajes a varios destinatarios simultáneamente. Para esto, las aplicaciones colocan los mensajes en un canal que corresponde a cierta tópico definido, el cual tiene el siguiente comportamiento: los interesados en recibir mensajes del tópico se suscriben al mismo, el emisor coloca el mensaje en el canal, y una copia del mismo será entregada a cada uno de los subscritos al mismo. 15

16 CAPÍTULO 2. ESTADO DEL ARTE En general, los MOMs brindan varias de las características y servicios que se describen a continuación. Garantía de Entrega de mensajes Dos aplicaciones que se están comunicando mediante un MOM no necesitan estar conectadas simultáneamente para que el envío de los mensajes sea exitoso. El MOM asegura que los mensajes enviados a un destinatario que no esté conectado, serán entregados al mismo cuando este vuelva a estarlo. Comunicación Asíncrona Luego de que una aplicación envía un mensaje a otra, el MOM permite que la aplicación cliente siga trabajando sin tener que esperar que el mensaje sea procesado por el destinatario del mismo. Soporte transaccional El uso de transacciones es soportado, y además en general se proveen mecanismos de integración con otros recursos, de forma que las transacciones contra el MOM se puedan incorporar a transacciones globales. Entrega en orden, y una sola vez Los MOMs proveen garantías de que los mensajes serán entregados una sola vez, y que además los mismos serán entregados respetando el orden en que fueron enviados. Servicios de ruteo de mensajes Permiten definir reglas de ruteo a nivel de configuración mediante las cuales al enviar un mensaje a un determinado canal, los mismos son enrutados según las configuraciones indicadas. Servicios de notificación En algunos casos las aplicaciones que envían los mensajes necesitan tener una forma de saber si el mensaje enviado ya fue procesado por el consumidor u obtener el resultado generado en éste. Para esto, los MOMs proveen mecanismos de notificación, de forma de que al ser procesado el mensaje por su consumidor se pueda entregar el resultado de este procesamiento al productor del mismo Contextos de Aplicación A continuación se describen contextos en los que la aplicación de mensajería puede ser beneficioso según [59][54]. Integración de aplicaciones Los ambientes de aplicaciones empresariales están caracterizados por su variabilidad y necesidad de facilitar el cambio de las mismas. La Integración de Aplicaciones Empresariales (EAI, por su nombre en ingles Enterprise Application Integration) consiste de conectar el desarrollo interno de la empresa con aplicaciones de terceros y probablemente con sistemas legados (de la empresa misma o de otras empresas adquiridas) de manera tal de poder compartir los datos que estas generan y unificar procesos de negocio. Por la naturaleza antes nombrada, las aplicaciones a integrar normalmente son desarrolladas, implantadas y mantenidas de manera independiente incluso dentro de una misma empresa. Como solución a esto y para evitar un alto acoplamiento entre cada par de sistemas a integrar, la arquitectura resultante tiende a basarse en algún componente que auspicia de mediador. Los denominados Buses de Información [59], mensajería y la distribución de datos dependientes de las fuentes (source-driven) son características inherentes de la EAI. La idea de un componente mediador es desacoplar las interfaces, permitiendo la evolución independiente de los sistemas, extrayendo la comunicación y coordinación entre los sistemas a un componente extra. Un acercamiento al problema basado en mensajería se ajusta directamente a los objetivos de la EAI y, por ejemplo, un middleware que implemente primitivas del tipo publish-subscribe o point-to-point es candidato para implementar componentes de tipo mediador. 16

17 CAPÍTULO 2. ESTADO DEL ARTE Diseminación de la Información Es la capacidad de poder suministrar información periódicamente a múltiples destinatarios. Se trata de una necesidad en sistemas de notificación de servicios, sistemas de control de tiempo real, o sistemas de monitoreo de bolsa de valores, entre otros. La mensajería podría dar un diseño robusto y flexible a este tipo de sistemas, de manera tal que las necesidad de filtrado de información no deba ser resuelta ni por los emisores ni por los receptores de la información. Esto es, un sistemas de mensajería se encargaría de recibir notificaciones y entregar las mismas a los destinatarios interesados. Sistemas de Monitoreo Distribuido En general cualquier forma de monitoreo es compatible con un acercamiento basado en manejo de eventos o de mensajería [54]. Como ejemplo, el monitoreo y control de las redes de comunicación consiste en relevar las capacidades de la red, estadísticas de funcionamiento, alertas y cambios de configuración en la misma. En particular los sistemas de monitoreo a menudo requieren una vista de alto nivel del funcionamiento de la red. Una falla en la red o un intento de intrusión en la misma quizás conduzca a que se disparen una multitud de eventos de diferente granularidad y normalmente el desafío de un administrador es encontrar la principal causa tan rápido como sea posible. Un procesamiento en tiempo real de estos eventos para detectar los patrones en forma de eventos compuestos, es una técnica muy poderosa para lograr lo anteriormente descrito. Un acercamiento al problema basado en manejos de eventos o en mensajería es recomendable, ya que permite tener un conjunto de componentes comunicados entre sí, que se encarguen de sectorizar los eventos ocurridos en la red y posteriormente comunicarse para notificar de sucesos que se disparen en cascada provocados por causas comunes. Sistemas Móviles Los sistemas móviles son sistemas distribuidos en los cuales un subconjunto de los nodos (por ejemplo los clientes en un contexto de arquitectura cliente/servidor) o incluso todos los nodos son móviles, lo cual nos lleva a una red con una topología dinámica. En estos sistemas los servidores centralizados y las comunicaciones sincrónicas son inapropiadas. Una infraestructura para sistemas móviles tiene que poder lidiar con reconfiguraciones, por lo que el manejo de estos eventos basado en mensajería puede ser pertinente Notaciones para especificar sistemas basados en mensajería Al momento de plantearse el trabajo o una tarea compleja relacionada con la construcción de un sistema, es conveniente utilizar diagramas o notaciones que permitan mostrar determinados aspectos interesantes del mismo a un determinado nivel de abstracción. El diagrama en sí es útil no solo para la planificación que realiza una persona respecto al trabajo a realizar, sino que es también una herramienta de comunicación importante para que otros entiendan los aspectos importantes que se manejan en el desarrollo. Los diagramas ofrecen vistas parciales y abstraen el sistema a desarrollar, por lo tanto no contienen cada detalle del sistema en sí, sino que es una aproximación a la realidad que éste representa. En esta sección se enumeraran varias especificaciones, diagramas y lenguajes de modelado junto con sus características, con el fin de mostrar que aspectos de un sistema basado en mensajería se puede detallar con cada uno. Para los sistemas basados en mensajería es deseado poder especificar clara y profundamente aspectos de la comunicación entre las partes involucradas como ser: comportamiento interno, estructura de los canales, como se define el flujo de la información y cómo se propaga, por ejemplo, la ocurrencia de un mensaje o un evento en un determinado componente o modulo del sistema que se modela. Basado en lo anterior, se pueden enumerar características deseables que debería cubrir una notación estándar para ser utilizada en el modelado de un sistema basado en mensajería: Contexto en que reside el sistema Lógica de la comunicación 17

18 CAPÍTULO 2. ESTADO DEL ARTE Comportamiento interno de los componentes Estructura de los canales de comunicación Propagación de eventos o recepción de mensajes por parte del sistema A continuación se describen herramientas de modelado agrupadas en dos categorías: diagramas de propósito general y patrones de mensajería. Se verá en cada sección las características de cada herramienta haciendo hincapié en las facilidades que estas brindan a la hora de analizar un sistema basado en mensajería Diagramas de propósito general Los diagramas y especificaciones enumeradas en las siguientes subsecciones corresponden a notaciones de propósito general para el modelado de sistemas. Todos tienen como característica que son ampliamente utilizados en el desarrollo de sistemas y en mayor o menor medida han sido adoptados en los procesos de construcción de aplicaciones de múltiples naturalezas o pertenecientes a diferentes paradigmas de programación (orientación a objetos, orientación a eventos, programación estructurada, etc.) Unified Modeling Language El Unified Modeling Language [37] (UML de aquí en mas) tiene como fin poder visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir uno o varios modelos del sistema, incluyendo aspectos conceptuales tales como son el comportamiento del mismo, procesos de negocio y funciones del sistema, y aspectos concretos como estructura interna o distribución física. A continuación se muestran algunos de los diagramas existentes en la especificación en su versión 2.1 [47] que modelan aspectos interesantes respecto a los sistemas basados en mensajería. Diagramas de Estado Estos brindan una forma de modelar sistemas que trabajan basados en los diferentes estados que pueden tomar los conceptos que lo componen. En cada estado, el sistema responde a un evento de una determinada manera (por ejemplo realizando una determinada acción y cambiando de estado o quedándose en el mismo). Los eventos, llamados triggers en el contexto de UML 2.1, pueden ser generados externa o internamente al sistema. La idea es modelar un sistema mostrando sus posibles estados, las posibles transiciones entre éstos y los eventos/acciones que causan cambios. Los eventos se marcan con etiquetas llamadas triggers y se pueden acompañar de una guarda de condición que especifica cuando un determinado evento externo aplica para ser tomado en cuenta por el sistema. También se pueden marcar las transiciones para mostrar los efectos que tienen en el sistema, a esto se lo llama acciones. Además de las acciones asociadas a las transiciones entre estados, se pueden asociar acciones a los estados del sistema. Estas acciones se pueden disparar cada vez que un estado es visitado o cuando se lo abandona e incluso se pueden definir acciones para cuando el sistema esta en un determinado estado. Algo interesante es que estos diagramas soportan estados compuestos, en los cuales se puede descomponer un estado en un numero acotado de sub estados. Este tipo de modelado de un sistema puede servir para demostrar el comportamiento de un componente ante los estímulos externos al mismo. En un contexto de mensajería se podría, por ejemplo, modelar sencillamente el comportamiento de un componente que filtre y redirija los mensajes a otros componentes. Diagramas de Actividad Las actividades pueden describirse como paquetes de trabajos, las mimas incluyen cierta cantidad de trabajo y lógica a cualquier nivel de abstracción. En un nivel alto de abstracción, las actividades pueden corresponderse a un determinado proceso de negocio y en un nivel mas bajo las actividades pueden representar procedimientos individuales a ser implementados en algún lenguaje. Estos 18

19 CAPÍTULO 2. ESTADO DEL ARTE diagramas representan cómo fluye el trabajo a realizar y en qué etapas se realizan los diferentes trabajos o actividades. La manera de denotar el flujo de la actividad es mediante transiciones que se representan como flechas entre las actividades del diagrama. La manera más común de modelar los datos que pasan entre dos actividades es mediante pins, los cuales figuran como pequeñas cajas en los extremos de una transición. Los pins funcionan tanto como entradas o salidas para una actividad, pueden ser nombrados y contener pequeñas flechas para indicar la dirección en que viajan los datos entre actividades. De manera análoga a los diagramas de flujo, los diagramas de actividad pueden contener puntos de decisión y puntos de unión, ambos representados con un diamante. Con un diagrama de actividad se puede representar flujos de actividades concurrentes mediante un nodo fork, que no es más que una línea gruesa de la cual salen y luego nodos join iguales en apariencia, pero que sirven para unificar los flujos que llegan de varias transiciones de una manera sincronizada. Un aspecto útil e interesante de este tipo de diagramas en el contexto de mensajería, es el uso de señales que son introducidas en la especificación 2.1 de UML. Su función principal es la de mostrar cómo una señal/evento externo/interno modifica el comportamiento del sistema en lo referente al flujo de tareas a realizar. Como ya se dijo estas señales pueden ser externas, esto es otro sistema envía un mensaje al nuestro o se produce un evento que lo afecta y por lo tanto se debe reaccionar al mismo; o internas en los casos en que nuestro sistema es el encargado de interactuar con otro sistema enviando un mensaje o disparando un evento en el sistema destino. Esto permite modelar fácilmente cómo se comporta un componente en un ambiente de mensajería, ya que se puede especificar las actividades y procesamientos que realiza el mismo ante la recepción de un mensaje y en caso de ser necesario enviar un mensaje a otro componente. Una especialización interesante de los diagramas de actividad son los Interaction Overview introducidos en UML 2.1. Esencialmente son actividades que también pueden incluir diagramas de secuencia o de comunicación. La idea es embeber ocurrencias de interacciones en un diagrama de actividad con el fin de agregar granularidad o un mejor entendimiento de como se interactúa con agentes externos a la actividad representada. Mientras que las actividades son buenas para representar procesos de negocio en las aplicaciones, los diagramas de secuencias y de comunicaciones son buenos para especificar las reglas de tiempo o de ruteo en casos específicos, por lo que esta especialización unifica ambos aspectos. Diagramas de Secuencia Permiten modelar la interacción entre instancias del modelo mediante los mensajes que ocurren durante la misma. Estas instancias pueden ser objetos del modelo de dominio, en caso de que se quiera un modelado a bajo nivel, o también pueden ser componentes e incluso sistemas distintos. Dado que cada instancia que interactúa en estos diagramas cuenta con una linea de vida, el diagrama da un sentido del tiempo en el cual se realiza el envío de mensajes, con lo que se puede llegar a representar fácilmente el procesamiento asincrónico entre instancias, los mensajes que las provocan y los mensajes resultado de dichos procesamientos. Si bien los diagramas de secuencia son muy útiles para modelar casos de uso, también pueden funcionar para esquematizar la comunicación entre instancias (sistemas, componentes, clases, etc.) teniendo en cuenta la relación temporal entre mensajes. Por otra parte, estos diagramas pierden claridad cuando se trata de modelar interacciones condicionales, en casos que las condiciones son complejas. Diagramas de Comunicación Estos diagramas brindan una manera alternativa de visualizar la interacción entre instancias. Los diagramas de comunicación muestran la misma información que los diagramas de secuencia, pero con una estructura y organización similar a la de un diagrama de objetos de UML, lo que los hace mas utilizados para modelar la comunicación entre instancias de objetos en un determinado sistema. En las comunicaciones se enfatiza la conexión entre las instancias. De este modo las interacciones muestran como los caminos de comunicación entre las instancias; esto en contraste con los diagramas de secuencia que no hacen asunciones de cómo se rutean los mensajes entre instancias. Además las comunicaciones no toman en cuenta el factor temporal de la interacción, mientras que en los diagramas de secuencia el orden cronológico de los mensajes esta denotado 19

20 CAPÍTULO 2. ESTADO DEL ARTE en la posición de los mismos en las lineas de vida de las instancias. Estos diagramas pueden ser útiles en un contexto de mensajería para los casos en que sea interesante modelar la interacción de varios componentes y como los mensajes se van ruteando entre los mismos Signal Wiring Diagrams Este tipo de diagramas son propuestos en [54] y detallan un sistema no enfocándose en la estructura de sus componentes, sino en las señales que intercambian entre sí. Los diagramas antes descritos (UML) muestran cómo partes seleccionadas de los sistemas se conectan o interoperan. Los Signal Wiring Diagramas (SWD de aquí en mas) se basan en la metáfora del diseño a nivel de hardware en el que se describe la conectividad de un sistema basándose en un esquema similar al utilizado en el cableado de hardware. Los diagramas pueden funcionar como un mapa, mostrando los itinerarios que recorren las señales para ir de un componente a otro. Haciendo un paralelismo entre el diseño de componentes de software y circuitos integrados, las funcionalidades en ambos se logran conectando funcionalidades mas granulares de los componentes integrantes del sistema general. Los SWD muestran entonces a los objetos/componentes de una manera muy similar a los que serían los circuitos integrados en un contexto de electrónica a bajo nivel. En la figura 2.5 se muestra cómo los componentes se envían mensajes con el fin de resolver la comunicación entre un procesador de comandos y los destinatarios de estos. En el ejemplo se muestra qué interfaz necesita el procesador de comandos para interactuar con otros componentes y quienes brindan la implementación de dicha interfaz, también se detalla cómo funciona el mecanismo de despacho en tiempo de ejecución para el uso de la interfaz a nivel del procesador de comandos. Figura 2.5: Ejemplo de un Signal Wiring Diagram En resumen, los SWD abstraen la estructura de los componentes con el fin de mostrar cómo se dan las comunicaciones entre los mismos en tiempo de ejecución (se enfoca en que señales están disponibles en un determinado sistema y que recorrido realizan las mismas al propagarse). Cuando un sistema esta basado en componentes interconectados por señales de eventos, los caminos que recorren estas señales se tornan cruciales para entender el sistema a un nivel de lógica de negocio y en términos de dónde se originan las señales, a qué componentes afectan y en qué orden. Usualmente cuando un sistema orientado a eventos no funciona bien, las fallas que ocurren están relacionadas a las señales que se disparan y al recorrido de las mismas (incluyendo las acciones que se disparan en cada caso). Los diagramas de comunicación de UML (vistos anteriormente) comparten similitudes con los SWD, pero muestran solo el conjunto de señales que ocurren en un escenario en particular, a diferencia de los SWD que permiten mostrar toda la secuencia de eventualmente todos los mensajes. Sin embargo los diagramas de comunicación muestran bien cómo se secuencian los mensajes (al tener la posibilidad de numerarlos), cuando los objetos que interactúan no se acumulan en un numero grande. Los diagramas de interacción son útiles cuando se quiere ilustrar al detalle los tiempos de interacción entre componentes, pero no son prácticos para describir la operativa 20

21 CAPÍTULO 2. ESTADO DEL ARTE entera de un sistema o subsistema, sobre todo cuando hay involucrada lógica condicional. Los SWD no están diseñados para remplazar otros tipos de diagramas, sino que los complementan, dando una vista diferente de conectividad e interacción a nivel de señales y su propagación Systems Modeling Language Systems Modeling Language [36] (SysML de aquí en mas) es un lenguaje de modelado gráfico de propósito general para la especificación de análisis, diseño y verificación de sistemas complejos, por ejemplo los que refieren a componentes de hardware, software, procedimientos, entre otros. En particular el lenguaje provee representaciones gráficas con un fundamento semántico para el modelado de los requerimientos de un sistema, su comportamiento, su estructura y caracterización, lo cual se utiliza para integrarlo con otros modelos de análisis para la ingeniería de sistemas. La especificación de SysML [45] representa un subconjunto de UML 2.1 con las extensiones necesarias para satisfacer los requerimientos de UML for Systems Engineering RFP [48]. Dentro de esta especificación se incluye un diagrama particularmente interesante para la especificación de soluciones basadas en mensajería, los Block Diagrams. Estos diagramas permiten representar la estructura de un determinado sistema (en su más alto nivel de comprensión). Los Block son unidades modulares en la descripción de un sistema, cada uno define una conjunto de features que describen un determinado elemento de interés. Cada una de estos puede incluir features tanto estructurales como de comportamiento, como ser propiedades u operaciones para representar el estado del sistema y el comportamiento que un sistema puede exhibir. Los diagramas pueden ser útiles para representar elementos correspondientes a todas las fases de la especificación de un sistema y también a los diferentes tipos de sistemas. Entre las utilidades se incluyen descomposiciones lógicas o físicas de un sistema, especificación de partes de software, hardware u otro tipo de construcciones. A cada una de estas partes se les puede especificar un modo de interacción el cual puede tener diferentes significados según su contexto, como pueden ser operaciones en componentes de software, transiciones entre estados, flujos de entrada/salida o interacciones continuas. En esto último es en donde UML 2.1 falla, ya que no provee de manera nativa la posibilidad de representar un intercambio de información sin tener que especificar cómo se inicia dicho intercambio o cómo se mantiene el mismo. Como se dijo anteriormente, un Block puede incluir propiedades que permiten especificar valores, partes o referencias a otros Blocks. Los Ports son un tipo de propiedad especial usado para especificar los tipos de interacción permitidos entre diferentes Blocks. Existen 2 tipos de Ports para estos diagramas, los FlowPorts que permiten describir un flujo de entrada o salida entre un Block y su entorno mediante puntos de interacción (puede representar flujos de datos, materiales, energía, etc.), y los StandardPorts que especifican los servicios que brinda/requiere un determinado Block a/de su ambiente a través de la especificación de interfaces bien definidas. Estos últimos pueden ser utilizados en el contexto de soluciones SOA o para denotar intercambios bidireccionales de información, del tipo P2P o intercambio de señales para el procesamiento asíncrono. En un diagrama de este tipo también se puede especificar comportamiento mediante lo que la especificación de SysML llama Allocations, lo cual permite mostrar el comportamiento de un Block y sus propiedades mediante por ejemplo diagramas de estado y de actividad. Dado que los Blocks están basados en las clases de UML, extendidas como UML composite structures [47], se puede especificar el funcionamiento interno de un Block de manera similar a como se especifica el de un componente de UML. En la figura 2.6 se pueden ver los diferentes blocks que interactúan, así como el tipo de ports que los conectan, las interfaces que exponen y cómo todos los blocks componen un block mas general (que en este caso representa un destilador). 21

22 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.6: Ejemplo de un Block Diagram Existe una gran similitud entre los SWD y los Block Diagrams dado de que ambos buscan representar la estructura interna de un sistema de manera global y fijar claramente cuáles son las interacciones entre los componentes de la estructura. En ambos casos se puede detallar el tipo de las interacciones que ocurren, por ejemplo cuando las interacciones se hacen de manera explícita y cuando no. Ambas representaciones, en principio, no detallan cómo es la estructura de la comunicación, pero dan la pauta de como se conectan los componentes de un sistema y cómo fluye la información entre estos desde una vista global Specification and Description Language La especificación de SDL [42] fue desarrollada y estandarizada por ITU-T [21], en un principio para modelar de manera estándar el funcionamiento de los sistemas utilizados en el sector de las telecomunicaciones. Estos sistemas consisten normalmente de procesos concurrentes que se comunican entre sí enviándose señales, por lo que se podría pensar que entre dichos procesos existe un intercambio de información mediante algún tipo de mensajería. SDL fue diseñado para describir un sistema no solo desde el punto de vista de cómo procesa internamente un sistema cada mensaje que recibe, sino que también permite mostrar cómo el sistema interactúa con agentes externos a éste, lo cual lo hace valioso para la representación del funcionamiento de sistemas distribuidos. Desde un punto de vista más específico las señales que se representan en un diagrama SDL pueden considerarse como notificaciones de eventos o incluso mensajes que son enviados entre aplicaciones, por lo tanto pueden ser de interés para el desarrollo de aplicaciones que manejen estas características en sus comunicaciones. Dentro de los varios diagramas que conforman SDL, son de interés para el contexto de soluciones de mensajería los diagramas: State Machine Diagrams y Block Diagrams. Los State Machine Diagrams tienen una similitud clara con los diagramas de actividad de UML, ya que están basados en la representación de un sistema como una maquina finita de estados, mostrando cuales son los flujos de la información que se procesa, los diferentes estados en los que se encuentra el proceso, puntos de decisiones y tareas que se realizan entre las transiciones que existen entre diferentes estados, así como de qué manera y en dónde el sistema envía o recibe señales desde o hacia aplicaciones externas. En los Block Diagrams se considera a los sistemas o procesos como entidades que se comunican intercambiando señales. Se denotan estos procesos con una figura llamada Block (un polígono octogonal) y estos se conectan mediante signalroutes, representaciones de canales de comunicación, en los cuales 22

23 CAPÍTULO 2. ESTADO DEL ARTE se ponen etiquetas que identifican los nombres de las señales que por ellos se transfiere. La naturaleza de los mensajes enviados por los canales de comunicación en SDL se asume asíncrona y la manera de determinar el comportamiento respecto al procesamiento de los mensajes para evitar comportamientos indeterminados es mediante una definición clara del orden en que se envían y se reciben estos mensajes sin importar el retraso o defasaje que pueda existir al transmitir los mismos por el canal de comunicación Patrones de mensajería Como se dijo en la sección la mensajería puede ser utilizada en el contexto de la integración de aplicaciones. El abordar la integración de aplicaciones presenta una dificultad grande ya que por definición debe lidiar con múltiples aplicaciones corriendo en plataformas heterogéneas normalmente distribuidas. El obtener resultados satisfactorios en este tipo de tareas está fuertemente basado en la experiencia previa de las personas que la lleven a cabo, ya que no se encontraron metodologías que cubran el tema. Dicha experiencia puede plasmarse en buenas prácticas que intentan resolver los problemas que se abordan recurrentemente al plantear la integración de aplicaciones. Los patrones de mensajería propuestos en [59] surgen para encapsular soluciones tipo a problemas comunes dentro del ámbito de la integración de sistemas basada en mensajería. Este tipo de soluciones se suelen organizar según el enfoque propuesto por las arquitecturas de Pipes-and-Filters, por lo que en general los distintos componentes se encadenan como filtros, enlazados mediante el uso de canales de comunicación. El uso de los patrones apunta a la resolución de diversas problemáticas a nivel de los canales de comunicación, de los mensajes enviados a través de estos, de los componentes que consumen estos mensajes, del ruteo y transformación de los mismos, entre otros. Cada patrón presenta un problema de diseño específico, discute las consideraciones que rodean al problema y también las diferentes variables que se pueden manipular para llevar a cabo un buen diseño. Finalmente presentan una solución que intenta balancear las diferentes variables que existen en el problema planteado. De los conceptos enumerados en la sección 2.1.3, referentes a los componentes de un sistema de mensajería, surgen las diferentes categorías que agrupan los patrones. A continuación se detalla la clasificación que se propone en [59] junto con los patrones que la componen y el conjunto de problemas tipo que resuelven: Messaging Channel Patterns Resuelven distintos problemas de transporte de los mensajes entre aplicaciones. Por ejemplo, las aplicaciones que envían información por un canal no tienen por qué conocer cual es el receptor final de los datos que produce, pero seleccionando un canal en particular el productor puede asegurarse que quien reciba la información es alguien que la esperaba. Apuntan a especificar características de los canales de comunicación a utilizar, como por ejemplo: si el mensaje es enviado a uno o a muchos receptores, garantía de entrega de los mensajes que se transportan por el canal, expiración de los mensajes enviados al canal, entre otros. Los patrones que integran la categoría son: Message Channel, Point-to-Point Channel, Publish-Subscribe Channel, Datatype Channel, Invalid Message Channel, Dead Letter Channel, Guaranteed Delivery, Channel Adapter, Messaging Bridge, Message Bus. Message Construction Patterns Abordan el diseño de los mensajes que envían los diferentes participantes de una comunicación. Por ejemplo, en el intercambio que se realiza entre dos aplicaciones, la información se envía insertándola en un mensaje. Apuntan a especificar la información que contienen los mensajes, su semántica, información adicional para permitir su procesamiento adecuado, entre otros. Los patrones que integran la categoría son: Message, Command Message, Document Message, Event Message, Request-Reply, Return Address, Correlation Identifier, Message Sequence, Message Expiration, Format Indicator. Message Routing Patterns 23

24 CAPÍTULO 2. ESTADO DEL ARTE Están relacionados con el ruteo de los mensajes desde una aplicación a otra. Por ejemplo, permiten desacoplar los componentes que realizan en conjunto el procesamiento en etapas de determinada información, logrando que la secuencia de pasos a realizar dependa de un conjunto de condiciones. Apuntan a la configuración de rutas por las que deben pasar los mensajes para su procesamiento, independizando a quien envía o recibe los mensajes de esta lógica. Los patrones que integran la categoría son: Message Router, Content-Based Router, Message Filter, Dynamic Router, Recipient List, Splitter, Aggregator, Resequencer, Composed Message Processor, Scatter-Gather, Routing Slip, Process Manager, Message Broker. Message Transformation Patterns Permiten definir el manejo de transformaciones que pueden realizarse sobre los mensajes que se intercambian, en lo que refiere a los diferentes formatos requeridos por cada aplicación, así como también modificaciones automáticas que se realizan sobre los mensajes. Los patrones que integran la categoría son: Message Translator, Envelope Wrapper, Content Enricher, Content Filter, Claim Check, Normalizer, Canonical Data Model. Messaging Endpoint Patterns Dan pautas relacionadas a la generación y el consumo de mensajes, especificando por ejemplo como un productor puede interactuar con el canal para producir un mensaje o como un receptor puede comportarse ante la ocurrencia de un nuevo mensaje. Los patrones que integran la categoría son: Message Endpoint, Messaging Gateway, Messaging Mapper, Transactional Client, Polling Consumer, Event-Driven Consumer, Competing Consumers, Message Dispatcher, Selective Consumer, Durable Subscriber, Idempotent Receiver, Service Activator. System Management Patterns - Indican cómo atacar las necesidades de administración, monitoreo y testeo de los componentes del sistema y de los canales de comunicación. Un ejemplo de esto es la necesidad de extraer información sobre los datos que circulan por los canales, con el fin de monitorear cual es la capacidad de procesamiento del sistema en general y poder así detectar caídas en el rendimiento. Los patrones que integran la categoría son: Control Bus, Detour, Wire Tap, Message History, Message Store, Smart Proxy, Test Message, Channel Purger Herramientas para implementar sistemas basados en mensajería A la hora de implementar soluciones basadas en mensajería existe diversidad de opciones. Estas van desde soluciones propietarias particulares para ciertas plataformas, hasta soluciones basadas en estándares independientes de la plataforma subyacente. La elección de la herramienta adecuada dependerá del contexto particular de la solución a implementar. En las siguientes subsecciones se presentan varias de estas opciones, pasando por una enumeración de algunos sistemas de mensajería comerciales y estándares al respecto; mostrándose luego frameworks que permiten la implementación de los patrones de mensajería de [59]; y por ultimo llegando a herramientas para la aplicación de mensajería en ambientes orientados a servicios, como por ejemplo ESBs y Web Services con sus especificaciones relacionadas Sistemas de Mensajería Comerciales MQ Series Uno de los líderes históricos en el mercado de los sistemas de mensajería empresarial es IBM MQ Series [17]. Su versión 5.1 está disponible en el mercado [60] desde el año Este inicialmente soportaba un modelo de mensajería point-to-point y en su versión 5 introdujo el modelo publish-subscribe. Se encuentra disponible para varias plataformas como ser, AIX, OS/2, AS/400, etc. Entre sus grandes prestaciones 24

25 CAPÍTULO 2. ESTADO DEL ARTE se destaca el soporte para balanceo de carga y tolerancia a fallas en ambientes multiplataforma. Este producto evolucionó como WebSphere MQ como se verá a continuación Microsoft Message Queuing Microsoft Message Queuing [28] (MSMQ de aquí en mas) es un componente del sistema operativo Microsoft Windows, que permite que aplicaciones distribuidas envíen y reciban mensajes utilizando un servicio que provee interfaces y colas para dichos fines, el cual además es accesible remotamente a través de la red. Dado que los mensajes son enviados y recibidos a través de este servicio, las aplicaciones que lo utilizan no tienen porqué residir en la misma máquina, así como tampoco estar conectadas a la red al mismo tiempo para que los mensajes puedan ser enviados o recibidos. El servicio de mensajería almacena los mensajes que son recibidos por la cola que utiliza el cliente y reenvía los mismos a la cola destino que utiliza la aplicación destinataria. De esta manera se desacopla a las aplicaciones participantes de la comunicación y se provee confiabilidad en la entrega de los mensajes transmitidos a través del servicio, así como también permite abstraerse del ruteo especifico de los mensajes que se envían. Se asegura además la transaccionalidad de los consumos de dichos mensajes y se pueden procesar por parte del cliente de una manera priorizada según las propiedades de dichos mensajes. MSMQ puede ser utilizado en una única instancia, en donde se publican en una maquina servidor todas las colas de mensajes que son utilizadas por todas las aplicaciones productoras y consumidoras (las cuales son llamados clientes dependientes); también se puede utilizar una arquitectura distribuida para el servicio MSMQ en donde cada uno de los servicios residentes en una máquina de la red auspicia de manejador de colas o queue mannager para sus clientes (las cuales son llamados clientes independientes) y se encarga de conocer otros servicios MSMQ y las colas que estos publican en las demás máquinas que conforman la red con el fin de redirigir los mensajes según su destino final. Esta distribución permite la escalabilidad de todo el sistema de mensajería, permitiendo realizar el procesamiento de los mensajes distribuyendo la carga de procesamiento en varios servidores a través de la red. Por otra parte Microsoft en diciembre de 2006 introdujo un framework que permite facilitar la comunicación entre aplicaciones, llamado Windows Comunication Foundation [50]. WCF unifica los diferentes modelos de programación soportados en el.net framework 2.0 en un único modelo, este modelo está basado en la declaración de contratos que definen el comportamiento deseado para la comunicación, abstrayendo no solo el protocolo utilizado, sino también la implementación de las diferentes características definidas para la comunicación. Dentro de las diferentes caracteristicas, mecanismos y protocolos de comunicación soportados por WCF se encuentran: comunicaciones asincrónicas (basadas en colas de mensajes sobre MSMQ), transacciones distribuidas, comunicaciones basadas en el protocolo SOAP [75], comunicaciones por protocolos propietarios como es.net Remoting [30], entre otras. El mecanismo por el cual se realiza la comunicación está determinado por el binding de la misma, el cual encapsula los detalles del intercambio de mensajes. Los contratos definidos entre las aplicaciones permiten configurar algunos aspectos de la configuración del transporte o protocolo de la comunicación que representan los denominados bindings. En WCF la comunicación asincrónica basada en colas de mensajes son un tipo más de transporte posible y la implementación utilizada para el transporte es MSMQ. La figura 2.7 muestra la estructura de la comunicación entre dos aplicaciones que utilizan MSMQ como transporte. 25

26 CAPÍTULO 2. ESTADO DEL ARTE Figura 2.7: MSMQ como transporte en WCF La aplicación cliente y la proveedora solo deben definir el contrato de la comunicación y la implementación de los clientes WCF correspondientes (tanto para la aplicación cliente como para la proveedora), los cuales son generados automáticamente mediantes herramientas que también generan los archivos de configuración necesarios. Para enviar un mensaje por este canal de comunicación, la aplicación cliente instancia el cliente WCF e invoca el método correspondiente. Esto causa que el mensaje sea transmitido a una cola de mensajes que finalmente la aplicación proveedora obtiene de manera transparente con el cliente generado previamente, encapsulando así las dificultades o complejidades de la comunicación mediante este tipo de transporte TIBCO Rendezvous TIBCO Rendezvous [46] es el sistema de mensajería que sirve como base para TIBCO ActiveEnterprise, se trata de la solución de integración de aplicaciones de TIBCO. Es uno de los sistemas de mensajería más utilizado en el contexto de integración de aplicaciones empresariales. Funciona sobre una gran gama de plataformas, tiene interfaces de programación para varios lenguajes (Java, C, C++, Perl, COM y.net), tiene soluciones para garantizar alta disponibilidad y además una administración sencilla. TIBCO Rendezvous TX es la extensión que agrega soporte transaccional, permitiendo componer accesos a bases de datos y envíos de mensajes en una sola transacción. Se puede decir que TIBCO Rendezvous es un servicio de notificación que no utiliza un servidor centralizado, cada maquina cliente posee su propio rendezvous deamon que corre como un proceso en segundo plano, dicho deamon interactúa con la aplicación cliente y provee las interfaces para comunicarse con otros clientes Rendezvous distribuidos en la red. Esto provoca que cada uno de estos deamons tenga que encargarse del manejo de la persistencia de cada mensaje enviado así como también del buffer de mensajes que tiene cada aplicación encolados para recibir. Otro aspecto que implementa el deamon es el del protocolo que se utiliza en la comunicación el cual esta basado en PGM [88]. Este servicio distribuido de mensajería soporta interacciones del tipo Point to Point, así como también del tipo Publish-Subscribe Implementaciones de JMS Java Message Service (JMS) [23] es una API perteneciente a la plataforma Java, a partir de la cual aplicaciones escritas en esta plataforma pueden comunicarse con un MOM. Al tratarse de una API independiente del proveedor que la implementa, las aplicaciones serán portables, por lo que, si se cambia de proveedor de mensajería (MOM), la comunicación desde una aplicación Java con este no deberá modificarse. Básicamente lo que brinda esta API son mecanismos para: crear, enviar, recibir y leer mensajes. A su vez, hace posible lograr una comunicación confiable tanto síncrona como asíncrona. JMS soporta dos modelos de mensajería, point-to-point y publish-subscribe. En la actualidad existen diversidad de MOMs que implementan la especificación JMS. A continuación se listan algunos de ellos. ActiveMQ 26

27 CAPÍTULO 2. ESTADO DEL ARTE Apache ActiveMQ [2] es un proveedor de mensajería open source que implementa completamente la especificación JMS 1.1. Entre las características que este proporciona, se destaca su posibilidad de configuración en cluster con alta disponibilidad. Provee interfaces de programación para ser utilizado desde la plataforma.net, C/C++, Delphi, Ruby, Perl y PHP, además de Java como interfaz nativa. Este producto es reutilizado en las implementaciones de Apache ServiceMix [8] y Apache Camel [3], como motor de mensajería. JBossMessaging JBoss Messaging [25] es un proveedor de mensajería open source de JBoss, que implementa completamente la especificación JMS 1.1. Entre sus características principales se destacan su integración con JBoss Transaction, soportando transacciones distribuidas, y la posibilidad de recuperación completa de estas ante fallas. A su vez, permite configuración en cluster, balanceo inteligente, y paginado automático de mensajes en almacenamiento secundario. Esto último es interesante dado que permite manejar colas de mensajes con grandes volúmenes de datos. Al igual que Active MQ, provee clientes para plataformas.net, C/C++, Delphi, Ruby, Perl y PHP. WebsphereMQ WebSphere MQ [18] es el proveedor de mensajería de IBM. Se trata del sucesor de MQ Series. Este se integra a la familia de productos WebSphere [19] a partir de marzo de Es uno de los productos lideres en el mercado. Dentro de sus prestaciones se destaca que está disponible para un gran número de plataformas, entre estas, z/os, Unix (AIX, HP OpenVMS, HP-UX, Solaris), HP NonStop, Linux, y Microsoft Windows. Hereda todas las características de MQ Series, y se potencia logrando integrarse fácilmente con otros productos de la familia WebSphere [81] Advanced Message Queue Protocol Advanced Message Queue Protocol (AMQP) es un estándar abierto creado por las empresas JPMorgan Chase & Co [27] e imatix Corporation [20] que define un protocolo a partir del cual se puede lograr interoperabilidad entre MOMs. El estándar propone un protocolo a seguir codificado en binario que lo hace más liviano en cómputos y ancho de banda que los protocolos propietarios de los MOMs. El estándar actualmente se encuentra en su versión 0.8, y se espera que en poco tiempo se libere la versión 1.0. De todas formas, existen hoy en día varias implementaciones, aunque varias en etapa de experimentación. Algunas implementaciones son OpenAMQ (la de referencia) [38], Apache Qpid [7], y RabbitMQ [40], todas ellas proyectos de código abierto Frameworks En la actualidad existen varios frameworks que brindan construcciones de base para implementar los patrones de mensajería descritos en la subsección A continuación se describen dos de estos frameworks: Apache Camel y Spring Integration Framework Spring Integration Spring Integration Framework[44] provee una extensión al estilo de programación Spring (basado en inyección de dependencias) para soportar la implementación de los patrones de mensajería de [59]. Esto permite a las aplicaciones basadas en Spring integrarse con aplicaciones externas vía adaptadores. Estos adaptadores proveen un alto nivel de abstracción a las aplicaciones encapsulando diversidad de protocolos de comunicación, y simplifican la comunicación de las mismas mediante mensajería Apache Camel Apache Camel [3] es un framework Java que implementa la gran mayoría de los patrones de mensajería de [59] de ruteo y transformación. Es en sí un motor de reglas el cual puede ejecutar en cualquier 27

28 CAPÍTULO 2. ESTADO DEL ARTE ambiente Java, sin necesitar de un servidor de aplicaciones. Entre sus mayores potenciales se encuentra la gran variedad de protocolos de comunicación que soporta, por citar algunos: HTTP, FTP, SMTP, LDAP, etc. Otra característica destacable es que las reglas de ruteo pueden expresarse utilizando un Domain Specific Language (DSL) propuesto por la herramienta, que permite expresar las reglas en alto nivel, al estilo from-to. Además tiene soporte para la especificación de las reglas mediante archivos XML Enterprise Service Bus Un ESB es una plataforma de integración de aplicaciones basada en estándares, que combina entre otras cosas: mensajería, servicios, ruteo y transformación de mensajes, con el objetivo de coordinar y conectar de manera confiable un número significativo de aplicaciones. Está construido sobre un canal común de mensajes (bus) altamente distribuible, multiprotocolo, basado en estándares y provee la columna vertebral para implementar una Arquitectura Orientada a Servicios (SOA). En la figura 2.8 se ilustra la infraestructura de este tipo de plataformas. Figura 2.8: Capacidades de integración multiprotocolo de un ESB Este tipo de plataforma puede traer ventajas significativas en contextos en los que existan necesidades de integrar aplicaciones. Por ejemplo cuando en una organización se tiene una necesidad de negocio concreta de integrar aplicaciones, se podría optar por implantar un ESB. Las ventajas de su uso se ven con mayor claridad en contextos en que dicha integración se realice en un ambiente heterogéneo de aplicaciones que trabajan en múltiples plataformas. Por ejemplo, en organizaciones que presentan ambientes heterogéneos, con muchas aplicaciones ejecutando en plataformas diferentes, al tener una necesidad de integración, los ESBs resuelven gran parte del proceso permitiendo tener un buen control del mismo. En la actualidad hay muchas definiciones del término ESB usadas por proveedores, analistas de mercado, y usuarios finales. No existe una definición formal del término, pero se puede apreciar que en general se coincide con un núcleo de funcionalidades básicas que un ESB debe proveer. Estas son enumeradas a continuación, según lo relevado de [52] y [72]. Transparencia de localización. Los ESBs desacoplan a los servicios proveedores de los consumidores. Estos proveen una plataforma central para comunicar aplicaciones haciendo transparente al consumidor la localización del receptor. Conversión de protocolos de transporte. Un ESB es capaz de integrar aplicaciones por más que estas se comuniquen bajo diferentes protocolos de transporte (HTTP, SMTP, FTP, etc). 28