PATRONES DE INTEGRACIÓN EMPRESARIALES
Las aplicaciones importantes rara vez viven en aislamiento. Si tu aplicación de ventas debe
interactuarcon tu aplicaciónde 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ésdel tiempolosdesarrolladoreshansuperadoestosretosconcuatroprincipalesenfoques:
 Transferenciade Archivos.-Unaaplicaciónescribe unarchivoque otralee posteriormente.
Las aplicacionesnecesitanconcordarenel 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 DatosCompartida.- Múltiplesaplicaciones compartenel mismoesquema de base
de datos,ubicadoen una sola base de datos física. Debido a que no hay almacenamiento
de datos duplicado,ningúndatotiene 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
funcionalidadesde formaque puede seraccesadade formaremota 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 posterior. Las aplicacione
deben concordar en el canal así como en el formato del mensaje. La comunicación es
asíncrona.
Mientrasloscuatro enfoquesesencialmente 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 esuna tecnologíaque permite lacomunicaciónde altavelocidad,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 mismomensaje essimplemente algúnordende estructurade datos –comoloes una cadena,un
array de bytes,unregistro,oun objeto.Puedeserinterpretadosimplemente como dato, como la
descripciónde uncomandopara serinvocadoen 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ónesusadaporel sistemade mensajería,yen su mayoría es ignorada (no siempre), por
las aplicaciones que usan los mensajes. El body contiene los mensajes que están siendo
transmitidosyesignoradoporel sistemade mensajería.Enconversación,cuandoundesarrollador
de aplicaciones quien está usando mensajería habla sobre un mensaje, generalmente se está
refiriendo a los datos en el body del mensaje.
Las arquitecturasde mensajeríaasíncronasonpoderosas,peronosrequierenque 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
persistenciade 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íaconloscanalesque definenlas rutasde comunicaciónentre lasaplicaciones. 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óloporque unaaplicaciónestélistaparaenviarunacomunicación no significa que
la otra aplicaciónesté 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íasuperaestaslimitaciones intentandorepetidamentetransmitirlosmensajes 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 sistemade mensajeríamueve 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.Unavezque el envíoestá completo,el emisorpuede dedicarse aotra
labormientrasel sistemade mensajeríatransmite el mensaje ensegundoplano. 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íael mensaje al canal de mensaje,el sistemade mensajeríaalmacenael mensaje en 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?
Comocon cualquiersoluciónsofisticada,nohay una sola respuesta. La respuesta rápida es que la
mensajeríaesmásinmediataque laTransferenciade 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
desarrolladorestrabajenconunmodelode programaciónmanejadoporeventos. Laló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
respondenalosmensajesentrantes.Tal sistemaesmáscomplejoymás difícil de manejar
y debuguear. Porejemplo,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.- Loscanalesde mensajesgarantizanlaentregade mensajes, pero no
garantizan cuando el mensaje se entregará. Esto puede causar que los mensajes sean
enviadosensecuencia para terminar la secuencia. En situaciones en donde los mensajes
dependenunode 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 unusuarioestábuscandoboletosde unalíneaaérea,él o ella va a querer ver el
precio del boleto enseguida, no después de algún tiempo indeterminado. Por lo tanto,
muchossistemasde mensajeríanecesitancerrarlabrechaentre lassoluciones síncronas y
asíncronas.
 Performance.- Los sistemas de mensajería agregan alguna sobrecarga a la comunicación.
Toma esfuerzometerdatosenun mensaje yenviarlosyrecibirunmensaje yprocesarlo.Si
tienesque transportaruntrozode datoscompleto,dividirlo en ncientas pequeñas piezas
puede noserinteligente. Porejemplo,si una solución de integración necesita sincronizar
informaciónentre dossistemasexistentes,el primerpasogeneralmenteesreplicartodala
información relevante de un sistema a otro. Para tal replicación de datos masiva, las

herramientasETL(Extract,Transformy Load) sonmucho más eficientesque lamensajerí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ácil 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
enprotocolospropietarios.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. Encontraste,lamayoría de lasaplicacionesusanllamadasde funcionessí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
procedimientoremoto (RPC) (como lo son CORBA o DCOM). Las llamadas síncronas implican que
el procesollamante esdetenido mientras el subproceso está ejecutando una función. Aún en un
escenarioRPC,donde lasllamadasasubprocesosse ejecutanenunprocesodiferente,el llamante
se bloqueahastaque el subprocedimientoretorna 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ónasíncronatiene 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
algunossubprocesosesténprogresando aúnmientrasotrossubprocesospueden estar esperando
resultadosexternos. 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 ejecutarotrastareasyser notificadocuandoel resultado esté disponible, lo cual puede
mejorarel performance. Sinembargo,el llamante tiene que sercapazde procesarel resultadoaún
mientrasestáenmedio de otrastareas,y tiene que sercapaz de usar el resultado para recordar el
contextoenel cual fue hecha la llamada. Tercero, los subprocesos asíncronos pueden ejecutarse
encualquierorden.Otrasvez,estopermite que unsubprocedimientoprogrese aún mientras otro
no pueda. Pero también significa que los subprocesos deben ser capaces de correr de forma
independienteencualquierorden,yel llamante debesercapazde determinar qué resultado vino
de qué subproceso y combinar los resultados en conjunto. De esta forma, la comunicación
asíncrona tiene variasventajas pero requiere pensar muy bien cómo un procedimiento usará los
subrocedimientos.
Aplicaciones Distribuidas VS Integración
Esta serie essobre laintegraciónde 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 estardistribuidaatravés de varias computadoras. Aunque esto da como resultado
procesosendiferentesmáquinascomunicándose unaconotra,esto es distribución de aplicación,
no integración de aplicación.
¿Por qué esuna arquitecturade n-capasconsideradadistribuciónde aplicacionesy 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ónentre lascapastiende aser síncrona. Tercero,una aplicación(de n-capaso atómica)
puede a tener usuarios humanos que sólo aceptarán una respuesta rápida del sistema.
En contraste,lasaplicacionesintegradassonaplicacionesindependientesque puedencorrerpor 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 funcionalidad y aún
delegue a otras aplicaciones por funcionalidad relacionada. Las aplicaciones integradas
comunicándose de formaasí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 aplicacionesintegradastiendenatenerrestriccionesabiertasde tiempo,de formaque puedan
trabajar enotras tareasconcurrentemente hastaque un resultadollegue 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
MicrosoftMessagerQueuing(MSMQ).Este servicioesaccesible atravésde 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 SunMicrosystemsincorporóel JavMessaging
Service (JMS) en la versión 1.2 de la especificación J2EE. Desde entonces, virtualmente
todoslosservidoresde aplicaciones(IBMWebSphere,Oracle Weblogic,etc.) proporcionan
una implementaciónparaestaespecificación. Además, Sun entrega una implementación
de referencia de JMS con el JDK J2EE.
3. Suites EAI.- Los productosde estosproveedoresofrecensuitespropietarias –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 patronesmencionadosaquísonindependientes 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
acelerael desarrollode lasolución. Paraayudar 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
Pointto PointChannel 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