Mensajería en Sistemas de Información

Mensajería en Sistemas de Información
Integrantes: Marcelo Caponi Pablo Rodríguez Defino Pablo Zamudio Tutores: Ing. MSc. Leonardo Rodríguez Ing. Diego Rivero

Objetivos - Entender soluciones basadas en mensajería
Mensajería para integración Estudiar EIP para integrar servicios Empezaremos viendo los objetivos que nos planteamos: 1) Entender soluciones basadas en mensajería Que es mensajeria Aporte de la mensajería a los Sistemas de Información Consideraciones a tener en cuenta Contextos de aplicación de mensajería Estado del arte 2) Estudiar técnicas y artefactos de diseño para atacar un problema de mensajería Aspectos interesantes a mostrar en el diseño Herramientas para la especificación de soluciones de mensajeria Problemas comunes => Patrones de Diseño de Mensajeria (EIP) 3) Estudiar Patrones de Mensajería en contexto SOA SOA tiene puntos de contacto con mensajería Futuro EIP según la bibliografía apunta a SOA Estándares de WS implementan patrones de EIP Frameworks e implementaciones de ESBs adoptan e implementan algunos patrones EIP => Estudiar Patrones de Mensajería en contexto SOA WS y ESB para integración WS-* → EIPs Frameworks y ESBs → EIPs

Agenda - Introducción a Mensajería en Sistemas de Información
- Estado del arte - Herramientas Clasificación de Patrones según implementación Ejemplos - Caso de Estudio: Loan Broker En funcion de los objetivos que definimos en la diapositiva anterior, estos son los puntos que vamos a tener dentro de la agenda de esta presentacion: Para entender que implican las soluciones basadas en mensajeria, vamos a ver: Introduccion a Mensajeria en Sistemas de Informacion Estado del Arte Para encarar el estudio de tecnicas y artefactos de disenio para especificacion de estas soluciones, vamos a ver los siguientes puntos: Aspectos a especificar en este tipo de soluciones Herramientas para disenio disponibles Guia para el disenio de estas soluciones Por ultimo, para ver la implementacion de EIP en SOA, veremos: Herramientas disponibles Clasificacion de EIP segun su implementacion Ejemplos - Conclusiones - Trabajo a Futuro

- Introducción a Mensajería en Sistemas de Información
- Estado del arte - Herramientas Clasificación de Patrones según implementación Ejemplos - Caso de Estudio: Loan Broker - Conclusiones - Trabajo a Futuro

¿Que es mensajería? Aplicación 1 Aplicación 2 Canal
Comunicacion entre aplicaciones mediante el envio de paquetes de datos, llamados mensajes. Para el envio de informacion se dispone de canales, que funcionan como colecciones de mensajes, compartidas entre todas las aplicaciones, donde se dejan y desde donde se toman los mensajes. Tenemos dos aplicacioens que se quieren comunicar mediante mensajeria. Para esto se define un canal mediante el cual se comunicaran las aplicaciones. La comunicacion consiste en que la aplicacion que quiere enviar la informacion, la empaquete en un mensaje, luego envie este mensaje al canal, y luego la aplicacion que desea consumir el mensaje lo toma del canal, desempaqueta el mensaje tomando la informacion y la procesa. Vimos que es mensajeria, ahora pasaremos a ver que aportes tiene su uso en Sistemas de Informacion.

Aspectos de interés Características Consideraciones Bajo Acoplamiento
Comunicación Asíncrona Comunicación Confiable Operación sin conexión Consideraciones Modelo de Programación complejo Problemas de secuenciamiento Bajo acoplamiento (en varios niveles) Estatico – las aplicaciones que se comunican mediante mensajeria, no tienen dependencias entre ellas, ya que como la comunicacion se da a traves del canal, la unica dependencia que las aplicaciones tienen es con este, no conociendo a las aplicaciones que consumen (o producen) los mensajes que estas producen (o consumen). De esta forma las aplicaciones que se estan comunicando mediante mensajeria no estan acopladas. Dinamico – las aplicaciones que se comunican mediante mensajeria, no tienen porque estar al mismo tiempo disponibles para la recepcion y envio de los mensajes que deseen intercambiar. La idea es que al enviar un mensaje mediante un canal, la aplicacion que consume este mensaje puede no estar disponible para la recepcion del mismo, pero a pesar de esto el envio se puede realizar sin problemas. Luego cuando la aplicacion que desea consumir el mensaje tenga disponibilidad para hacerlo, puede procesar el mensaje sin depender de que quien envio el mensaje este disponible. Comunicacion Asincrona Por lo que explicamos anteriormente, al poder enviar un mensaje a un canal y que el consumidor lo pueda procesar en el momento que quiera o pueda, podemos decir que en ese sentido la comunicacion que se esta realizando de hecho es asincrona. Comunicacion Confiable Al enviar un mensaje por un canal, quien envia el canal tiene las garantias de que ese mensaje sera entregado a el/los destinatarios que corresponda. Operacion sin conexion Al enviar un mensaje por un ccanal, quien envia y quienes reciben los mensajes no tienen porque establecer una conexion para que la comunicacion se produzca. Al margen de estos aportes, el uso de mensajeria trae aparejados ciertos desafios, que vienen de la mano por ejemplo del modelo de programacion que se debe utilizar en este tipo de soluciones. En un contexto de mensajeria la comunicacion entre los distintos actores no se maneja de forma sincrona, se deben tener en cuenta ciertos aspectos no tan comunes, como por ejemplo: los participantes de la comunicacion no comparten el contexto de ejecucion se pierde la secuencialidad de los programas, al no ser visible el hilo conductor de las aplicaciones en el codigo desarrollado, sino mas bien en la secuencia en que los mensajes se vayan procesando.

Componentes de una solución de mensajería
Channels: Direcciones lógicas en el sistema de mensajería. Messages: Entidades que transportará el sistema de mensajería. Message Endpoint: Permite conectar una aplicación al sistema de mensajería. Un sistema de mensajeria tiene 3 componentes principales: Canales Mensajes Endpoints Los canales son direcciones logicas en el sistema de mensajeria donde se depositan los mensajes y desde el que se toman los mismos para posibilitar la comunicación. Los mensajes son las entidades que se transporan en el sistema de mensajeria. Los endpoints son los que permiten conectar a las aplicaciones que desean usar el sistema de mensajeria. Funcionan como punto de interconexion entre las aplicaciones y el sistema de mensajeria, enviando y recibiendo mensajes del sistema de mensajeria y permitiendo a las aplicaciones que los procesen. Estos componentes de una solucion de mensajeria con el tiempo fueron generalizados en una pieza de software mas general abocada escencialmente a permitir la comunicación entre aplicaciones mediante mensajeria. A este tipo de software se le llama Message Oriented Middleware.

Message Oriented Middleware
Permite la comunicación entre aplicaciones mediante el intercambio de mensajes. Características: Confiable Asíncrona Con garantía de entrega Con notificación de entrega Con manejo transaccional Como ya algo hablamos, un MOM es una pieza de software abocada a facilitar la comunicacion entre apliaciones mediante el intercambio de mensajes. Las caracteristicas que brinda son: Comunicacion confiable Al estar trabajando con un MOM, quien envia los mensajes tiene garantido que los mensajes no se van a perder. Comunicacion asincrona Al enviar un mensaje mediante un MOM, el emisor del mensaje luego de enviado el mismo, puede seguir realizando otras tareas, sin importar si el mensaje fue procesado o no. A raiz de esto, el receptor del mensaje puede no estar disponible, o no tener capacidad de procesamiento en el momento del envio del mensaje, pudiendo posponer la recepcion de ese mensaje a cuando tenga capacidades para hacerlo. Con garantia de entrega Esta caracteristica asegura que ademas de que los mensajes no se pierdan (confiable), si ocurre algun suceso por el cual el MOM este indisponible durante algun tiempo, al volver a estar disponible, los mensajes que no hayan sido procesados antes de su caida seguiran estando disponibles para poder ser consumidos. Con notificacion de entrega Aun utilizando asincronismo en la comunicacion entre aplicaciones, en algunos casos puede ser de interes para quien envia los mensajes saber cuando efectivamente fueron procesados los mismos. Esto es lo que esta caracteristica brinda. Con manejo transaccional En contextos en los que la comunicacion mediante el uso de un MOM forma parte de un conjunto de operaciones que incluyen por ejemplo operaciones contra una base de datos, puede ser de interes que todas las operaciones contra el MOM sean attacheadas a una transaccion global, de forma de que las operaciones sobre el MOM tengan efecto solo si el resto de las operaciones realizadas en la transaccion fue exitoso. Hasta aca, tenemos una vision global de que es mensajeria, para que se puede usar, que ventajas puede traer su uso, y que componentes especificos existen para el desarrollo de estas soluciones, con lo que concluimos con el primer objetivo que teniamos, que era entender que era una solucion basada en mensajeria. Ahora pasaremos al segundo objetivo, que implica el estudio de tecnicas y artefactos para la especificacion de este tipo de soluciones.

Contextos de aplicación
Integración de aplicaciones Diseminación de información Sistemas de monitoreo distribuido Sistemas móviles Integración de aplicaciones Integrar aplicaciones independientes, en ≠ plataformas y tecnologías. Diseminación de la Información Sistemas de notificación de servicios, sistemas de tiempo real, en los que el ppal requisito es la diseminación a tiempo de información a los interesados. Sistemas de Monitoreo Distribuido Procesamiento en tiempo real de eventos distribuidos, para la generación de información agregada. Por ejemplo sistemas para el monitoreo de redes. Sistemas Móviles Sistemas cuyos nodos son dispositivos móviles, con topologías dinámicas y ≠ posibilidades de conexión. Vimos los contextos de mensajeria, ahora vamos a ver los principales componentes de un sistema de mensajeria

Herramientas de Diseño
Patrones de Diseño de Mensajería (EIP) Diagramas de propósito general UML y otros Ningún diagrama especifica completamente una solución de mensajería Cada uno aporta una perspectiva o vista de la solución Son complementarios

Patrones de Diseño de Mensajería
Channel Patterns Point-to-Point Channel Message Patterns Correlation Identifier Routing Patterns Message Router Transformation Patterns Content Filter Endpoint Patterns Message Selector Management Patterns Wire Tap Sanata pareja de como surgen Transformation Patterns: Relacionados a las transformaciones de los mensajes a los formatos requeridos por cada aplicación. Ejemplos: “Data Enricher”, “Content Filter”. Endpoint Patterns: Relacionados a la forma en que los actores envían y consumen mensajes. Ejemplos: “Polling Consumer”, “Event-Driven Consumer” Management Patterns: Sirven para la administración y testeo de un sistema. Ejemplos: “Wire Tap”, “Test Message”.

Diagramas de propósito general
UML (Diagramas de estados, Diagramas de Actividad, Diagramas de secuencia, etc) Diagramas de Contexto Signal Wiring Diagrams Block Diagrams Workflow diagrams SDL Hacer referencia de donde vienen. Ir poniendo dibujitos en el bloque Poner primero los patrones. Herramientas y luego pongo los diagramas, y luego los que elegimos

Herramientas de Implementación
Sistemas de Mensajería Comerciales MQ Series, MSMQ, TIBCO Rendezvous Implementaciones de JMS Frameworks Apache Camel, Spring Integration Enterprise Service Bus Apache ServiceMix, Mule ESB Web Services y estándares WS-* Ningún diagrama especifica completamente una solución de mensajería Cada uno aporta una perspectiva o vista de la solución Son complementarios

Motivación – EIP para integración de Servicios
Mensajería → Bajo acoplamiento Madurez reflejada en EIP WS → Estándar sobre plataformas heterogéneas Madurez reflejada en estándares WS-* WS-* ∩ EIP ESB adoptan EIP Porqué hay puntos de contacto entre SOA y Mensajería ?. Recordemos que uno de los propositos de una Arquitectura Orientada a Servicios, es poder componer servicios simples para obtener servicios mas complejos. Esa composición se puede lograr de varias formas, una de ellas es a través de Mensajería. Esta forma a su vez, nos proporciona ventajas, como por ejmplo, el bajo acoplamiento entre componentes. Por lo tanto, la Mensajería es relevante estudiarla en un contexto SOA. La bibliografia principal de nuestro trabajo, el libro de EIP, cuando menciona sus trabajos futuros, hace refrencia a la relevancia de estudiar a los patrones en un contexto SOA. Hacen referencia a que el futuro viene por el lado de SOA. Tambien la bibliografia menciona lo interesante de las especificaciones WS-*, dado que estas implementan varios patrones. Surgen ESBs y Frameworks que implementan patrones, por lo cual podemos contar con piezas de sw que implementen los patrones de mensajeria, algo que no es menor. Uno de ellos es Apache Camel, que lo estudiaremos mas adelante.

Herramientas – Web Services
Estándares WS-* WS-Addressing WS-ReliableMessaging WS-Notification WS-BaseNotification, WS-Topics, WS-BrokeredNotification WS-Enumeration Que herramientas tenemos para implementar EIP en SOA, además de otras cosas, los estandares WS-*. WS-Notificaction: Permite que un Web Service pueda recibir notificaciones. Esta compuesto por 3 estandares, WS-BaseNotification, WS-BrokeredNotification y WS-Topics. WS-BaseNotification: Es la forma más básica de notificación, del estilo productor consumidor. El consumidor se registra para ser notificado cuando se genere cierta información que le es de interés, y es notificado por el productor. WS-BrokeredNotification: Parecida a BaseNotification, con la diferencia de que desacopla a los productores de los consumidores, a traves de de un broker. Este es quien maneja las sucripciones, y es quien hace los notify. WS-Topics: Permite el uso de topicos, como una forma de categorizar las notificaciones. Entonces, WS-Topics, puede ser usado tanto por BaseNotification como por BrokeredNotification dado que cuando un Web Service se quiere suscribir para recibir información, puede hacerlo a un cierto tópico. WS-Addressing: Permite en un mensaje SOAP, incluir información del emisor, los destinatarios, a quien se debe responder, a quien se debe de informar en caso de error. WS-ReliableMessaging: Define un protocolo punto a punto que permite el intercambio de mensajes con garantía de entrega, independientemente de fallas en la red, o en los actores que participan del intercambio. WS-Coordiantion, WS-AtomicTransaction y WS-BussinesActivity forman parte de una más general WS-Transaction. WS-AtomicTransaction: Da soporte para realizar transacciones de corta duración entre WebServices, existe un coordinador de esa transacción, el cual puede decidir hacer en un rollback, y llevar a los WebServices involucrados a su estado previo. WS-BussinesActivity: Sirve para coordinar actividades o procesos que no puden ser modelados como una transacción atómica, ya sea por su duración, o por requerir intervención humana. No se, imaginemos un proceso largo que sigue un expediente. WS-Coordiantion: Es una especificacion que define como tienen que interactuar un conjunto de web services para terminar una cierta tarea. Por ejemplo, quizas para terminar una tarea, tengamos que llegar a el final de un proceso de negocio, y a su vez culminar tambien una cierta transaccion, por lo tanto en ese caso se deberían de coordinar dos cosas de naturaleza diferente. En ese caso WS-Coordination, hace uso de AtomicTransaction y de BussinesActivity, y coordniaría a ambas. Nos provee un modelo donde podemos definir un solo coordinador, o coordinadores distribuidos. WS-Enumeration: Nos ayuda a intercambiar grandes volumenes de informacion. Dado que pueden existir casos donde un volumen muy grande de informacion no se va a poder pasar en un simple mensaje soap. Por lo tanto, con esta especificacion se podran enumerar los paquetes. Un cosa muy buena es que el consumidor puede manejar algo parecido a lo que es un cursor en una base de datos, y pedir, dame el siguiente o dame 10 mas, etc. WS-Policy: Es una especificación a partir de la cual, los WebServices pueden definir las caracetrisitcas que presentan y que exigen de los demás para operar. Por ejemplo, un web service puede exigir para operar, que los mensajes le lleguen firmados. Con esto se dota a los web services de la capacidad de negociar las condiciones de su interaccion. WS-ResourceFramework: Mediante esta especificación, se pueden utilizar servicios con estado interno. Hay varias subcategorías aquí tambien, como, WS-Resource, WS-ResourceProperties, WS-ResourceLifeTime. Nos está quedando WS-Security, que puede ser aplicada en caso necesario, pero la seguridad no es el foco de nuestro estudio en sí.

Herramientas – ESB Funcionalidades básicas
Conversión de protocolos de transporte Transparencia de localización Transformación de mensajes Ruteo de mensajes Soporte a ejecución de procesos de negocio Monitoreo y administración Apache Camel como ahi dice, es un motor de reglas de ruteo y transfomacion de mensajes. En el sitio, se hace referencia a la bibliografia de EIP, de la misma forma que en el libro, usando el lenguaje visual para cada patron, y se muestra como se implementan varios de ellos. En principio, Apache Camel, implementa la mayoria de los patrones de ruteo y transformacion. Apache Camel es un motor muy potente, dado que soporta un gran variedad de protocolos de transporte como, por ejemplo, http, jms, ftp, rmi, etc. Se pueden especificar reglas que hagan cosas como por ejemplo, que se genere un evento al crear un archivo en un file sistem, y eso haga que se coloque un mensaje en una cola. Es muy facil plugear nuevos componentes, el componente de JMS, es generico, y facilmente se le puede configurar para cualquier proveedor de JMS. Otra de las grandes ventajas de Apache Camel es la simplicidad para expresar las reglas de ruteo y transformacion. Java DSL es un lenguaje muy expresivo y facil de usar, reglas se especifican mediante clausulas from(endpoint).to(), y se le pueden asociar reglas en cadena. Ademas de eso, existe ya un plugin de eclipse donde se pueden especificar graficamente las reglas y y generar Java DSL. - El modelo de camel soporta los archivos de configuracion de Spring, por lo tanto las reglas se pueden especificar muy facilmente en archivos de configuracion similares a los de Spring.

Clasificación de Patrones según implementación
Implementables con Web Services Implementables con estándares WS-* Implementables con ESB Composición de patrones simples Implementación particular Bueno, viendo un poco que hay patrones de mensajeria que su implementacion se corresponde con estandares de WS-* y algunos que pueden ser implementados por otros mecanismos, por ejemplo con el framework camel, es que decidimos clasificar a los patrones segun su implementacion. Dado lo anterior, definimos dos grandes categorias, Patrones implementables directamente con las especificaciones WS-* y patrones que no pueden ser implementados con WS-*. Es interesante subdividir en esas dos categorias dado que de cierto modo, estamos viendo que patrones se han convertido en estandares y cuales no. Dentro de los que no salen directamente por las especificaciones WS-*, podemos agruparlos en familias de patrones, teniendo en cuenta que se implementaran de forma semejante. Estas categorias son: Canal – Son patrones donde en su implementacion tienen como principal protagonista al canal de comunicacion. Ruteo – Basados en el ruteo de mensajes Manipulacion de mensajes – Son patrones que manipulan mensajes, esto es, separando el contendido de los mismos, o agregandoles contenido, antes de tomar cualquier accion con ellos. Transformacion de mensajes – Se basan en las transformaciones que le haran a los mensajes que reciben para que luego estos puedan ser redirigidos System Management – Son patrones que intentan informarnos del estado del sistema, por ejemplo cuantos mensajes van por cada canal, que destinos estan vivos, cuales no, etc. Con este tipo de patrones podremos sacar estadisticas, y tomar acciones correctivas lo antes posible, en caso de detectar fallas en el sistema.

Ejemplo de Implementación con WS-*
Publish-Subscribe Channel Problema ¿Cómo notificar a un conjunto de destinatarios ante la ocurrencia de un evento?. Solución Usar un canal Publish-Subscribe al que los destinatarios se subscriben. Para fijar un poco los conceptos antes mencionados, vamos a mostrar un par de ejemplos. Un patron que sale directamente a partir de WS-*, y otro que no. El problema que ataca el patron, es el que dice ahi, evitar que un componente reciba mensajes que no le son de interes. La idea es, una aplicacion se quiere suscribir para que le lleguen mensajes que otra genera, pero no le interesa recibir todos los mensajes, sino los que cumplen cierta condicion. La solucion es poner un componente que reciba todos los mensajes y se encargue de redirijir al destino los que le son de interes. Bueno, vimos el problema y su solucion, ahora veamos como se implementa con los estandares de WS-*.

Ejemplo de Implementación con WS-*
Utilización de: WS-Notification (WS-BrokeredNotification y WS-Topics) Servicios destinatarios se subscriben a un tópico y son notificados ante eventos. Se utiliza al ESB como implementación de WS-BrokeredNotification y WS-Topics. El broker en este caso es el ESB el cual implementa la especificación

Ejemplo de Implementación compuesta
Smart Proxy Problema ¿Cómo lograr interceptar las invocaciones y respuestas a un servicio que responde siempre a la dirección de indicada por el invocador?. Solución Usar un Smart Proxy que intercepte las invocaciones y respuestas del servicio. Bueno, ahora vamos a ver un ejemplo de implementacion de patron que no se puede resolver directamente con las especificaciones WS-*. Veamos el Dead Letter Channel, como dice ahí, el patrón resuelve el problema de que hacer con los mensajes que no pueden ser entregados. La solución es, especificar un canal donde se redirijan los mensajes que no pueden ser entregados. Veamos la implementacion de este patron.

Ejemplo de Implementación compuesta
Composición de tres patrones Correlation Identifier WS-Addressing Message Router Capacidades de ruteo del ESB Return Address Este patron se compone de dos partes, la primera es, saber que condiciones se tienen que cumplir para redirigir al dead letter channel. Y la segunda, como y a donde redirigir. El patron es implementado por Apache Camel, algunos ejemplos de condiciones que podemos especificar para redirigir a un dead letter channel son por ejemplo, cantidad de reintentos. Por ejemplo, si el destino esta caido, y se reintenta un numero x de veces, y el destino sigue caido, tomamos la decisión de reenviar al dead letter channel. Dentro de las reglas de ruteo, podemos especificar que el dead letter channel sea un web serivce, una cola de mensaje, una gran variedad de componentes que nos provee Apache Camel.

Resultados obtenidos Este patron se compone de dos partes, la primera es, saber que condiciones se tienen que cumplir para redirigir al dead letter channel. Y la segunda, como y a donde redirigir. El patron es implementado por Apache Camel, algunos ejemplos de condiciones que podemos especificar para redirigir a un dead letter channel son por ejemplo, cantidad de reintentos. Por ejemplo, si el destino esta caido, y se reintenta un numero x de veces, y el destino sigue caido, tomamos la decisión de reenviar al dead letter channel. Dentro de las reglas de ruteo, podemos especificar que el dead letter channel sea un web serivce, una cola de mensaje, una gran variedad de componentes que nos provee Apache Camel.

Problema Agencia de Crédito Banco 1 Banco N . $$$ ¿Banco 1 … Banco N?

Solución: Loan Broker Agencia de Crédito Banco 1 Cliente Banco N
Servidor de Correo Servidor de Facturación

Análisis y Diseño Análisis Diseño Modelado del dominio del problema
Contexto de la aplicación Proceso de negocio Diseño Estructura de la aplicación Aspectos de Mensajería Interacción entre componentes Al final, de los puntos atacados en el analisis y diseño vamos a ver el que es particular de soluciones de mensjajeria que es el diagrama de patrones de mensajeria. Los otros podrian usarse para cualquier problema de integracion que no se resuelva con mensajería.

Diseño

Herramientas Apache ServiceMix Apache CXF
Componentes para implementar EIP Basado en estándar JBI Apache CXF Stack de WS que implementa varias WS-*

Implementación

Resultados Análisis y diseño de una solución basada en mensajería
Implementación de todos los EIPs sobre las herramientas seleccionadas Simple para casos que plataforma brinda soporte Complejo para mapear conceptos de mensajería a conceptos de JBI 1 – Se probaron las notaciones relevadas y se concluyo que aportan a la especificación de aspectos particulares de este tipo de soluciones (ejemplo EIP) 2 – Basados en las propuestas de soluciones propuestas para varios patrones, se realizaron las implementaciones en el contexto del caso de estudio. Algunas impls son directas (gracias a facilidades de la plataforma) y para otras fue mas complejo lograr su implementación.

Conclusiones Se entendieron conceptos de mensajería y aspectos relevantes en este tipo de soluciones. Se logran propuestas de implementación para EIPs usando ESB, Web Services y estándares WS-*. Se validan algunas de estas propuestas mediante la implementación de un caso práctico. EIPs vigentes en contextos de integración de servicios. Como vimos, necesitamos otros tipos de diagramas para relevar aspectos relevantes a una solucion basada en mensajeria, que no se pueden especificar con UML. Por eso surge vista de EIP, ademas hay aspectos como la interaccion entre los componentes con mensajeria de por medio que no se puden modelar con el nivel adecuado de abstraccion usando solamente UML. Por eso surge la idea de utilizar Block Diagrams de SysML. No encontramos metodologias para atacar este tipo de soluciones, y un poco la idea fue dejar algo asi como guias de diseño, o buenas practicas, para que sean de utilidad a la hora de encarar una solucion con mensajeria. Pudimos ver que la implementacion de los EIP en SOA es factible. Si bien los estandares WS-* implementan una parte de los EIP, no los cubren en su totalidad, pero se puede apreciar una tendencia a logralo.

Trabajo a Futuro Analizar alternativas para lograr garantía de entrega en el contexto de Web Services. Profundizar el estudio del manejo transaccional en la integración de servicios. Analizar factibilidad de componer propuestas de implementaciones de EIPs. Seguir avance de especificación AMQP (Advanced Message Queue Protocol). Como vimos, necesitamos otros tipos de diagramas para relevar aspectos relevantes a una solucion basada en mensajeria, que no se pueden especificar con UML. Por eso surge vista de EIP, ademas hay aspectos como la interaccion entre los componentes con mensajeria de por medio que no se puden modelar con el nivel adecuado de abstraccion usando solamente UML. Por eso surge la idea de utilizar Block Diagrams de SysML. No encontramos metodologias para atacar este tipo de soluciones, y un poco la idea fue dejar algo asi como guias de diseño, o buenas practicas, para que sean de utilidad a la hora de encarar una solucion con mensajeria. Pudimos ver que la implementacion de los EIP en SOA es factible. Si bien los estandares WS-* implementan una parte de los EIP, no los cubren en su totalidad, pero se puede apreciar una tendencia a logralo.

Preguntas

Mensajería en Sistemas de Información

Presentaciones similares

Presentación del tema: "Mensajería en Sistemas de Información"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Mensajería en Sistemas de Información

Presentaciones similares

Presentación del tema: "Mensajería en Sistemas de Información"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback