MENSAJERÍA EN SISTEMAS DE INFORMACIÓN

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE APLICACIONES EMPRESARIALES

DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE APLICACIONES EMPRESARIALES DISEÑO DE UN MÉTODO PARA DETERMINAR UN CONJUNTO DE RECOMENDACIONES PARA REALIZAR LA INTEGRACIÓN DE APLICACIONES EMPRESARIALES VICTOR DANNEY GARCIA PLAZA MARIA TERESA LOPEZ DUEÑAS UNIVERSIDAD DE SAN BUENAVENTURA

Más detalles

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico

Capítulo II. Guía Gerencial de la Plataforma de Gobierno Electrónico Capítulo II Guía Gerencial de la Plataforma de Gobierno Electrónico 12 Capítulo II Guía Gerencial de la PGE Introducción Este capítulo presenta el concepto de gobierno electrónico, los desafíos de interoperabilidad

Más detalles

INTEGRACIÓN DE SISTEMAS HEREDADOS

INTEGRACIÓN DE SISTEMAS HEREDADOS CAPÍTULO 2 INTEGRACIÓN DE SISTEMAS HEREDADOS En el presente capítulo, se presenta el problema de integración de sistemas de Software. Una de cuyas características es la presencia de los llamados Sistemas

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

WebSphere Message Broker como Entreprise Service Bus

WebSphere Message Broker como Entreprise Service Bus IBM Software Group WebSphere Message Broker como Entreprise Service Bus Irene Couso, IT Specialist, SWG WebSphere Services Agenda WebSphere Problemática En Los Clientes Por Qué Esta Arquitectura? Oferta

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Components & Connectors Viewtype. Estilos

Components & Connectors Viewtype. Estilos Components & Connectors Viewtype Estilos 1 Estilos Especializan el C&C viewtype introduciendo tipos de componente y conector a los cuales pertenecerán las instancias del modelo Especifican patrones de

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Módulo 2. Arquitectura

Módulo 2. Arquitectura Módulo 2. Arquitectura Introducción Objetivos o Analizar la arquitectura física y lógica de la plataforma Agrega. o Identificar los componentes más importantes de la arquitectura física. o Exponer las

Más detalles

Qué se entiende por diseño arquitectónico? Comprende el establecimiento de un marco de trabajo estructural básico para un sistema. Alude a la estructura general del software y el modo en que la estructura

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Implementación de una Plataforma ESB Adaptativa

Implementación de una Plataforma ESB Adaptativa Instituto de Computación - Facultad de Ingeniería Universidad de la República Montevideo, Uruguay Implementación de una Plataforma ESB Adaptativa Informe de Proyecto de Grado Jorge Luis Laborde de los

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Arquitecturas de Integración

Arquitecturas de Integración Arquitecturas de Integración Ing. Gastón Escobar Ing. Nicolás Passerini Ing. Juan Arias Ing. Santiago Blanco 2006 Agenda Enterprise Architecture Integración de Sistemas Evolución histórica Métodos de integración

Más detalles

Tema 4: Diseño de flujos interaplicación

Tema 4: Diseño de flujos interaplicación Tema 4: Diseño de flujos interaplicación 4.1 Introducción a los Sistemas EAI Modelo de referencia (1) INTEGRACIÓN B2B INTEGRACIÓN DE APLICACIONES Y PROCESOS INTEGRACIÓN DE DATOS INTEGRACIÓN DE PLATAFORMA

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

2.1 Compuertas para Bases de Datos

2.1 Compuertas para Bases de Datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Uno de los aspectos mas importantes en un sistema multibase de datos es la forma en como llevar a cabo la comunicación

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Service Oriented Architecture: Con Biztalk?

Service Oriented Architecture: Con Biztalk? Service Oriented Architecture: Con Biztalk? Pablo Abbate Servicios Profesionales Danysoft SOA supone una nueva forma de pensar acerca de la arquitectura IT para las empresas. De hecho, es una asociación

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

La integración de información. Presente y futuro de la empresa moderna

La integración de información. Presente y futuro de la empresa moderna La integración de información. Presente y futuro de la empresa moderna Ing. Josue Carralero Iznaga, MSc. ISPJAE, Facultad de Ingeniería Informática, Departamento de Ingeniería de Software. Complejo de

Más detalles

Módulo 2 Comunicación

Módulo 2 Comunicación Sistemas Distribuidos Módulo 2 Comunicación Facultad de Ingeniería Departamento de Informática Universidad Nacional de la Patagonia San Juan Bosco Comunicación en Sistemas Distribuidos Modelos de Comunicaciones

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

Curso 5007437. Integración de Aplicaciones de Empresa (Enterprise Application Integratión, EAI)

Curso 5007437. Integración de Aplicaciones de Empresa (Enterprise Application Integratión, EAI) Curso 5007437 Conceptos y estándares de arquitecturas orientadas a servicios Web Curso 2006/2007 Capítulo 3: Integración de Aplicaciones de Empresa (Enterprise Application Integratión, EAI) Pedro Álvarez

Más detalles

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD BPMN Notación de modelado de procesos de negocio BPMN Fue desarrollado por la BPMI (Business Process Management Initiative) Objetivos: Proveer una notación entendible para cualquiera desde el analista

Más detalles

ESB. Norberto Fernández Departamento de Ingeniería Telemática http://www.it.uc3m.es/berto/ Tecnologías de Distribución de Contenidos - UC3M 1

ESB. Norberto Fernández Departamento de Ingeniería Telemática http://www.it.uc3m.es/berto/ Tecnologías de Distribución de Contenidos - UC3M 1 ESB Norberto Fernández Departamento de Ingeniería Telemática http://www.it.uc3m.es/berto/ 1 Motivación EAI (Enterprise Application Integration) Una organización tiene distintas suborganizaciones con distintos

Más detalles

Interoperabilidad. Conferencia: Presente y futuro de las SMART GRIDS en México. Ing. Alfredo Espinosa Reza aer@iie.org.mx

Interoperabilidad. Conferencia: Presente y futuro de las SMART GRIDS en México. Ing. Alfredo Espinosa Reza aer@iie.org.mx Interoperabilidad Conferencia: Presente y futuro de las SMART GRIDS en México Ing. Alfredo Espinosa Reza aer@iie.org.mx 29 de Octubre de 2013 Contenido Introducción. Estrategias para modelado y acceso

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Informe de avance Implementación herramientas de back-end (3-III).

Informe de avance Implementación herramientas de back-end (3-III). Proyecto RG-T1684 Desarrollo e implementación de las soluciones Prueba piloto del Componente III Informe Número 1. Informe de avance Implementación herramientas de back-end (3-III). Lautaro Matas 11/04/2013

Más detalles

LA ARQUITECTURA TCP/IP

LA ARQUITECTURA TCP/IP LA ARQUITECTURA TCP/IP Hemos visto ya como el Modelo de Referencia de Interconexión de Sistemas Abiertos, OSI-RM (Open System Interconection- Reference Model) proporcionó a los fabricantes un conjunto

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos

Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos Tesina Licenciatura en Informática (UNLP) Las tecnologías SOA y ESB como herramientas integradoras para el acceso unificado a servicios colaborativos heterogéneos Boccalari Cristian Temario General Visión

Más detalles

Ingeniería de Negocios y Desarrollo de Sistemas de Información

Ingeniería de Negocios y Desarrollo de Sistemas de Información Ingeniería de Negocios y Desarrollo de Sistemas de Información Procesos de Negocios Modelos de negocio Ingeniería de Negocios: Notaciones Procedimientos Patrones Proceso de desarrollo de sistemas Metodologías

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Taller de Sistemas de Información 3. Presentación SCA

Taller de Sistemas de Información 3. Presentación SCA Taller de Sistemas de Información 3 Presentación SCA Integrantes: Gustavo Fava Diego Salido Marcos Techera agosto de 2008 TSI 3 1 Introducción a SCA Aplicación: conjunto de componentes de software trabajando

Más detalles

Arquitectura de Proyectos de IT

Arquitectura de Proyectos de IT Arquitectura de Proyectos de IT Apunte: Introducción a MQ y conceptos de mensajería Autores: Patricio Echagüe patricioe@gmail.com Ing. Gastón Escobar gescobar@gmail.com Versión: 0.1 Octubre, 2005 1 Índice

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012

Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012 Título: Optimización de Procesos de Negocio con SOA / BPM Nombre y Apellido: Mario Bolo Email: bolo@ar.ibm.com Fecha: 15/08/2012 El problema: las aplicaciones tradicionales no le proveen la agilidad necesaria

Más detalles

Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones

Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3 Historia de revisiones Fecha Versión Descripción Autor 17/08/2005 1.0 Se hace la

Más detalles

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.

Más detalles

Etapas del desarrollo

Etapas del desarrollo Capítulo 4 Etapas del desarrollo Este capítulo documenta la aplicación del modelo presentado anteriormente, para el caso de la detección y clasificación de eventos sísmicos sobre señales digitales. El

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

Capítulo II. Arquitectura del Software

Capítulo II. Arquitectura del Software Capítulo II. Arquitectura del Software Después de un cuidadoso análisis de los objetivos del proyecto, se determinó que la mejor manera de estructurar el sistema era haciendo uso del muy famoso patrón

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Cómo lograr una implementación exitosa de SOA?

Cómo lograr una implementación exitosa de SOA? Software Huibert Aalbers Certified Executive Software IT Architect BUE Technical Sales, SW Services Manager IBM de Mexico 2007 IBM Corporation Agenda!Interoperabilidad! De dónde viene SOA?!Las distintas

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Procesos de Negocios

Procesos de Negocios Procesos de Negocios Procesos de negocios Como dijimos en el Tema 1: los sistemas de información y las organizaciones se influyen entre sí: Los SI deben proveer la información que la organización necesita.

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

Más detalles

BPMN 2.0. Bizagi Suite. Copyright 2014 Bizagi

BPMN 2.0. Bizagi Suite. Copyright 2014 Bizagi BPMN 2.0 Bizagi Suite BPMN 2.0 1 Tabla de Contenido Scope... 2 BPMN 2.0... 2 Qué es BPMN?... 2 Por qué es importante modelar con BPMN?... 3 Conceptos clave... 3 Proceso De Solicitud De Crédito... 3 Proceso

Más detalles

Administración de Variabilidad en una línea de producto basada en modelos

Administración de Variabilidad en una línea de producto basada en modelos Administración de Variabilidad en una línea de producto basada en modelos Kelly Garcés Carlos Parra Hugo Arboleda Andres Yie Rubby Casallas Universidad de los Andes, Bogotá k-garces @uniandes.edu.co Universidad

Más detalles

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO MODELO ARQUITECTURAL PARA UNA LÍNEA DE PRODUCCIÓN DE SOFTWARE QUE INTEGRA LAS INGENIERÍAS DEL DOMINIO Y APLICACIÓN USANDO InDoCaS DEYANIRETH DUARTE MARIN Barquisimeto,

Más detalles

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Las Redes IP; Conceptos básicos

Las Redes IP; Conceptos básicos WHITE PAPER Las redes IP: Conceptos básicos 0 Índice 1.- Introducción... 2 2.- Comunicación de redes, conceptos básicos... 2 3.- Fundamentos de transmisión... 4 4.- Infraestructura de la red de área local

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia

Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Implantación de una arquitectura orientada a servicios. Un caso de uso Mª Luisa Gutiérrez Acebrón División de Informática y Tecnologías de la Información Ministerio de Justicia Introducción Los compromisos

Más detalles

Propuestas de Proyectos de Grado 2014

Propuestas de Proyectos de Grado 2014 Propuestas de Proyectos de Grado 2014 Laboratorio de Integración de Sistemas 26 de Febrero, 2014 Instituto de Computación Facultad de Ingeniería Universidad de la República de Uruguay Laboratorio de Integración

Más detalles

ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN ARQUITECTURA SOA Services Oriented Arquitecture SOA como arquitectura para BPM Las organizaciones deben

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

Taller de Sistemas de Información 2

Taller de Sistemas de Información 2 Taller de Sistemas de Información 2 Clase 1 Aruitecturas y Middlewares Contenido Aruitectura de un sistema Evolución de las aruitecturas Monolíticas File sharing Cliente/Servidor En capas SOA Middlewares

Más detalles

16/04/2015. Peer to Peer Style

16/04/2015. Peer to Peer Style Implicit Invocation Implicit Invocation Event-Based Event-Based Características Componentes independientes comunicándose sólo enviando eventos a través de conectores a un event-bus Los componentes emiten

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Arquitecturas de Software

Arquitecturas de Software Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO

Más detalles

Capítulo 6: Instrumentación: Diseño del Sistema de H2O

Capítulo 6: Instrumentación: Diseño del Sistema de H2O Capítulo 6: Instrumentación: Diseño del Sistema de H2O Digital Media Server El video en demanda a través del web aún está restringido a las grandes empresas que pueden pagar por contar por un servicio

Más detalles

Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos.

Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos. I JORNADAS DE SIG LIBRE Arquitectura SOA para la integración entre software libre y software propietario en entornos mixtos. Alejandro Guinea de Salas (1), Sergio Jorrín Abellán (2) (1) Director de Geograma

Más detalles

La aplicación práctica en el mundo empresarial de los estándares Web

La aplicación práctica en el mundo empresarial de los estándares Web La aplicación práctica en el mundo empresarial de los estándares Web El problema de la integración inter/intra empresas y la familia "XML" Enrique Bertrand XML Business Integration, Regional Director Software

Más detalles

Service Broker. Bind. Service Consumer. Service Provider

Service Broker. Bind. Service Consumer. Service Provider En este capítulo, usted podrá empezar por mirar a la arquitectura orientada al servicio como un concepto en arquitectura para aplicaciones distribuidas. A continuación usted examinará cómo estas arquitecturas

Más detalles

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software

Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Ramón Gómez-Romero, Karen Cortés Verdin, Juan Carlos Pérez Arriaga, Ángeles Arenas Valdés Universidad

Más detalles

Servicios Web. Capítulo 3: Integración de Aplicaciones de Empresa (Enterprise Application Integratión, EAI)

Servicios Web. Capítulo 3: Integración de Aplicaciones de Empresa (Enterprise Application Integratión, EAI) Servicios Web Capítulo 3: Integración de Aplicaciones de Empresa (Enterprise Application Integratión, EAI) Pedro Álvarez alvaper@unizar.es José Ángel Bañares banares@unizar.es http://diis.unizar.es/postweb/

Más detalles

Creando Arquitecturas

Creando Arquitecturas Creando Arquitecturas orientadas a servicios SOA Suite Abril 2013 Buenos Aires - Argentina Índice 1. Introducción. 2. Nuestro camino para la creación de SOAs. 3. Como justificar el cambio? 4. Nuestras

Más detalles

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores REPORTE OFICIAL OCTUBRE DE 2014 CA Unified Infrastructure Management para servidores 2 Reporte oficial: CA Unified Infrastructure Management para servidores Tabla de contenidos Descripción general de la

Más detalles

Clientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea

Clientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3

Más detalles

SISTEMAS DE INFORMACIÓN III TEORÍA

SISTEMAS DE INFORMACIÓN III TEORÍA CONTENIDO: Introducción a los Web services Las bases de los Web services La nueva generación de la Web Interactuando con los Web services La tecnología de Web services XML: Lo fundamental WSDL: Describiendo

Más detalles

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas

Unidad I Fundamentos de Sistemas Distribuidos. M.C. Juan Carlos Olivares Rojas Unidad I Fundamentos de Sistemas Distribuidos M.C. Juan Carlos Olivares Rojas Temario 1.1. Características de un sistema distribuido 1.2. Objetivos de los sistemas distribuidos 1.3. Ventajas y desventajas

Más detalles

COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA. Instituto Tecnológico de Nogales (ITN)

COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA. Instituto Tecnológico de Nogales (ITN) COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA 1 Ismael Armando Zúñiga Félix y 2 Luicyana Pérez Figueroa 1,2 División de Estudios de Posgrado e Investigación (DEPI), Instituto

Más detalles

Introducción a redes Ing. Aníbal Coto Cortés

Introducción a redes Ing. Aníbal Coto Cortés Capítulo 5: Ethernet Introducción a redes Ing. Aníbal Coto Cortés 1 Objetivos En este capítulo, aprenderá a: Describir el funcionamiento de las subcapas de Ethernet. Identificar los campos principales

Más detalles