SlideShare une entreprise Scribd logo
1  sur  12
Télécharger pour lire hors ligne
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

Contenu connexe

Tendances

Diagramas de componentes exposicion martes
Diagramas de componentes exposicion  martesDiagramas de componentes exposicion  martes
Diagramas de componentes exposicion martes
Jackson Marshelo
 
Aplicaciones Distribuídas
Aplicaciones DistribuídasAplicaciones Distribuídas
Aplicaciones Distribuídas
Javierialv
 
14 Clase Flujo De AnáLisis Ii
14 Clase Flujo De AnáLisis Ii14 Clase Flujo De AnáLisis Ii
14 Clase Flujo De AnáLisis Ii
Julio Pari
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
antonio
 
Desarrollo de software basado en lineas de productos
Desarrollo de software basado en lineas de productosDesarrollo de software basado en lineas de productos
Desarrollo de software basado en lineas de productos
JOSEPHPC3000
 

Tendances (20)

Diagramas de componentes exposicion martes
Diagramas de componentes exposicion  martesDiagramas de componentes exposicion  martes
Diagramas de componentes exposicion martes
 
Unidad 2. metodologias de desarrollo de software tema1
Unidad 2. metodologias de desarrollo de software tema1Unidad 2. metodologias de desarrollo de software tema1
Unidad 2. metodologias de desarrollo de software tema1
 
Cuestionario uml
Cuestionario umlCuestionario uml
Cuestionario uml
 
Comprensión de los Requerimientos
Comprensión de los Requerimientos Comprensión de los Requerimientos
Comprensión de los Requerimientos
 
Deployment Diagram Example Templates
Deployment Diagram Example TemplatesDeployment Diagram Example Templates
Deployment Diagram Example Templates
 
Aplicaciones Distribuídas
Aplicaciones DistribuídasAplicaciones Distribuídas
Aplicaciones Distribuídas
 
Analisis y Diseño de Sistemas II-2
Analisis y Diseño de Sistemas II-2Analisis y Diseño de Sistemas II-2
Analisis y Diseño de Sistemas II-2
 
14 Clase Flujo De AnáLisis Ii
14 Clase Flujo De AnáLisis Ii14 Clase Flujo De AnáLisis Ii
14 Clase Flujo De AnáLisis Ii
 
MVC vs MVP
MVC vs MVPMVC vs MVP
MVC vs MVP
 
MoProsoft Presentacion
MoProsoft PresentacionMoProsoft Presentacion
MoProsoft Presentacion
 
Lenguaje Acme
Lenguaje AcmeLenguaje Acme
Lenguaje Acme
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
 
Lenguaje de especificación
Lenguaje de especificaciónLenguaje de especificación
Lenguaje de especificación
 
Sistema distribuido
Sistema distribuidoSistema distribuido
Sistema distribuido
 
Unidad 1. caracterizacion de los sistemas distribuidos
Unidad 1.  caracterizacion de los sistemas distribuidosUnidad 1.  caracterizacion de los sistemas distribuidos
Unidad 1. caracterizacion de los sistemas distribuidos
 
Estilos arquitectónicos
Estilos arquitectónicosEstilos arquitectónicos
Estilos arquitectónicos
 
Desarrollo de software basado en lineas de productos
Desarrollo de software basado en lineas de productosDesarrollo de software basado en lineas de productos
Desarrollo de software basado en lineas de productos
 
IEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de softwareIEEE 1471-2000: Documento de arquitectura de software
IEEE 1471-2000: Documento de arquitectura de software
 
Tipos de arquitecturas de sistemas
Tipos de arquitecturas de sistemasTipos de arquitecturas de sistemas
Tipos de arquitecturas de sistemas
 
Modelo basado en clases
Modelo basado en clasesModelo basado en clases
Modelo basado en clases
 

En vedette

SG 09 Patrones de Integración Empresarial Apache Camel (Draft)
SG 09 Patrones de Integración Empresarial Apache Camel (Draft)SG 09 Patrones de Integración Empresarial Apache Camel (Draft)
SG 09 Patrones de Integración Empresarial Apache Camel (Draft)
Domingo Suarez Torres
 
SG 09 Patrones de Integración Empresarial Apache Camel
SG 09 Patrones de Integración Empresarial Apache CamelSG 09 Patrones de Integración Empresarial Apache Camel
SG 09 Patrones de Integración Empresarial Apache Camel
Domingo Suarez Torres
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
aleja0940
 

En vedette (11)

SG 09 Patrones de Integración Empresarial Apache Camel (Draft)
SG 09 Patrones de Integración Empresarial Apache Camel (Draft)SG 09 Patrones de Integración Empresarial Apache Camel (Draft)
SG 09 Patrones de Integración Empresarial Apache Camel (Draft)
 
Metodologia Integracion de Aplicaciones
Metodologia Integracion de AplicacionesMetodologia Integracion de Aplicaciones
Metodologia Integracion de Aplicaciones
 
SG 09 Patrones de Integración Empresarial Apache Camel
SG 09 Patrones de Integración Empresarial Apache CamelSG 09 Patrones de Integración Empresarial Apache Camel
SG 09 Patrones de Integración Empresarial Apache Camel
 
Integración de Aplicaciones
Integración de AplicacionesIntegración de Aplicaciones
Integración de Aplicaciones
 
Factores de calidad según mc call
Factores de calidad según mc callFactores de calidad según mc call
Factores de calidad según mc call
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
 
Orquestación o coreografía
Orquestación o coreografíaOrquestación o coreografía
Orquestación o coreografía
 
Tema 3 3
Tema 3 3Tema 3 3
Tema 3 3
 
Orquestacion y Coreografia de Servicios Web
Orquestacion y Coreografia de Servicios WebOrquestacion y Coreografia de Servicios Web
Orquestacion y Coreografia de Servicios Web
 
Unidad 2 Integración de Sistemas
Unidad 2   Integración de SistemasUnidad 2   Integración de Sistemas
Unidad 2 Integración de Sistemas
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
 

Similaire à Patrones de Integración Empresariales (20)

Capitulo2
Capitulo2Capitulo2
Capitulo2
 
Capitulo2
Capitulo2Capitulo2
Capitulo2
 
Capitulo 2 comunicacion
Capitulo 2 comunicacionCapitulo 2 comunicacion
Capitulo 2 comunicacion
 
SEMANA 6.pptx
SEMANA 6.pptxSEMANA 6.pptx
SEMANA 6.pptx
 
SISTEMAS DISTRIBUIDOS COMUNICACION UNIDAD 2.pptx
SISTEMAS DISTRIBUIDOS COMUNICACION UNIDAD 2.pptxSISTEMAS DISTRIBUIDOS COMUNICACION UNIDAD 2.pptx
SISTEMAS DISTRIBUIDOS COMUNICACION UNIDAD 2.pptx
 
Introduccion al middleware
Introduccion al middlewareIntroduccion al middleware
Introduccion al middleware
 
C:\fakepath\comunicacion sod
C:\fakepath\comunicacion sodC:\fakepath\comunicacion sod
C:\fakepath\comunicacion sod
 
Segunda tarea kuky
Segunda tarea kukySegunda tarea kuky
Segunda tarea kuky
 
Segunda tarea kuky
Segunda tarea kukySegunda tarea kuky
Segunda tarea kuky
 
Servidores
ServidoresServidores
Servidores
 
Tcp y osi
Tcp y osiTcp y osi
Tcp y osi
 
Trabajo de teleproceso
Trabajo de teleprocesoTrabajo de teleproceso
Trabajo de teleproceso
 
Trabajo de teleproceso
Trabajo de teleprocesoTrabajo de teleproceso
Trabajo de teleproceso
 
resumen del Cap2 de ccna1
resumen del Cap2 de ccna1resumen del Cap2 de ccna1
resumen del Cap2 de ccna1
 
Términos de Programación Distribuida 5
Términos de Programación Distribuida 5Términos de Programación Distribuida 5
Términos de Programación Distribuida 5
 
SERVIDORES_WCR
SERVIDORES_WCRSERVIDORES_WCR
SERVIDORES_WCR
 
Servidores
ServidoresServidores
Servidores
 
SERVIDORES – GNU LINUX
SERVIDORES – GNU LINUXSERVIDORES – GNU LINUX
SERVIDORES – GNU LINUX
 
Ensayo de redes[1]
Ensayo de redes[1]Ensayo de redes[1]
Ensayo de redes[1]
 
07 middleware
07 middleware07 middleware
07 middleware
 

Plus de Abimael Desales López

El mejor enfoque para una arquitectura orientada a servicios
El mejor enfoque para una arquitectura orientada a serviciosEl mejor enfoque para una arquitectura orientada a servicios
El mejor enfoque para una arquitectura orientada a servicios
Abimael Desales López
 

Plus de Abimael Desales López (15)

Aprendiendo AWS Lambda con API Gateway y DynamoDB
Aprendiendo AWS Lambda con API Gateway y DynamoDBAprendiendo AWS Lambda con API Gateway y DynamoDB
Aprendiendo AWS Lambda con API Gateway y DynamoDB
 
Tutorial - Ordenar listas Java
Tutorial   - Ordenar listas JavaTutorial   - Ordenar listas Java
Tutorial - Ordenar listas Java
 
Tareas Programadas de Oracle con Toad 10
Tareas Programadas de Oracle con Toad 10Tareas Programadas de Oracle con Toad 10
Tareas Programadas de Oracle con Toad 10
 
File Processing - Batch Process Execution
File Processing - Batch Process ExecutionFile Processing - Batch Process Execution
File Processing - Batch Process Execution
 
File Processing - Process Execution Solution
File Processing - Process Execution SolutionFile Processing - Process Execution Solution
File Processing - Process Execution Solution
 
Tutorial - REST con java (JAX-RS 2.0)
Tutorial - REST con java (JAX-RS 2.0)Tutorial - REST con java (JAX-RS 2.0)
Tutorial - REST con java (JAX-RS 2.0)
 
Jpa modelos de componentes
Jpa   modelos de componentesJpa   modelos de componentes
Jpa modelos de componentes
 
Integrando sonar
Integrando sonarIntegrando sonar
Integrando sonar
 
Apache Camel - Parte II
Apache Camel - Parte IIApache Camel - Parte II
Apache Camel - Parte II
 
Apache Camel
Apache CamelApache Camel
Apache Camel
 
El mejor enfoque para una arquitectura orientada a servicios
El mejor enfoque para una arquitectura orientada a serviciosEl mejor enfoque para una arquitectura orientada a servicios
El mejor enfoque para una arquitectura orientada a servicios
 
Orquestación de Servicios y SOA
Orquestación de Servicios y SOAOrquestación de Servicios y SOA
Orquestación de Servicios y SOA
 
SOA: Principios de Diseño de Servicios - Parte II
SOA: Principios de Diseño de Servicios - Parte IISOA: Principios de Diseño de Servicios - Parte II
SOA: Principios de Diseño de Servicios - Parte II
 
Analisis ¿No es eso para personas poco inteligentes?
Analisis ¿No es eso para personas poco inteligentes?Analisis ¿No es eso para personas poco inteligentes?
Analisis ¿No es eso para personas poco inteligentes?
 
Conceptos introductorios al diseño de Servicios SOA
Conceptos introductorios al diseño de Servicios SOAConceptos introductorios al diseño de Servicios SOA
Conceptos introductorios al diseño de Servicios SOA
 

Dernier

Modulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdfModulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdf
AnnimoUno1
 
EPA-pdf resultado da prova presencial Uninove
EPA-pdf resultado da prova presencial UninoveEPA-pdf resultado da prova presencial Uninove
EPA-pdf resultado da prova presencial Uninove
FagnerLisboa3
 

Dernier (15)

Modulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdfModulo-Mini Cargador.................pdf
Modulo-Mini Cargador.................pdf
 
Avances tecnológicos del siglo XXI y ejemplos de estos
Avances tecnológicos del siglo XXI y ejemplos de estosAvances tecnológicos del siglo XXI y ejemplos de estos
Avances tecnológicos del siglo XXI y ejemplos de estos
 
Avances tecnológicos del siglo XXI 10-07 eyvana
Avances tecnológicos del siglo XXI 10-07 eyvanaAvances tecnológicos del siglo XXI 10-07 eyvana
Avances tecnológicos del siglo XXI 10-07 eyvana
 
Desarrollo Web Moderno con Svelte 2024.pdf
Desarrollo Web Moderno con Svelte 2024.pdfDesarrollo Web Moderno con Svelte 2024.pdf
Desarrollo Web Moderno con Svelte 2024.pdf
 
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptxPROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
PROYECTO FINAL. Tutorial para publicar en SlideShare.pptx
 
guía de registro de slideshare por Brayan Joseph
guía de registro de slideshare por Brayan Josephguía de registro de slideshare por Brayan Joseph
guía de registro de slideshare por Brayan Joseph
 
presentacion de PowerPoint de la fuente de poder.pptx
presentacion de PowerPoint de la fuente de poder.pptxpresentacion de PowerPoint de la fuente de poder.pptx
presentacion de PowerPoint de la fuente de poder.pptx
 
pruebas unitarias unitarias en java con JUNIT
pruebas unitarias unitarias en java con JUNITpruebas unitarias unitarias en java con JUNIT
pruebas unitarias unitarias en java con JUNIT
 
Refrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdf
Refrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdfRefrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdf
Refrigerador_Inverter_Samsung_Curso_y_Manual_de_Servicio_Español.pdf
 
Global Azure Lima 2024 - Integración de Datos con Microsoft Fabric
Global Azure Lima 2024 - Integración de Datos con Microsoft FabricGlobal Azure Lima 2024 - Integración de Datos con Microsoft Fabric
Global Azure Lima 2024 - Integración de Datos con Microsoft Fabric
 
Presentación guía sencilla en Microsoft Excel.pptx
Presentación guía sencilla en Microsoft Excel.pptxPresentación guía sencilla en Microsoft Excel.pptx
Presentación guía sencilla en Microsoft Excel.pptx
 
EL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptx
EL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptxEL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptx
EL CICLO PRÁCTICO DE UN MOTOR DE CUATRO TIEMPOS.pptx
 
EPA-pdf resultado da prova presencial Uninove
EPA-pdf resultado da prova presencial UninoveEPA-pdf resultado da prova presencial Uninove
EPA-pdf resultado da prova presencial Uninove
 
Trabajo Mas Completo De Excel en clase tecnología
Trabajo Mas Completo De Excel en clase tecnologíaTrabajo Mas Completo De Excel en clase tecnología
Trabajo Mas Completo De Excel en clase tecnología
 
Presentación de elementos de afilado con esmeril
Presentación de elementos de afilado con esmerilPresentación de elementos de afilado con esmeril
Presentación de elementos de afilado con esmeril
 

Patrones de Integración Empresariales

  • 1.
  • 2. 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.
  • 3. 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.
  • 4. ¿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:
  • 5. 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
  • 6.  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
  • 7. 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.
  • 8. 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
  • 9. 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.
  • 10. 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
  • 11. 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.
  • 12. 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