PATRONES DE INTEGRACIÓN EMPRESARIALES

Las aplicaciones importantes rara vez viven en aislamiento. Si tu aplicación de ventas debe

interactuar con tu aplicación de inventarios, tu aplicación de adquisiciones debe conectarse a un

sitio de subastas, o el calendario de tu PDA debe sincronizarse con el servidor del calendario

corporativo, da la impresión como que cualquier aplicación puede mejorarse integrándola con

otras aplicaciones.

Todas las soluciones de integración tienen que tratar con algunos retos fundamentales:

Redes inalcanzables.

Redes lentas.

Algún par de aplicaciones son distintas

El cambio es inevitable.

A través del tiempo los desarrolladores han superado estos retos con cuatro principales enfoques:

Transferencia de Archivos.- Una aplicación escribe un archivo que otra lee posteriormente.

Las aplicaciones necesitan concordar en el nombre del archivo y su ubicación, su formato,

el momento en que será escrito y leído, y quién eliminará el archivo.

Base de Datos Compartida.- Múltiples aplicaciones comparten el mismo esquema de base

de datos, ubicado en una sola base de datos física. Debido a que no hay almacenamiento

de datos duplicado, ningún dato tiene que ser transferido de una aplicación a otra. Como

apunte, puede utilizarse un usuario con permisos de lectura/escritura y uno o dos para

ejecución de sentencias únicamente, para las aplicaciones.

Invocación de Procedimientos Remotos.- Una de las aplicaciones expone algunas de sus

funcionalidades de forma que puede ser accesada de forma remota por otras aplicaciones

como un procedimiento remoto. La comunicación ocurre en tiempo real y de forma

síncrona.

Mensajería.- Una aplicación publica un mensaje a un canal de mensajería común. Otras

aplicaciones pueden leer el mensaje del canal en momento posteri or. Las aplicacione

deben concordar en el canal así como en el formato del mensaje . La comunicación es

asíncrona.

Mientras los cuatro enfoques esencialmente resuelven el mismo problema, cada estilo tiene sus

ventajas y desventajas distintas. De hecho, las aplicaciones pueden integrarse usando varios

estilos de forma que cada punto de integración tome ventaja del estilo que mejor se le ajuste.

¿Qué es la Mensajería?

Piensa de la mensajería como un sistema telefónico, el cual cuente con buzón de voz.

Mensajería es una tecnología que permite la comunicación de alta velocidad, asíncrona, programa

a programa con entrega confiable. Los programas se comunican enviando paquetes de datos

llamados mensajes de uno a otro. Los canales, también conocidos como colas, son vías que

conectan los programas y transmiten mensajes. Un canal se comporta como una colección o

arreglo de mensajes, pero uno que es mágicamente compartido a través de múltiples

computadoras y puede ser usado de forma concurrente por diversas aplicaciones. Un emisor o

productor es un programa que envía un mensaje a un canal. Un receptor o consumidor es un

programa que recibe un mensaje leyéndolo (y elimándolo) de un canal.

El mismo mensaje es simplemente algún orden de estructura de datos –como lo es una cadena, un

array de bytes, un registro, o un objeto. Puede ser interpretado simplemente como dato, como la

descripción de un comando para ser invocado en el receptor, o como la descripción de un evento

que ocurrió en el emisor. Un mensaje realmente contiene dos partes, un header y un body. El

header contiene meta-información sobre el mensaje –quién lo envió, a dónde va, etc.; esta

información es usada por el sistema de mensajería, y en su mayoría es ignorada (no siempre), por

las aplicaciones que usan los mensajes. El body contiene los mensajes que están siendo

transmitidos y es ignorado por el sistema de mensajería. En conversación, cuando un desarrollador

de aplicaciones quien está usando mensajería habla sobre un mensaje, generalmente se está

refiriendo a los datos en el body del mensaje.

Las arquitecturas de mensajería asíncrona son poderosas, pero nos requieren que pensemos bien

nuestro enfoque de desarrollo. Relativamente pocos desarrolladores han estado expuestos a

sistemas de mensajes y mensajería. Como resultado de esto, en general los desarrolladores de

aplicaciones no están tan familiarizados con los idiomas y peculiaridades de esta plataforma de

comunicaciones.

¿Qué es un Sistema de Mensajería?

Las capacidades de mensajería son usualmente provistas por un sistema de software separado

llamado un Sistema de Mensajería o Middleware Orientado a Mensajes (MOM). Un sistema de

mensajería maneja la mensajería de la forma en que un sistema de base de datos maneja la

persistencia de los datos. De la forma como un administrador debe llenar 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 rutas de comunicación entre las aplicaciones. El sistema

de mensajería entonces coordina y administra el envío y recepción de mensajes. El propósito

principal de una base de datos es asegurarse que cada registro de datos es persistido de forma

segura, y de forma análoga la tarea principal de un sistema de mensajería es mover mensajes

desde la computadora emisora en una forma confiable.

La razón por la que un sistema de mensajería es necesario para mover mensajes desde una

computadora a otra es que las computadoras y las redes que las conectan son inherentemente

inalcanzables. Sólo porque una aplicación esté lista para enviar una comunicación no significa que

la otra aplicación esté lista para recibirla. Aún si ambas aplicaciones están listas, la red puede no

estar funcionando, o puede fallar para transmitir los datos de forma apropiada. Un sistema de

mensajería supera estas limitaciones intentando repetidamente transmitir los mensajes hasta que

tenga éxito. Bajo circusntancias ideales, el mensaje es transmitido existosamente en el primer

intento, pero frecuentemente las circunstancias no son ideales.

Resumidamente, los mensajes son transmitidos en cinco pasos:

1. Crear.- El emisor crea el mensaje y lo llena con datos.

2. Enviar.- El emisor agrega el mensaje a un canal.

3. Entregar.- El sistema de mensajería mueve el mensaje desde la computadora emisora a la

computadora receptora, volviéndola disponible al receptor.

4. Recibir.- El receptor lee el mensaje desde el canal.

5. Procesar.- El receptor extrae los datos del mensaje.

El siguiente diagrama ilustra los cinco pasos del proceso de transmisión, qué computadoras

ejecutan cada uno, y qué pasos involucra el sistema de mensajería:

Este diagrama también ilustra dos conceptos importantes de mensajería:

1. Send and Forget (Envía y Olvida).- En el paso 2 la aplicación emisora envía el mensaje al

canal de mensajería. Una vez que el envío está completo, el emisor puede dedicarse a otra

labor mientras el sistema de mensajería transmite el mensaje en segundo plano. El emisor

puede estar seguro que el receptor eventualmente recibirá el mensaje y no tiene que

esperar hasta que suceda.

2. Store and Forward (Almacena y Reenvía).- En el paso dos, cuando la aplicación emisora

envía el mensaje al canal de mensaje, el sistema de mensajería almacena el mensaje e n la

computadora del emisor, ya sea en memoria o en disco. En el paso 3, el sistema de

mensajería entrega el mensaje reenviándolo desde la computadora emisora a la

computadora receptora y luego almacena el mensaje otra vez en la computadora

receptora. Este proceso de almacena y reenvía puede ser repetido muchas veces, ya que

el mensaje es movido de una computadora a otra, hasta que alcance la computadora

receptora.

¿Por qué usar Mensajería?

Ahora que sabemos lo que es la mensajería, debemos preguntarnos: ¿por qué usar mensajería?

Como con cualquier solución sofisticada, no hay una sola respuesta. La respuesta rápida es que la

mensajería es más inmediata que la Transferencia de Archivos, mejor encapsulada que la Base de

Datos Compartida, y más confiable que la Invocación de Procedimientos Remotos. Sin embargo,

eso es sólo el inicio de las ventajas que pueden ser obtenidas usando mensajería.

Los beneficios específicos de la mensajería incluyen:

Comunicación Remota

Integración de Lenguaje/Plataforma

Comunicación Asíncrona

Timing Variable

Throttling (Limitación)

Comunicación Confiable

Operación Desconectada

Mediación

Gestión de Threads

¿Por qué usar Mensajería?

La mensajería asíncrona no es la panacea de la integración. Resuelve muchos de los retos de

integrar aplicaciones dispares en una forma elegante pero también introduce nuevos retos.

Algunos de estos retos son inherentes en el modelo asíncrono mientras que otros retos pueden

variar con la implementación específica de un sistema de mensajería.

Modelo de programación compleja.- La mensajería asíncrona requiere que los

desarrolladores trabajen con un modelo de programación manejado por eventos. La lógica

de la aplicación puede ya no ser codificada en un sólo método que involucra a otros

métodos, pero la lógica no es dividida en un número de manejadores de eventos que

responden a los mensajes entrantes. Tal sistema es más complejo y más difícil de manejar

y debuguear. Por ejemplo, el equivalente de la llamada a un sólo método puede requerir

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 inválidos (como lo

describe el Request-Reply)

Issues de Secuencia.- Los canales de mensajes garantizan la entrega de mensajes, pero no

garantizan cuando el mensaje se entregará. Esto puede causar que los mensajes sean

enviados en secuencia para terminar la secuencia. En situaciones en donde los mensajes

dependen uno de otro, tiene que tenerse cuidado especial para restablecer la secuencia

del mensaje.

Escenarios Síncronos.- No todas las aplicaciones pueden operar en un modo enviar y

olvidar. Si un usuario está buscando boletos de una línea aérea, él o ella va a querer ver el

precio del boleto enseguida, no después de algún tiempo indeterminado. Por lo tanto,

muchos sistemas de mensajería necesitan cerrar la brecha entre las soluciones síncronas y

asíncronas.

Performance.- Los sistemas de mensajería agregan alguna sobrecarga a la comunicación.

Toma esfuerzo meter datos en un mensaje y enviarlos y recibir un mensaje y procesarlo. Si

tienes que transportar un trozo de datos completo, dividirlo en ncientas pequeñas piezas

puede no ser inteligente. Por ejemplo, si una solución de integración necesita sincronizar

información entre dos sistemas existentes, el primer paso generalmente es replicar toda la

información relevante de un sistema a otro. Para tal replicación de datos masiva, las

herramientas ETL (Extract, Transform y Load) son mucho más eficientes que la mensajería.

La mensajería es más adecuada para mantener los sistemas en sincronía después de la

replicación de datos inicial.

Soporte Limitado de la Plataforma.- Muchos sistemas de mensajería propietarios no

están disponibles en todas las plataformas. Muchas veces es más fáci l enviar a FTP un

archivo a otra plataforma que accesarlo vía mensajería.

Bloquedo del Proveedor.- Muchas implementaciones de sistemas de mensajería confían

en protocolos propietarios. Aunque las especificaciones comunes de mensajería como lo

es JMS no controlan la implementación física de la solución. Como resultado,

generalmente diferentes sistemas de mensajería no se conectan entre ellos. Esto puede

dejarte con un nuevo gran reto de integración: integrar múltiples soluciones de

integración.

De esta forma, la mensajería asíncrona no resuelve todos los problemas, y aún puede generar

nuevos. Mantén en mente estas consecuencias cuando decidas qué problemas resolver usando

mensajería.

Pensando Asíncronamente

La mensajería es una tecnología asíncrona la cual permite que la entrega sea reintentada hasta

que tenga éxito. En contraste, la mayoría de las aplicaciones usan llamadas de funciones síncronas;

por ejemplo: un procedimiento llamando a un subprocedimiento, un método llamando a otro

método, o un procedimiento invocando a otro remotamente a través de una llamada a

procedimiento remoto (RPC) (como lo son CORBA o DCOM). Las llamadas síncronas implican que

el proceso llamante es detenido mientras el subproceso está ejecutando una función. Aún en un

escenario RPC, donde las llamadas a subprocesos se ejecutan en un proceso diferente, el llamante

se bloquea hasta que el subprocedimiento retorna el control (y el resultado) al llamante. Cuando

se usa mensajería asíncrona, el llamante utiliza un enfoque send and forget que le permite

continuar para ejecutar después de que envíe el mensaje . Como resultado, el procedimiento

llamante continúa su ejecución mientras el subprocedimiento está siendo invocado.

La comunicación asíncrona tiene varias implicaciones. Primero, ya no tenemos un sólo thread de

ejecución. Varios threads se habilitan para que los subprocedimientos corran de forma

concurrente, lo cual puede mejorar el performance en gran medida y ayudar a asegurar que

algunos subprocesos estén progresando aún mientras otros subprocesos pueden estar esperando

resultados externos. Sin embargo, los threads concurrentes también pueden hacer el debugging

mucho más difícil. Segundo, los resultados (si los hay) llegan vía una callback. Esto le permite al

llamante ejecutar otras tareas y ser notificado cuando el resultado esté disponible , lo cual puede

mejorar el performance. Sin embargo, el llamante tiene que ser capaz de procesar el resultado aún

mientras está en medio de otras tareas, y tiene que ser capaz de usar el resultado para recordar el

contexto en el cual fue hecha la llamada. Tercero, los subprocesos asíncronos pueden ejecutarse

en cualquier orden. Otras vez, esto permite que un subprocedimiento progrese aún mientras otro

no pueda. Pero también significa que los subprocesos deben ser capaces de correr de forma

independiente en cualquier orden, y el llamante debe ser capaz de determinar qué resultado vino

de qué subproceso y combinar los resultados en conjunto. De esta forma, la comunicación

asíncrona tiene varias ventajas pero requiere pensar muy bien cómo un procedimiento usará los

subrocedimientos.

Aplicaciones Distribuidas VS Integración

Esta serie es sobre la integración de empresarial – cómo se integran aplicaciones independientes

de forma que puedan trabajar juntas. Una aplicación empresarial frecuentemente incorpora una

arquitectura de n-capas (una versión más sofisticada de la arquitectura cliente/servidor)

permitiéndole estar distribuida a través de varias computadoras. Aunque esto da como resultado

procesos en diferentes máquinas comunicándose una con otra, esto es distribución de aplicación,

no integración de aplicación.

¿Por qué es una arquitectura de n-capas considerada distribución de aplicaciones y no integración

de aplicaciones? Primero, las partes de comunicación son altamente acopladas –dependen

directamente una de otra, de forma que una capa no puede funcionar sin las otras. Segundo, la

comunicación entre las capas tiende a ser síncrona. Tercero, una aplicación (de n-capas o atómica)

puede a tener usuarios humanos que sólo aceptarán una respuesta rápida del sistema.

En contraste, las aplicaciones integradas son aplicaciones independientes que pueden correr por sí

mismas cada una, pero se coordinan una con otra en una forma débilmente acoplada. Esto

permite que cada aplicación se enfoque en un conjunto comprensivo de f uncionalidad y aún

delegue a otras aplicaciones por funcionalidad relacionada. Las aplicaciones integradas

comunicándose de forma asíncrona no tienen que esperar una respuesta; ellas proceden sin una

respuesta o ejecutan otras tareas de forma concurrente hasta que la respuesta esté disponible.

Las aplicaciones integradas tienden a tener restricciones abiertas de tiempo, de forma que puedan

trabajar en otras tareas concurrentemente hasta que un resultado llegue a estar disponible, y por

lo tanto son más pacientes que la mayoría de los usuarios humanos que están esperando en

tiempo real un resultado.

Sistemas de Mensajería Comerciales

Los beneficios aparentes de integrar sistemas usando una solución de mensajería asíncrona han

abierto un mercado significativo para los proveedores de software que crean middleware de

mensajería y herramientas asociadas. Podemos agrupar de groso modo los productos de

proveedores de mensajería en las siguientes cuatro categorías:

1. Sistemas Operativos.- La mensajería ha llegado a ser una necesidad común que los

proveedores han comenzado a integrar la infraestructura de software necesaria en el

sistema operativo o plataforma de base de datos. Por ejemplo, los sistemas operativos

Windows 2000 Server, 2003, 2008, y posteriores, incluyen el software de servicio

Microsoft Messager Queuing (MSMQ). Este servicio es accesible a través de un número de

APIs, incluyendo componentes COM y el namespace System.Messaging, parte de la

plataforma .NET. De forma similar Oracle ofrece Oracle AQ como parte de su plataforma

de base de datos

2. Servidores de Aplicaciones.- Prrimeramente Sun Microsystems incorporó el Jav Messaging

Service (JMS) en la versión 1.2 de la especificación J2EE. Desde entonces, virtualmente

todos los servidores de aplicaciones (IBM WebSphere, Oracle Weblogic, etc.) proporcionan

una implementación para esta especificación. Además, Sun entrega una implementación

de referencia de JMS con el JDK J2EE.

3. Suites EAI.- Los productos de estos proveedores ofrecen suites propietarias –pero ricas en

funcionalidad- que incluyen mensajería, automatización de procesos de negocios,

workflow, portales, y otras funciones. Los jugadores clave en este mercado son IBM

WebSphere MQ, Oracle, Microsoft BizTalk, TIBCO, WebMethods, SeeBeyond,

CrossWorlds, entre otros. Muchos de estos productos incluyen a JMS como uno de las

muchas APIs clientes que soportan, mientras otros proveedores –como SonicSoftware y

Fiorano- se enfocan principalmente en implementar infraestructuras de mensajería que

cumplen con JMS.

4. Toolkits de Web Services.- Los web services han ganado terreno de interés en las

comunidades de integración empresarial. Los cuerpos de estándares y consorcios están

trabajando activamente en estandarizar la entrega de mensajes confiables sobre web

services (especificaciones WS-). Un número creciente de proveedores ofrecen

herramientas que implementan enrutamiento, transformación y administración de

soluciones basadas en web services.

Los patrones mencionados aquí son independientes de los proveedores y aplican a la mayoría de

las soluciones mensajería. Desafortunadamente cada proveedor tiende a definir su propia

terminología cuando describe soluciones de mensajería.

Muchos proveedores de mensajería han incorporado algunos de los patrones mencionados en

esta obra como carácterísticas de sus productos, lo cual simplifica la aplicación de los patrones y

acelera el desarrollo de la solución. Para ayudar a los lectores a mapear el lenguaje de patrones a

terminología específica de los proveedores, se proporciona la siguiente tabla que mapea los

nombres de patrones más comunes a sus correspondientes nombres de característica del

producto en algunos de los productos de mensajería más ampliamente usados.

Patrones de Integración Empresarial

Java Message Service (JMS)

Microsoft MSMQ WebSphere MQ

Message Channel Destination Message Queue Queue

Point to Point Channel Queue Message Queue Queue

Publish-Subscribe-Channnel

Topic ------- ------------

Message Message Message Message

Message EndPoint Message Producer, Message Consumer

Patrones de Integración Empresarial

TIBCO WebMethods SeeBeyond Vitria

Message Channel Topic Intelligent Queue Channel

Point to Point Channel

Distributed Queue Intelligent Queue Channel

Publish-Subscribe-Channnel

Subjet ------- Intelligent Queue Pub/Sub Channel

Message Message Document Event Event Message EndPoint Publisher,

Subscriber Publisher, Subscriber

Publisher, Subscriber

Publisher, Subscriber

Bibliografía

1. Hophe, Gregor y Bobby Wolf. Enterprise Integration Patterns – Designing, Building and

Deploying Messaging Solutions

2. Imágenes extraídas de Google.

3. Con la ayuda de Google Traductor para frases difíciles.

No se te olvide regalarme un like en mi página de facebook: JavaDevelopersMexico

(https://www.facebook.com/JavaDevelopersMexico), donde podrás encontrar otros temas de tu

interés.

MDP. ABIMAEL DESALES LÓPEZ