libro

Prefacio por John Crupi ¿Qué haces cuando llega una nueva tecnología? Aprendes la tecnología. Esto es exactamente lo que yo hizo. Estudié J2EE (siendo de Sun Microsystems, parecía ser la elección lógica). Específicamente, Me concentré en la tecnología EJB leyendo las especificaciones (ya que aún no había libros). Sin embargo, aprender la tecnología es sólo el primer paso; el verdadero objetivo es aprender a utilizarla de manera efectiva. aplicar la tecnología. Lo bueno de las tecnologías de plataforma es que te obligan a realizando ciertas tareas. Pero, en lo que respecta a la tecnología, puedes hacer lo que quieras. quieres y muy a menudo te metes en problemas si no haces las cosas apropiadamente. Una cosa que he visto en los últimos 15 años es que parece haber dos áreas en las que el software Los desarrolladores se obsesionan con: programar y diseñar, o más específicamente, programar y diseñar de manera efectiva. Existen excelentes libros que le indican la forma más eficaz de programan ciertas cosas en Java y C#, pero muchos menos le dicen cómo diseñar de manera efectiva. Eso es donde entra en juego este libro. Cuando Deepak Alur, Dan Malks y yo escribimos Core J2EE Patterns, Quería ayudar a los desarrolladores de J2EE a "diseñar" un mejor código. La mejor decisión que tomamos fue utilizar patrones como el artefacto de elección. Como dice James Baty, un ingeniero distinguido de Sun, “Los patrones Parece ser el punto óptimo del diseño”. No podría estar más de acuerdo y, por suerte para nosotros, Gregor y Bobby sentir de la misma manera. Este libro se centra en un tema candente y en crecimiento: la integración mediante mensajería. No sólo es La mensajería es clave para la integración, pero lo más probable es que sea el enfoque predominante en los servicios web para los próximos años. Hay tanto ruido hoy en día en el mundo de los servicios web, es un tema delicado y esfuerzo complejo sólo para identificar las especificaciones y tecnologías en las que centrarse. La meta Sin embargo, sigue siendo lo mismo: el software le ayuda a resolver un problema. Al igual que en los primeros días de J2EE y .NET, todavía no existe mucha ayuda de diseño para servicios web. Mucha gente dice Los servicios web son simplemente una forma nueva y abierta de resolver nuestros problemas de integración existentes, y estoy de acuerdo. Pero eso no significa que sepamos cómo diseñar servicios web. Y eso nos lleva a la joya de este libro. Creo que este libro tiene muchos de los patrones que necesitamos para diseñar servicios web y otros sistemas de integración. Debido a que las especificaciones del servicio web todavía están en pugna, no sería Ha tenido sentido que Bobby y Gregor proporcionen ejemplos de muchos de los servicios web. especificaciones. Pero eso está bien. La verdadera recompensa se producirá cuando las especificaciones se vuelvan estándares y utilizamos los patrones de este libro para diseñar aquellas soluciones que se realizan mediante estos estándares. Entonces tal vez podamos alcanzar nuestro próximo objetivo de integración: diseñar para Arquitecturas orientadas a servicios. Lee este libro y mantenlo a tu lado. Mejorará su carrera de software sin fin. John Crupi Bethesda, Maryland, EE.UU. agosto de 2003

Prefacio por Martin Fowler Mientras trabajaba en mi libro Patrones de arquitectura de aplicaciones empresariales, tuve la suerte de recibir una revisión en profundidad de Kyle Brown y Rachel Reinitz en algunos talleres informales en Kyle's oficina en Raleigh-Durham. Durante estas sesiones, nos dimos cuenta de que había un gran vacío en mi trabajo. Sistemas de mensajería asincrónica. Hay muchas lagunas en mi libro y nunca pretendí que fuera una colección completa de Patrones para el desarrollo empresarial. Pero la brecha en la mensajería asincrónica es particularmente importante porque creemos que la mensajería asincrónica desempeñará un papel cada vez más importante papel en el desarrollo de software empresarial, particularmente en la integración. La integración es importante porque las aplicaciones no pueden vivir aisladas unas de otras. Necesitamos técnicas que nos permitan tomar aplicaciones que nunca fueron diseñadas para interoperar y romper los tubos de escape para que podamos podemos obtener un beneficio mayor que el que las aplicaciones individuales pueden ofrecernos. Han existido varias tecnologías que prometen resolver el rompecabezas de la integración. Todos concluyó que la mensajería es la tecnología más prometedora. El desafío que tenemos Lo que enfrentamos fue transmitir cómo enviar mensajes de manera efectiva. El mayor desafío en esto es que Los mensajes son por naturaleza asincrónicos y existen diferencias significativas en el diseño. enfoques que utiliza en un mundo asincrónico. No tenía espacio, energía o, francamente, el conocimiento para cubrir este tema adecuadamente en Patrones. de Arquitectura de Aplicaciones Empresariales. Pero se nos ocurrió una solución mejor para esta brecha: encontrar alguien más que pudiera. Buscamos a Gregor y Bobby y aceptaron el desafío. El resultado es el libro que estás a punto de leer. Estoy encantado con el trabajo que han hecho. Si ya has trabajado con mensajería sistemas, este libro sistematizará gran parte del conocimiento que usted y otros ya tienen. aprendió de la manera más difícil. Si está a punto de trabajar con sistemas de mensajería, este libro le proporcionará una base que será invaluable sin importar con qué tecnología de mensajería tengas para trabajar con. Martín Fowler Melrose, Massachusetts, EE.UU. agosto de 2003

Prefacio Este es un libro sobre la integración empresarial mediante mensajería. No documenta ningún particular tecnología o producto. Más bien, está diseñado para desarrolladores e integradores que utilizan una variedad de productos y tecnologías de mensajería, tales como: • Middleware orientado a mensajes (MOM) y suites de integración ofrecidas por proveedores como IBM (familia WebSphere MQ), Microsoft (BizTalk), TIBCO, WebMethods, SeeBeyond, Vitria y otros • Implementaciones de Java Message Service (JMS) incorporadas en sistemas comerciales y servidores de aplicaciones J2EE de código abierto, así como productos independientes • Message Queuing de Microsoft (MSMQ), accesible a través de varias API, incluida la Bibliotecas System.Messaging en Microsoft .NET • Estándares de servicios web emergentes que soportan servicios web asíncronos (por ejemplo, WS-ReliableMessaging) y las API asociadas, como la API Java de Sun para XML Mensajería (JAXM) o Extensiones de servicios web de Microsoft (WSE). La integración empresarial va más allá de la creación de una única aplicación con n niveles distribuidos arquitectura, que permite distribuir una única aplicación en varios ordenadores. Mientras que un nivel en una aplicación distribuida no puede ejecutarse por sí solo, las aplicaciones integradas son programas independientes que cada uno puede ejecutarse por sí mismo, pero que funcionan coordinándose con cada uno otros de manera débilmente acoplada. La mensajería permite enviar datos o comandos a través de la red utilizando un enfoque de "enviar y olvidar" donde la persona que llama envía la información y luego pasa a otros trabajos mientras la información es transmitida por el sistema de mensajería. Opcionalmente, Posteriormente, la persona que llama puede ser notificada del resultado mediante una devolución de llamada. Llamadas asincrónicas y devoluciones de llamada puede hacer que un diseño sea más complejo que un enfoque sincrónico, pero una llamada asincrónica puede ser Vuelva a intentarlo hasta que tenga éxito, lo que hace que la comunicación sea mucho más confiable. Asincrónico La mensajería también permite otras ventajas, como la limitación de solicitudes y la carga. equilibrio. Quién debería leer este libro Este libro está diseñado para ayudar a los desarrolladores de aplicaciones e integradores de sistemas a conectar aplicaciones. utilizando productos de middleware orientados a mensajes: • Arquitectos y desarrolladores de aplicaciones que diseñan y construyen empresas complejas. aplicaciones que necesitan integrarse con otras aplicaciones. Asumimos que eres desarrollar sus aplicaciones utilizando una plataforma de aplicaciones empresariales moderna como Plataforma Java 2, Enterprise Edition (J2EE) o el marco Microsoft .NET. Este libro le ayudará a conectar la aplicación a una capa de mensajería e intercambiar información con otras aplicaciones. Este libro se centra en la integración de aplicaciones, no en ​ Enviar comentarios Paneles laterales Historial Guardado Contribuir

aplicaciones de construcción; para ello le remitimos a Patrones de Aplicación Empresarial Arquitectura de Martin Fowler. • Arquitectos y desarrolladores de integración que diseñan y construyen soluciones de integración. conectar aplicaciones empaquetadas o personalizadas. La mayoría de los lectores de este grupo tendrán experiencia con una de las muchas herramientas de integración comercial como IBM WebSphere MQ, TIBCO, WebMethods, SeeBeyond, Vitria, etc. Muchas de estas herramientas incorporan los patrones presentado en este libro. Este libro ayuda a los lectores a comprender los conceptos subyacentes y Tome decisiones de diseño seguras utilizando un vocabulario independiente del proveedor. • Los arquitectos empresariales deben mantener una visión general del software y Activos de hardware en una empresa. Este libro presenta un lenguaje consistente para describir soluciones de integración a gran escala que pueden abarcar muchas tecnologías o puntos soluciones. Este lenguaje también es un facilitador clave para una comunicación eficiente entre los arquitecto empresarial y arquitectos y desarrolladores de integración y aplicaciones. Lo que vas a aprender Este libro no intenta presentar un argumento comercial para la integración de aplicaciones empresariales; el La atención se centra en cómo hacerlo funcionar. Los lectores de este libro aprenderán cómo integrar la empresa aplicaciones entendiendo: • Las ventajas y limitaciones de la mensajería en comparación con otras técnicas de integración. • Cómo determinar los canales de mensajes que necesitarán sus aplicaciones, cómo controlarlos si varios consumidores pueden recibir el mismo mensaje y cómo manejarlos no válidos mensajes • Cuándo enviar un mensaje, qué debe contener y cómo utilizar un mensaje especial propiedades • Cómo enrutar un mensaje a su destino final incluso cuando el remitente no lo sabe donde esta eso • Cómo convertir mensajes cuando el remitente y el receptor no están de acuerdo en un acuerdo común formato • Cómo diseñar el código que conecta una aplicación al sistema de mensajería • Cómo gestionar y monitorear un sistema de mensajería una vez que esté en uso como parte de la empresa Incluso los lectores que estén familiarizados con estas prácticas se beneficiarán al tenerlas documentadas. y poder utilizarlos para facilitar la comunicación con sus compañeros. Lo que este libro no cubre Creemos que cualquier libro que lleve la palabra "empresa" en el título probablemente caerá en uno de los siguientes tres categorías. O intenta cubrir toda la amplitud del tema y será obligados a no ofrecer una orientación detallada sobre cómo implementar soluciones reales. O el libro proporcionar orientación práctica específica sobre el desarrollo de soluciones reales, pero se ve obligado a limitar el alcance del área temática que aborda. Por último, los libros que intentan hacer ambas cosas son

Es probable que nunca se terminen o que se publiquen tan tarde que resulten irrelevantes. Optamos por el segundo. elección y, con suerte, creó un libro que ayude a las personas a crear mejores soluciones de integración incluso aunque tuvimos que limitar el alcance del libro. Temas que nos hubiera encantado discutir pero Tuve que excluir para no caer en la trampa de la categoría tres: seguridad, datos complejos. mapeo, flujo de trabajo, motores de reglas, escalabilidad y solidez, y transacciones distribuidas procesamiento (XA, Tuxedo y similares). Elegimos la mensajería asincrónica como énfasis para esto. libro porque está lleno de interesantes cuestiones de diseño y compensaciones y proporciona una abstracción limpia de las muchas implementaciones proporcionadas por varios proveedores de integración. Este libro tampoco es un tutorial sobre una tecnología de mensajería o middleware específica. Usted encontrará ejemplos basados en una serie de tecnologías diferentes en este libro, como JMS, MSMQ, TIBCO, Microsoft BizTalk, XSL, etc. Incluimos estos ejemplos con fines ilustrativos para mostrar a los lectores cómo el patrón podría traducirse en una implementación real. Si usted está interesado en Para obtener más información sobre cualquiera de estas tecnologías específicas, consulte uno de los libros a los que se hace referencia. en la bibliografía o en uno de los muchos recursos en línea. Cómo está organizado este libro El núcleo del libro contiene 65 patrones que forman un lenguaje de patrones. Libros como Diseño Patrones, arquitectura de software orientada a patrones, patrones centrales J2EE y patrones de empresa La arquitectura de aplicaciones ha popularizado la noción de utilizar patrones para documentar técnicas de programación informática. El concepto de patrones y lenguajes de patrones fue Aplicado originalmente a la arquitectura de ciudades y edificios por Christopher Alexander en su obra seminal obras Un lenguaje de patrones y una forma atemporal de construir. Para ayudar al lector a diseñar una integración. solución, cada patrón representa una decisión que el lector debe tomar, explica el consideraciones que afectan la decisión y presenta una solución bien considerada para guiar la decisión. Un lenguaje de patrones es una red de patrones relacionados donde cada patrón conduce a otros, guiar al lector a través del proceso de toma de decisiones. Este enfoque es una técnica poderosa. para documentar el conocimiento de un experto de modo que pueda ser fácilmente comprendido y aplicado por no expertos. Un lenguaje de patrones enseña al lector cómo resolver una variedad ilimitada de problemas dentro de un espacio problemático acotado. Debido a que el problema general que se está resolviendo es diferente cada vez, el camino a través de los patrones y cómo se aplican también es único. De esta manera, este libro fue escrito para cualquier persona que utilice cualquier herramienta de mensajería o integración para cualquier propósito, pero se puede aplicar específicamente para usted y la aplicación específica de mensajería a la que se enfrenta. Los patrones describen soluciones comúnmente aceptadas a problemas recurrentes, por lo que si eres un desarrollador experimentado de soluciones de integración orientadas a mensajes, muchos de estos patrones te resulta familiar. Sin embargo, incluso si ya reconoces la mayoría de estos patrones, todavía hay valor al revisar este libro. Este libro debería validar la comprensión que tanto le ha costado ganar sobre cómo utilizar mensajería. Le brinda una referencia consolidada para ayudarlo a transmitir sus conocimientos de manera efectiva a colegas menos experimentados. También documenta detalles de las soluciones y relaciones entre

ellos de los que quizás no eras consciente. Finalmente, los nombres de los patrones le dan una idea común. Vocabulario para discutir eficientemente alternativas de diseño de integración con sus compañeros. Agradecimientos Como la mayoría de los libros, la elaboración de Patrones de integración empresarial ha tardado mucho tiempo. La idea de Los escritos sobre patrones de integración basados en mensajes se remontan al verano de 2001, cuando Martin Estaba trabajando en patrones de arquitectura de aplicaciones empresariales. En ese momento, a Kyle se le ocurrió que Si bien P de EAA habló mucho sobre cómo crear aplicaciones, solo toca brevemente cómo integrarlos. Esta idea fue el punto de partida de una serie de reuniones entre Martin y Kyle. eso también incluía a Rachel Reinitz y John Crupi. Bobby se unió a estas discusiones en el otoño de 2001, seguido por Gregor a principios de 2002. El verano siguiente, el grupo presentó dos artículos para su revisión en la conferencia Pattern Languages of Programs (PLoP), escrita conjuntamente por Bobby y Kyle y el otro por Gregor. Después de la conferencia, Kyle y Martin volvieron a centrarse en sus propios proyectos de libros mientras Gregor y Bobby fusionaban sus artículos para formar la base del libro. Al mismo tiempo, se puso en marcha el sitio www.enterpriseintegrationpatterns.com para permitir arquitectos y desarrolladores de integración de todo el mundo para participar en la rápida evolución de el contenido. Mientras trabajaban en el libro, Gregor y Bobby invitaron a los colaboradores a ayudar descubrir el contenido del libro. Aproximadamente dos años después de la idea original de Kyle, llegó el manuscrito final. el editor. Este libro no habría sido posible sin la ayuda de una larga lista de colaboradores. Nombres aquí... Acerca de la imagen de portada El tema común de los libros de Martin Fowler Signature Series es la imagen de un puente. En En cierto sentido tuvimos suerte, porque ¿qué tema encajaría mejor con un libro sobre ¿integración? Durante miles de años, los puentes han ayudado a conectar a personas de diferentes orillas. montañas o lados de la carretera. Seleccionamos una imagen del Puente Taiko-bashi en el Santuario Sumiyoshi-taisha en Osaka, Japón por su sencilla elegancia y belleza. Como santuario sintoísta dedicado a la deidad guardiana de los marineros, Originalmente se construyó junto al agua. Curiosamente, la recuperación de tierras ha empujado al agua de distancia, de modo que el santuario hoy se encuentra casi tres millas tierra adentro. Unos 3 millones de personas visitan este Santuario al comienzo de un nuevo año.

Introducción Las aplicaciones interesantes rara vez viven aisladas. Si su aplicación de ventas debe interactuar con su aplicación de inventario, su aplicación de adquisición debe conectarse a un sitio de subasta, o el PIM de su PDA debe sincronizarse con el servidor de calendario corporativo, parece que cualquier La aplicación se puede mejorar integrándola con otras aplicaciones. Todas las soluciones de integración tienen que afrontar algunos desafíos fundamentales: • Las redes no son confiables. Las soluciones de integración tienen que transportar datos de una computadora a otro a través de redes. En comparación con un proceso que se ejecuta en una sola computadora, La computación distribuida tiene que estar preparada para lidiar con un conjunto mucho mayor de posibles problemas. Muchas veces, dos sistemas a integrar están separados por continentes y datos. entre ellos tiene que viajar a través de líneas telefónicas, segmentos LAN, enrutadores, conmutadores, redes y enlaces satelitales. Cada uno de estos pasos puede causar retrasos o interrupciones. • Las redes son lentas. Enviar datos a través de una red es varios órdenes de magnitud más lento que hacer una llamada a un método local. Diseñar una solución ampliamente distribuida de la misma manera te acercarías a una sola aplicación podría tener un rendimiento desastroso trascendencia. • Dos aplicaciones cualesquiera son diferentes. Las soluciones de integración necesitan transmitir información. entre sistemas que utilizan diferentes lenguajes de programación, plataformas operativas y formatos de datos. Una solución de integración debe poder interactuar con todos estos diferentes tecnologías. • El cambio es inevitable. Las aplicaciones cambian con el tiempo. Una solución de integración debe mantener al ritmo de los cambios en las aplicaciones que conecta. Las soluciones de integración pueden obtenerse fácilmente atrapado en una avalancha de cambios: si un sistema cambia, todos los demás sistemas pueden Ser afectado. Una solución de integración necesita minimizar las dependencias de un sistema. a otro mediante el uso de un acoplamiento flojo entre aplicaciones. Con el tiempo, los desarrolladores han superado estos desafíos con cuatro enfoques principales: 1. Transferencia de archivos: una aplicación escribe un archivo que otra lee más tarde. Las aplicaciones Es necesario acordar el nombre del archivo y la ubicación, el formato del archivo, el momento en que se se escribirá y leerá, y quién eliminará el archivo. 2. Base de datos compartida: varias aplicaciones comparten el mismo esquema de base de datos, ubicado en un base de datos física única. Como no hay almacenamiento de datos duplicados, no es necesario almacenar datos. transferidos de una aplicación a otra. 3. Invocación de procedimiento remoto: una aplicación expone parte de su funcionalidad para que otras aplicaciones pueden acceder de forma remota como procedimiento remoto. El La comunicación se produce en tiempo real y sincrónicamente. 4. Mensajería: una aplicación publica un mensaje en un canal de mensajes común. Otro las aplicaciones pueden leer el mensaje del canal más adelante. Las aplicaciones deben

Acordar un canal así como el formato del mensaje. La comunicación es asincrónico. Si bien los cuatro enfoques resuelven esencialmente el mismo problema, cada estilo tiene sus diferencias. ventajas y desventajas. De hecho, las aplicaciones pueden integrarse utilizando múltiples estilos, de modo que cada punto de integración aprovecha el estilo que más le conviene. ¿Qué es la mensajería? Este libro trata sobre cómo utilizar la mensajería para integrar aplicaciones. Una forma sencilla de entender lo que hace la mensajería es considerar el sistema telefónico. Una llamada telefónica es una forma sincrónica. de comunicación. Sólo puedo comunicarme con la otra parte si la otra parte está disponible en el momento en que hago la llamada. El correo de voz, por otro lado, permite la comunicación asincrónica. Con correo de voz, cuando el receptor no responde, la persona que llama puede dejarle un mensaje; más tarde el El receptor (a su conveniencia) puede escuchar los mensajes en cola en su buzón. El correo de voz habilita que la persona que llama deje un mensaje ahora para que el receptor pueda escucharlo más tarde, lo cual es mucho más fácil que intentando que la persona que llama y el receptor hablen por teléfono al mismo tiempo. Paquetes de correo de voz (en al menos parte de) una llamada telefónica en un mensaje y lo pone en cola para su consumo posterior; esto es esencialmente cómo funciona la mensajería. La mensajería es una tecnología que permite comunicación asincrónica y de alta velocidad entre programas. Comunicación con entrega confiable. Los programas se comunican enviando paquetes de datos llamados mensajes entre sí. Los canales, también conocidos como colas, son vías lógicas que conectan el programas y transmitir mensajes. Un canal se comporta como una colección o conjunto de mensajes, pero uno que se comparte mágicamente entre varias computadoras y puede ser utilizado simultáneamente por múltiples aplicaciones. Un remitente o productor es un programa que envía un mensaje escribiéndolo en un canal. Un receptor o consumidor es un programa que recibe un mensaje leyéndolo (y eliminándolo) desde un canal. El mensaje en sí es simplemente algún tipo de estructura de datos, como una cadena, una matriz de bytes, un registro, o un objeto. Puede interpretarse simplemente como datos, como la descripción de un comando que se va a invocar. en el receptor, o como la descripción de un evento que ocurrió en el remitente. un mensaje en realidad Contiene dos partes, un encabezado y un cuerpo. El encabezado contiene metainformación sobre el mensaje: quién lo envió, adónde va, etc.; Esta información es utilizada por el sistema de mensajería. y las aplicaciones que utilizan los mensajes lo ignoran en su mayor parte (pero no siempre). El cuerpo contiene los datos que se transmiten y son ignorados por el sistema de mensajería. En una conversación, cuando un El desarrollador de aplicaciones que utiliza la mensajería habla de un mensaje, normalmente se refiere al datos en el cuerpo del mensaje. Las arquitecturas de mensajería asincrónica son poderosas, pero requieren que reconsideremos nuestro desarrollo. acercarse. En comparación con los otros tres enfoques de integración, relativamente pocos desarrolladores han tenido exposición a mensajería y sistemas de mensajes. Como resultado, los desarrolladores de aplicaciones en general No estamos tan familiarizados con los modismos y peculiaridades de esta plataforma de comunicación. ​

¿Qué es un sistema de mensajería? Las capacidades de mensajería generalmente las proporciona un sistema de software independiente llamado mensajería. sistema o middleware orientado a mensajes (MOM). Un sistema de mensajería gestiona la mensajería de la misma manera que un El sistema de base de datos gestiona la persistencia de los datos. Así como un administrador debe poblar la base de datos con el esquema para los datos de una aplicación, un administrador debe configurar el sistema de mensajería con los canales que definen las vías de comunicación entre las aplicaciones. El El sistema de mensajería coordina y gestiona el envío y la recepción de mensajes. El El objetivo principal de una base de datos es garantizar que cada registro de datos persista de forma segura y, de la misma manera, La tarea principal de un sistema de mensajería es mover mensajes desde la computadora del remitente a la computadora del receptor de manera confiable. La razón por la que se necesita un sistema de mensajería para mover mensajes de una computadora a otra es que Las computadoras y las redes que las conectan son inherentemente poco confiables. Sólo porque uno aplicación esté lista para enviar una comunicación no significa que la otra aplicación esté lista para enviar recíbelo. Incluso si ambas aplicaciones están listas, es posible que la red no esté funcionando o que no funcione correctamente. transmitir los datos correctamente. Un sistema de mensajería supera estas limitaciones intentando repetidamente transmitir el mensaje hasta lograrlo. En circunstancias ideales, el mensaje se transmite con éxito en el primer intento, pero las circunstancias a menudo no son las ideales. En esencia, un mensaje se transmite en cinco pasos: 1. Crear: el remitente crea el mensaje y lo completa con datos. 2. Enviar: el remitente agrega el mensaje a un canal. 3. Entregar: el sistema de mensajería mueve el mensaje desde la computadora del remitente a la computadora del receptor, poniéndolo a disposición del receptor. 4. Recibir: el receptor lee el mensaje del canal. 5. Proceso: el receptor extrae los datos del mensaje. Este diagrama ilustra estos cinco pasos de transmisión, qué computadora realiza cada uno y cuál Los pasos involucran el sistema de mensajería:

Este diagrama también ilustra dos conceptos de mensajería importantes: 1. Enviar y olvidar: en el paso 2, la aplicación emisora envía el mensaje al mensaje canal. Una vez que se completa el envío, el remitente puede continuar con otro trabajo mientras el El sistema de mensajería transmite el mensaje en segundo plano. El remitente puede estar seguro que el receptor eventualmente recibirá el mensaje y no tendrá que esperar hasta que sucede. 2. Almacenar y reenviar: en el paso 2, cuando la aplicación emisora envía el mensaje al canal de mensaje, el sistema de mensajería almacena el mensaje en la computadora del remitente, ya sea en memoria o en disco. En el paso 3, el sistema de mensajería entrega el mensaje mediante reenviarlo desde la computadora del remitente a la computadora del receptor, y luego almacena el mensaje una vez más en la computadora del receptor. Este proceso de almacenamiento y reenvío puede ser se repite muchas veces, a medida que el mensaje se mueve de una computadora a otra, hasta que llega al ordenador del receptor. Los pasos de crear, enviar, recibir y procesar pueden parecer una sobrecarga innecesaria. Por qué no ¿Simplemente entregar los datos al receptor? Envolviendo los datos como un mensaje y almacenándolos en el sistema de mensajería, las aplicaciones delegan en el sistema de mensajería la responsabilidad de entregando los datos. Debido a que los datos están empaquetados como un mensaje atómico, se puede volver a intentar la entrega. hasta que tenga éxito y el receptor pueda estar seguro de recibir de manera confiable exactamente una copia de los datos. ¿Por qué utilizar la mensajería? Ahora que sabemos qué es la mensajería, deberíamos preguntarnos: ¿Por qué utilizar la mensajería? Como con cualquier solución sofisticada, no existe una respuesta sencilla. La respuesta rápida es que la mensajería es más inmediato que File Transfer, mejor encapsulado que Shared Database y más confiable que Invocación de Procedimiento Remoto. Sin embargo, eso es sólo el comienzo de las ventajas que se pueden obtener. obtenidos mediante la mensajería. Los beneficios específicos de la mensajería incluyen:

Comunicación remota. La mensajería permite que aplicaciones separadas se comuniquen y transferir datos. Dos objetos que residen en el mismo proceso pueden simplemente compartir los mismos datos. en memoria. Enviar datos a otra computadora es mucho más complicado y requiere datos que se van a copiar de una computadora a otra. Esto significa que los objetos tienen que "serializables", es decir, se pueden convertir en un flujo de bytes simple que se puede enviar a través de la red. Si no se necesita comunicación remota, no se necesitan mensajes; un mas simple Una solución como colecciones simultáneas o memoria compartida es suficiente. • Integración de plataforma/idioma. Cuando se conectan varios sistemas informáticos de forma remota comunicación, estos sistemas probablemente utilicen diferentes lenguajes, tecnologías y plataformas, quizás porque fueron desarrollados con el tiempo por equipos independientes. Integrando tales Las aplicaciones divergentes pueden requerir una zona desmilitarizada de middleware para negociar. entre las aplicaciones, a menudo utilizando el mínimo común denominador, como datos planos archivos con formatos oscuros. En estas circunstancias, un sistema de mensajería puede ser universal. Traductor entre las aplicaciones que funciona con el idioma y plataforma de cada una. sus propios términos, pero les permite comunicarse a través de un mensaje común paradigma. Esta conectividad universal es el corazón del patrón Message Bus. • Comunicación asíncrona. La mensajería permite un enfoque de enviar y olvidar para comunicación. El remitente no tiene que esperar a que el receptor reciba y procese el mensaje; ni siquiera tiene que esperar a que el sistema de mensajería entregue el mensaje. El remitente sólo necesita esperar a que se envíe el mensaje, p. para que el mensaje ser almacenado exitosamente en el canal por el sistema de mensajería. Una vez que el mensaje es almacenado, el remitente es libre de realizar otros trabajos mientras el mensaje se transmite en el fondo. Es posible que el receptor desee enviar un acuse de recibo o un resultado a el remitente, lo que requiere otro mensaje, cuya entrega deberá ser detectada por un Mecanismo de devolución de llamada en el remitente. • Temporización variable. Con la comunicación síncrona, la persona que llama debe esperar a que el receptor Termine de procesar la llamada antes de que la persona que llama pueda recibir el resultado y continuar. De este modo, la persona que llama sólo puede realizar llamadas tan rápido como el receptor puede realizarlas. Por otro lado, La comunicación asincrónica permite al remitente enviar solicitudes por lotes al receptor en su propio ritmo y que el receptor consuma las solicitudes a su propio ritmo diferente. Este permite que ambas aplicaciones se ejecuten al máximo rendimiento y no pierdan tiempo esperando entre sí (al menos hasta que el receptor se quede sin mensajes para procesar). • Estrangulamiento. Un problema con las llamadas a procedimientos remotos es que muchas de ellas en una sola receptor al mismo tiempo puede sobrecargarlo. Esto puede provocar que el rendimiento degradación e incluso causar que el receptor se bloquee. La comunicación asincrónica permite el receptor controle la velocidad a la que consume solicitudes, para no volverse sobrecargado por demasiadas solicitudes simultáneas. El efecto adverso en las personas que llaman causado por Esta limitación se minimiza porque la comunicación es asincrónica, por lo que las personas que llaman no están bloqueados esperando en el receptor. • Comunicación confiable. La mensajería proporciona una entrega confiable que una llamada a procedimiento remoto (RPC) no puede. La razón por la que la mensajería es más confiable que RPC es que la mensajería utiliza un Método de almacenamiento y reenvío para transmitir mensajes. Los datos se empaquetan como mensajes, que son unidades atómicas independientes. Cuando el remitente envía un mensaje, el mensaje El sistema almacena el mensaje. Luego entrega el mensaje reenviándolo al destinatario.

computadora, donde se almacena nuevamente. Almacenar el mensaje en la computadora del remitente y en el Se supone que la computadora del receptor es confiable. (Para hacerlo aún más confiable, el los mensajes se pueden almacenar en el disco en lugar de en la memoria; consulte Entrega garantizada). ¿Qué es no confiable es reenviar (mover) el mensaje desde la computadora del remitente al computadora del receptor, porque es posible que el receptor o la red no estén funcionando correctamente. El sistema de mensajería soluciona esto reenviando el mensaje hasta que lo logra. Este El reintento automático permite que el sistema de mensajería supere los problemas con la red. de modo que el remitente y el receptor no tengan que preocuparse por estos detalles. • Operación desconectada. Algunas aplicaciones están diseñadas específicamente para ejecutarse sin conexión desde la red, pero aún debe sincronizarse con los servidores cuando se establece una conexión de red. disponible. Estas aplicaciones se implementan en plataformas como computadoras portátiles, PDA y tableros de instrumentos de automóviles. La mensajería es ideal para permitir que estas aplicaciones sincronizar: los datos que se van a sincronizar se pueden poner en cola a medida que se crean, esperando hasta que La aplicación se vuelve a conectar a la red. • Mediación. El sistema de mensajería actúa como mediador, como en el patrón Mediador. [GoF]: entre todos los programas que pueden enviar y recibir mensajes. Una aplicación Puede usarlo como un directorio de otras aplicaciones o servicios disponibles para integrar. Si una La aplicación se desconecta de las demás, solo necesita volver a conectarse al sistema de mensajería, no a todas las demás aplicaciones de mensajería. El sistema de mensajería. se puede utilizar para proporcionar una gran cantidad de conexiones distribuidas a un recurso compartido, como por ejemplo una base de datos. El sistema de mensajería puede emplear recursos redundantes para proporcionar alta disponibilidad, equilibrar la carga, redirigir conexiones de red fallidas y ajustar desempeño y calidad del servicio. • Gestión de Hilos. La comunicación asincrónica significa que una aplicación no tendrá que bloquear mientras espera que otra aplicación realice una tarea, a menos que así lo desee. En lugar de bloquear para esperar una respuesta, la persona que llama puede usar una devolución de llamada que alertará al persona que llama cuando llegue la respuesta. (Consulte el patrón Solicitud-Respuesta). Una gran cantidad de mensajes bloqueados Los hilos, o los hilos bloqueados durante mucho tiempo, pueden ser problemáticos. Demasiados bloqueados Los subprocesos pueden dejar la aplicación con muy pocos subprocesos disponibles para realizar un trabajo real. Si una aplicación con algún número dinámico de subprocesos bloqueados falla, cuando el La aplicación se reinicia y recupera su estado anterior, restablecer esos subprocesos será difícil. Con las devoluciones de llamada, los únicos subprocesos que se bloquean son un número pequeño y conocido de oyentes esperando respuestas. Esto deja la mayoría de los hilos disponibles para otros trabajos y define un número conocido de subprocesos de escucha que pueden restablecerse fácilmente después de un fallo. Por lo tanto, existen varias razones diferentes por las que una aplicación o empresa puede beneficiarse de mensajería. Algunos de estos son detalles técnicos con los que los desarrolladores de aplicaciones se identifican más fácilmente, mientras que otras son decisiones estratégicas que resuenan mejor entre los arquitectos empresariales. Cual de estos Las razones más importantes dependen de los requisitos actuales de sus aplicaciones particulares. Todas son buenas razones para utilizar la mensajería, así que aproveche las razones que le proporcionen la mayor beneficio para usted.

Desafíos de la mensajería asincrónica La mensajería asincrónica no es la panacea de la integración. Resuelve muchos de los desafíos de integrar sistemas dispares de una manera elegante pero también introduce nuevos desafíos. Algunos de Estos desafíos son inherentes al modelo asincrónico, mientras que otros desafíos varían según el modelo. Implementación específica de un sistema de mensajería. • Modelo de programación complejo. La mensajería asincrónica requiere que los desarrolladores trabajen con Un modelo de programación basado en eventos. La lógica de la aplicación ya no se puede codificar en un método único que invoca otros métodos, pero la lógica no se divide en una serie de Controladores de eventos que responden a los mensajes entrantes. Un sistema de este tipo es más complejo y más difícil de desarrollar y depurar. Por ejemplo, el equivalente de una llamada a un método simple puede requieren un mensaje de solicitud y un canal de solicitud, un mensaje de respuesta y un canal de respuesta, un identificador de correlación y una cola de mensajes no válidos (como se describe en Solicitud-Respuesta). • Problemas de secuencia. Los canales de mensajes garantizan la entrega de mensajes, pero no garantizan cuándo se entregará el mensaje. Esto puede provocar que los mensajes que se envían en secuencia salirse de la secuencia. En situaciones en las que los mensajes dependen unos de otros, se ha tenido especial cuidado medidas a tomar para restablecer la secuencia del mensaje. • Escenarios sincrónicos. No todas las aplicaciones pueden funcionar en modo enviar y olvidar. Si un usuario está buscando boletos de avión, querrá ver el precio del boleto de inmediato, no después de un tiempo indeterminado. Por lo tanto, muchos sistemas de mensajería necesitan unir la brecha entre soluciones sincrónicas y asincrónicas. (Ver la Solicitud-Respuesta patrón.) • Actuación. Los sistemas de mensajería añaden algunos gastos generales a la comunicación. requiere esfuerzo convertir datos en un mensaje y enviarlo, y recibir un mensaje y procesarlo. Si usted tener que transportar una gran cantidad de datos, dividirlos en millones de piezas pequeñas puede no ser ser una idea inteligente. Por ejemplo, si una solución de integración necesita sincronizar información entre dos sistemas existentes, el primer paso suele ser replicar toda la información relevante de un sistema a otro. Para tal paso de replicación masiva de datos, ETL (extraer, transformar y cargar) las herramientas son mucho más eficientes que la mensajería. Lo mejor es enviar mensajes Adecuado para mantener los sistemas sincronizados después de la replicación de datos inicial. • Soporte de plataforma limitado. Muchos sistemas de mensajería propietarios no están disponibles en todos plataformas. Muchas veces es más fácil enviar un archivo por FTP a otra plataforma que acceder a él a través de un sistema de mensajería. • Dependencia de un proveedor. Muchas implementaciones de sistemas de mensajería se basan en protocolos propietarios. Incluso las especificaciones de mensajería comunes, como JMS, no controlan el contenido físico. implementación de la solución. Como resultado, los diferentes sistemas de mensajería generalmente no conectarse entre sí. Esto puede plantearle un desafío de integración completamente nuevo: integrando múltiples soluciones de integración! (Consulte el patrón Puente de mensajería). Por lo tanto, la mensajería asincrónica no resuelve todos los problemas e incluso puede crear algunos nuevos. Tenga en cuenta estas consecuencias al decidir qué problemas resolver mediante la mensajería

Pensando asincrónicamente La mensajería es una tecnología asincrónica que permite volver a intentar la entrega hasta que se realiza correctamente. Por el contrario, la mayoría de las aplicaciones utilizan llamadas a funciones síncronas; por ejemplo: un procedimiento que llama a un subprocedimiento, un método que llama a otro método, o un procedimiento que invoca a otro de forma remota a través de una llamada a procedimiento remoto (RPC) (como CORBA y DCOM). Las llamadas sincrónicas implican que el proceso de llamada se detiene mientras el subproceso está ejecutando una función. Incluso en un RPC escenario, donde el subprocedimiento llamado se ejecuta en un proceso diferente, la persona que llama bloquea hasta el subprocedimiento devuelve el control (y los resultados) a la persona que llama. Cuando se usa asíncrono mensajería, la persona que llama utiliza un enfoque de enviar y olvidar que le permite continuar ejecutándose después de envía el mensaje. Como resultado, el procedimiento de llamada continúa ejecutándose mientras el subprocedimiento está siendo invocado.   Semántica de llamadas sincrónicas y asincrónicas La comunicación asincrónica tiene varias implicaciones. Primero, ya no tenemos un solo hilo de ejecución. Varios subprocesos permiten que los subprocedimientos se ejecuten simultáneamente, lo que puede mejorar en gran medida el rendimiento y ayudar a garantizar que algunos subprocesos progresen incluso mientras otros subprocesos pueden estar esperando resultados externos. Sin embargo, los subprocesos simultáneos también pueden dificultar mucho la depuración. En segundo lugar, los resultados (si los hay) llegan mediante una devolución de llamada. Esto permite a la persona que llama realizar otras tareas y recibir una notificación cuando el resultado esté disponible, lo que puede mejorar el rendimiento. Sin embargo, la persona que llama debe poder procesar el resultado incluso mientras está realizando otras tareas, y debe poder utilizar el resultado para recordar el contexto en el que se realizó la llamada. En tercer lugar, los subprocesos asincrónicos se pueden ejecutar en cualquier orden. Nuevamente, esto permite que un subprocedimiento avance incluso mientras que otro no puede hacerlo. Pero también significa que los subprocesos deben poder ejecutarse de forma independiente en cualquier orden, y la persona que llama debe poder determinar qué resultado proviene de qué subproceso y combinar los resultados. Por tanto, la comunicación asincrónica tiene varias ventajas, pero requiere repensar cómo un procedimiento utiliza sus subprocedimientos. Aplicaciones distribuidas versus integración Este libro trata sobre la integración empresarial: cómo integrar aplicaciones independientes para que puedan trabajar juntas. Una aplicación empresarial a menudo incorpora una arquitectura de n niveles (una Semántica de llamadas sincrónicas y asincrónicas La comunicación asincrónica tiene varias implicaciones. Primero, ya no tenemos un solo hilo de ejecución. Varios subprocesos permiten que los subprocedimientos se ejecuten simultáneamente, lo que puede mejorar en gran medida el rendimiento y ayudar a garantizar que algunos subprocesos progresen incluso mientras otros subprocesos pueden estar esperando resultados externos. Sin embargo, los subprocesos simultáneos también pueden dificultar mucho la depuración. En segundo lugar, los resultados (si los hay) llegan mediante una devolución de llamada. Esto permite a la persona que llama realizar otras tareas y recibir una notificación cuando el resultado esté disponible, lo que puede mejorar el rendimiento. Sin embargo, la persona que llama debe poder procesar el resultado incluso mientras está realizando otras tareas, y debe poder utilizar el resultado para recordar el contexto en el que se realizó la llamada. En tercer lugar, los subprocesos asincrónicos se pueden ejecutar en cualquier orden. Nuevamente, esto permite que un subprocedimiento avance incluso mientras que otro no puede hacerlo. Pero también significa que los subprocesos deben poder ejecutarse de forma independiente en cualquier orden, y la persona que llama debe poder determinar qué resultado proviene de qué subproceso y combinar los resultados. Por tanto, la comunicación asincrónica tiene varias ventajas, pero requiere repensar cómo un procedimiento utiliza sus subprocedimientos. Aplicaciones distribuidas versus integración Este libro trata sobre la integración empresarial: cómo integrar aplicaciones independientes para que puedan trabajar juntas. Una aplicación empresarial a menudo incorpora una arquitectura de n niveles (una