PROYECTO

PATRONES DE MENSAJERIAS
Event-Driven Messaging - Asynchronous Queuing

INTEGRANTES:
 BELTRAN VENTURA JEAN
 DEL PEZO LOAIZA RAÚL
 ESPINOZA BURGOS KERLY
 LABORDE XAVIER
 ORTIZ BRIONES LEYNER
 RAMOS MENOSALVA FREDD
DOCENTE: ING. CHRISTOPHER CRESPO LEÓN

18 DE JUNIO DE 2018
UNIVERSIDAD DE GUAYAQUIL
Curso: 7-3
 Contenido
¿Qué es SOA?......................................................................................................................... 2
¿Qué es un patrón de diseño? ................................................................................................. 2
¿Qué es un Patrón Compuesto? .............................................................................................. 2
¿Qué es un lenguaje de patrón de diseño? .............................................................................. 3
¿Qué es un catálogo de patrón de diseño? .............................................................................. 3
Notación de Patrones .............................................................................................................. 4
Figuras de patrones ................................................................................................................. 4
Figuras de secuencias de aplicaciones de patrones ............................................................. 5
Figuras de relación de patrones........................................................................................... 5
Jerarquía de Patrones Compuestos ..................................................................................... 5
Perfiles de patrones ................................................................................................................. 6
Patrones de Servicio de Mensajería ........................................................................................ 8
Introducción ........................................................................................................................ 8
¿De qué trata estos tipos de patrones? ................................................................................ 8
Event-Driven Messaging ........................................................................................................ 8
Definición ............................................................................................................................... 8
Problema ............................................................................................................................. 8
Solución ............................................................................................................................ 10
Aplicación ......................................................................................................................... 11
Impacto ............................................................................................................................. 11
Relación con otros patrones .............................................................................................. 11
Caso de estudio de ejemplo .............................................................................................. 12
Asynchronous Queuing ........................................................................................................ 13
Problema ........................................................................................................................... 13
Solución ............................................................................................................................ 14
Aplicación ......................................................................................................................... 14
Principios .............................................................................................................................. 16
Impactos ............................................................................................................................ 16
Ventajas ............................................................................................................................ 17
Desventajas ....................................................................................................................... 17
Relaciones............................................................................................................................. 17
Caso de estudio y Patrón esocgido ....................................................................................... 18
Implementación de asynchronuos queuing ....................................................................... 20
Modelo de mensajería básica ............................................................................................ 20
Patron bus de mensaje de WSO2 ...................................................................................... 20
Herramientas Usadas ........................................................................................................ 20
Conclusión ............................................................................................................................ 21
Preguntas: ............................................................................................................................. 22

1
 ¿Qué es SOA?

La Arquitectura Orientada a Servicios (SOA, Service Oriented Architecture) es la estructura

subyacente que permite la comunicación entre varios servicios. La SOA define la interacción
y conexión entre dos entidades, que pudieran ser simplemente el transferir datos, o coordinar
una actividad específica entre servicios.

En este proceso, las interacciones están auto contenidas y ligeramente acopladas, y son por
tanto independientes entre sí.

La arquitectura más simple para un SOA muestra un proveedor de servicios en un lado, y a

un consumidor de servicios en el otro lado, intercambiando las solicitudes y respuesta de
servicios. Huelga decir que los SOA son mucho más exhaustivos en la vida real, y que la
implementación exitosa de un SOA requiere de conocimiento experto.

¿Qué es un patrón de diseño?

Un patrón provee una solución a un problema común, de forma que es estandarizado y

aceptado por la industria.

Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno, así como
la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más
adelante sin tener que volver a pensarla otra vez.

Un patrón de diseño es una descripción de clases y objetos comunicándose entre sí, adaptada
para resolver un problema de diseño general en un contexto particular.

¿Qué es un Patrón Compuesto?

Puede representar un conjunto de patrones que se aplican en conjunto a un programa o

implementación particular para establecer un conjunto específico de características de
diseño. Esto se denominaría aplicación conjunta.

Aunque se clasifica un conjunto de patrones como "patrones compuestos", es importante

tener en cuenta que casi cualquier patrón puede convertirse en un patrón compuesto. Cada
uno de los patrones se puede descomponer en un conjunto de patrones más granulares. Su

2
combinación conjunta o coexistente da como resultado el patrón original, lo que también lo
convierte en un patrón compuesto.

La razón por la cual esta perspectiva es importante es porque si un patrón se etiqueta como
un patrón compuesto siempre es relativo. Solo se trata de la granularidad en la que se
documenta el patrón en relación con otros patrones en el mismo catálogo.

¿Qué es un lenguaje de patrón de diseño?

Así como las palabras deben tener una relación gramática y semántica entre ellas para crear
un lenguaje oral útil, los patrones de diseño deben estar relacionados los unos con los otros
para poder formar un lenguaje de patrones.

Un lenguaje de patrón de diseño es un método estructurado para describir una serie de buenas
prácticas de diseño en un área particular.

Los lenguajes de patrón se utilizan para formalizar los valores de decisiones cuya efectividad
resulta obvia a través de la experiencia, pero que es difícil de documentar y pasar a los
aprendices. También son herramientas útiles a la hora de estructurar el conocimiento y
comprender sistemas complejos sin caer en la simplificación extrema.

Estos procesos incluyen la organización de personas o grupos que tienen que tomar
decisiones complejas, y revelan cómo interactúan las diferentes funciones como parte del
total.

Los patrones deben estar organizados en estructuras lógicas o estructuras intuitivas. La

estructura (jerárquica, iterativa, etc) puede variar, dependiendo del tema. Cada patrón debe
indicar su relación con otros patrones y con el lenguaje en sí.

¿Qué es un catálogo de patrón de diseño?

Un catálogo de patrones de diseño es simplemente una colección documentada de patrones

de diseño relacionados.

3
Un catálogo de patrones de diseño es aquel grupo de patrones que han sido documentados,
utilizados y verificados al menos en tres sistemas diferentes para resolver el mismo problema
pudiendo cumplir su objetivo con éxito.

Notación de Patrones

Una notación simple se usa para representar consistentemente diferentes tipos de patrones.

Figuras de patrones
Se usan en los siguientes tres tipos principales de diagramas:

• Figuras de secuencia de aplicación de patrón

• Figuras de relación de patrón

• Figuras de jerarquía de patrón compuesto

Echemos un vistazo más de cerca a cada uno:

4
Figuras de secuencias de aplicaciones de patrones

Al documentar los lenguajes de patrones de diseño, es útil mostrar la secuencia

sugerida en la que se deben aplicar los patrones.

Las Figura muestran secuencias de aplicaciones de patrones para grupos de

patrones relacionados y para patrones individuales que pertenecen a un grupo
particular, respectivamente.

Figuras de relación de patrones

Como se explica en la próxima sección de Perfiles de patrones, se explora
numerosas relaciones entre patrones y proporciona un diagrama de relaciones de
patrones para cada patrón de diseño documentado.

Jerarquía de Patrones Compuestos

Los patrones compuestos están compuestos de combinaciones de patrones de diseño. Cuando

se ilustra un patrón compuesto, generalmente se requiere una representación jerárquica,

5
donde el nombre del patrón compuesto se muestra en la parte superior, y los patrones que
componen el compuesto se muestran debajo.

Perfiles de patrones

Cada uno de los patrones en este catálogo se describe utilizando el mismo formato y
estructura de perfil en función de las siguientes partes:

 Requisito: Esta es una declaración concisa de una sola oración que presenta el
requisito fundamental abordado por el patrón en forma de pregunta. Cada descripción
de patrón comienza con esta declaración.
 Icono: Cada descripción de patrón va acompañada de una imagen de icono que actúa
como un identificador visual. Los iconos se muestran junto con las declaraciones de
requisitos en cada perfil de patrón.
 Resumen: La tabla de resumen esta compuesta de declaraciones que colectivamente
proporcionan una sinopsis concisa del patrón para fines de referencia rápida
 Problema: El problema que causa un problema y los efectos del problema se
describen en esta sección, generalmente acompañado de una figura que ilustra aún
más el "estado del problema", este es el problema para el cual el patrón proporciona
una solución.

6
 Solución: Esto representa la solución de diseño propuesta por el patrón para resolver
el problema y cumplir con el requisito. A menudo, la solución es una breve
declaración seguida de un diagrama que comunica de forma concisa el estado de
solución final
 Aplicación: Esta parte está dedicada a describir cómo se puede aplicar el patrón.
Puede incluir directrices, detalles de implementación y, a veces, incluso un proceso
sugerido.
 Impactos: La mayoría de los patrones vienen con compensaciones. Esta sección
destaca las consecuencias, los costos y los requisitos comunes asociados con la
aplicación de un patrón. Tenga en cuenta que estas consecuencias son comunes pero
no necesariamente predecibles.
 Relaciones: Esta sección simplemente resalta relaciones comunes con énfasis en
cómo los patrones se apoyan o dependen el uno del otro.
 Caso de Estudio: La mayoría de los perfiles de patrón concluyen con un ejemplo de
caso de estudio que demuestra la aplicación de muestra de un patrón en relación con
los argumentos establecidos previamente.

7
 Patrones de Servicio de Mensajería
Introducción
Los patrones de mensajería son muy interesantes para los programadores, ya que nos ofrecen
soluciones a problemas comunes y cuotidianos a la hora de diseñar una aplicación. Existen
infinidad de casos en que el problema sigue el mismo patrón, solo cambia el contexto; un
patrón de diseño te propone una solución a este tipo de problemas.

La manera de utilizarlos depende de dos factores: comprender correctamente cuando se

pueden usar y tenerlos presentes a la hora de usar estos patrones. Lo primero se consigue
habiéndolos estudiado y puesto en práctica en diferentes contextos. Lo segundo, que también
incluye su dificultad, es la capacidad de encontrarse con un problema, y ser capaz de
relacionarlo con un patrón de diseño que conozcas.

¿De qué trata estos tipos de patrones?

Los patrones por tratar en esta investigación son conocidos en el mundo por su forma de uso
en empresa y la manera en que solucionan problemas el patrón Event – Driven Messaging
solución problemas de mensajería a través de sistema de suscriptores y editores y el patrón
Asynchronous Queuing soluciona problemas a través diseño dedicado a acomodar
intercambios de mensajes y, por lo tanto, está relacionado de forma natural con la mensajería
de servicio. Los agentes impulsados por eventos forman una parte fundamental del marco de
espera, lo que explica la relevancia de Service Agent.

Event-Driven Messaging

Definición
La mensajería impulsada por eventos es un patrón de diseño aplicado dentro del paradigma de diseño
de orientación de servicio para permitir que los consumidores del servicio, interesados en eventos que
ocurren dentro de la periferia de un proveedor de servicios, reciban notificaciones sobre estos eventos
cuando ocurran. sin recurrir al mecanismo tradicional ineficiente basado en sondeo.

Problema
En los entornos típicos de mensajería, los consumidores de servicios pueden elegir entre una
vía y request-response message exchange patterns (MEPs), pero ambos tienen que proceder

8
del consumidor. Los eventos pueden ocurrir dentro de límite funcional del proveedor de
servicios que son de interés para el consumidor. Siguiendo MEPs tradicionales, el
consumidor tendría que sondear continuamente el servicio con el fin de averiguar si se había
producido tal evento (y luego recuperar los detalles de los eventos correspondientes).

Este modelo es ineficiente porque conduce a numerosas invocaciones de servicios y

intercambio de datos innecesario. Puede introducir más retrasos en cuanto a cuando el
consumidor recibe la información del evento, ya que puede ser sólo capaz de comprobar para
el evento a intervalos predeterminados de votación.

9
Solución

Un programa de gestión de eventos se introduce, permitiendo que el consumidor de servicios

se establezca como suscriptor de eventos asociados con un servicio que asume el papel de
editor.

Puede haber diferentes tipos de eventos que el servicio tiene disponibles, y los consumidores
pueden elegir cual les gustaría recibir. Cuando se produce un evento, el servicio (que actúa
como editor) envía automáticamente los detalles del evento en el programa de gestión de
eventos, que a su vez emite una notificación de eventos para todos los consumidores
registrados como suscriptores del evento.

10
Aplicación

Un marco de mensajería basada en eventos se implementa como una extensión del inventario
de servicios.

Plataformas de tiempo de ejecución, middleware de mensajería y productos ESB

comúnmente proporcionan la infraestructura necesaria para el procesamiento de mensajes y
capacidades de seguimiento, junto con agentes de servicio que suministran procesamiento de
eventos complejos, filtrado y correlación.

Impacto

Los intercambios de mensajes basados en eventos no se pueden incorporar fácilmente como

parte de la Transacción del servicio atómico, y pueden surgir problemas de disponibilidad
del editor / suscriptor.

Relación con otros patrones

11
Caso de estudio de ejemplo

El FRC administra una flota de agentes de campo que visitan aserraderos y otros sitios
propiedad de empresas en la industria maderera y forestal. A menudo estas visitas son de
seguimiento en quejas o preocupaciones de los representantes de la compañía. Por ejemplo,
el oficial de campo puede necesitar de ayudar a educar a los operadores de la fábrica sobre
cómo una nueva política de FRC afecta su operación. Sin embargo, a veces los oficiales de
campo también son enviados a realizar inspecciones sorpresa para garantizar que se sigan,
de hecho, ciertas políticas relacionadas con los procedimientos.

Para apoyar mejor a estos oficiales, FRC ha emitido dispositivos móviles que muestran
agenda para un día determinado y cualquier información logística o de contrato relacionada.
Estos dispositivos se desarrollaron a medida, y los arquitectos de FRC tuvieron que tomar
una decisión sobre si debe estar diseñado para sondear periódicamente el sistema central de
programación de FRC para actualizaciones o si se debe usar un mecanismo de empuje en su
lugar. Después de entrevistas con relevantes Personal de FRC (tanto oficiales de campo como
aquellos que mantienen el sistema interno que contiene los datos requeridos por los oficiales),
optaron por el enfoque push.

A pesar de que la rutina de votación periódica hubiera sido menos costosa y consumidora de
tiempo para construir, sus entrevistas revelaron que hay momentos en que el personal interno
necesita enviar mensajes urgentes a los oficiales de campo. Por ejemplo, en caso de un
desastre natural u otro tipo de emergencia. En esta situación, es inaceptable tener que esperar
hasta el dispositivo móvil emite su próximo comando de sondeo; la notificación debe salir
inmediatamente.

Para implementar dicho sistema, los arquitectos de FRC recurren a la mensajería controlada
por eventos, que les permite configurar cada dispositivo móvil como suscriptor de eventos
regidos por un servicio central actuando como editor. Cuando ocurren eventos relevantes, se
transmite un mensaje a todos los oficiales de campo. El sistema además puede distinguir
entre diferentes tipos de suscriptores y mensajes. Los oficiales individuales están suscritos a
su programar, y por lo tanto un oficial solo recibe una actualización cuando cambia la agenda

12
afecta a ese oficial. Sin embargo, otros tipos de mensajes (como los que notifican una
emergencia) se envían automáticamente a todos los suscriptores.

Asynchronous Queuing

Al realizar comunicación síncrona se requiere que la respuesta sea dada inmediatamente, esto
no permite que el usuario y el sistema interactúen de una forma más amigable. Como solución
a este problema se introduce una cola como un buffer intermediario, este recibe mensajes de
solicitud y los envía en nombre de los consumidores. Si el servicio de destino no está
disponible, la cola actúa como almacenamiento temporal y conserva el mensaje.
Problema
Al realizar comunicación síncrona se requiere que la respuesta sea dada inmediatamente, esto
no permite que el usuario y el sistema interactúen de una forma más amigable.

13
Solución
Como solución a este problema se introduce una cola como un buffer intermediario, este
recibe mensajes de solicitud y los envía en nombre de los consumidores. Si el servicio de
destino no está disponible, la cola actúa como almacenamiento temporal y conserva el
mensaje. A continuación, intenta periódicamente retransmitirlo.
Aplicación
Queuing tecnología debe ser incorporado en la arquitectura del entorno, y las tiendas de
respaldo también puede ser necesario.

14
El servicio A envía un mensaje al servicio B, que es interceptado y almacenado por una cola
intermediaria (1). La cola reenvía el mensaje al Servicio B (2), y mientras el Servicio B está
procesando el mensaje, el Servicio A permanece liberado de la memoria (3).

15
Después de completar su procesamiento, el Servicio B emite un mensaje de respuesta al
Servicio A, que también es recibido y almacenado por la cola intermediaria (4). El servicio
A recibe la respuesta (5) y completa el procesamiento de la respuesta, mientras que el servicio
B se desactiva (6).

Principios
 Contrato de servicios estandarizados
 Bajo acoplamiento
 Servicios sin estado
Impactos
Es posible que no se reconozca la entrega exitosa del mensaje y que las transacciones
atómicas no sean posibles.

16
Ventajas
 Permite la automatización de decisiones complejas y la rápida adaptación a los
cambiantes requisitos empresariales
 Un sistema de gestión de reglas de enrutamiento centralizado puede ayudar a aliviar
el riesgo de introducción de posibles fallos.
 Perdida de acoplamiento * Servicios reutilizables
 Composición de servicios
Desventajas
 Puede conducir a servicios más complejos difíciles de diseñar ya que es más
complicado anticipar todos los escenarios posibles en tiempo de ejecución
 Puede que no haya reconocimiento de la entrega de mensajes de éxito * Las
transacciones atómicas pueden no ser posibles.

Relaciones con Ortos Patrones

Asynchronous Queuing es un patrón de diseño dedicado a acomodar intercambios de mensajes y, por
lo tanto, está relacionado de forma natural con la mensajería de servicio. Los agentes impulsados por
eventos forman una parte fundamental del marco de espera, lo que explica la relevancia de Service
Agent. Además, los metadatos de mensajería pueden jugar un rol en cómo los mensajes se procesan,
almacenan o enrutan a través de estos agentes.

17
Las plataformas ESB se basan fundamentalmente en disminuir el acoplamiento entre las diferentes
partes de una solución orientada a servicios, razón por la cual este patrón es una parte central de
Enterprise Service Bus, como se muestra en la figura. Un patrón de diseño opcional asociado con el
ESB es Reliable Messaging, que es un patrón comúnmente aplicado en conjunto con Asynchronous
Queuing. Juntos, estos dos patrones proporcionan extensiones clave de QoS que hacen atractivo el
uso de productos de ESB, especialmente en apoyo de composiciones de servicios complejos.

Caso de estudio y Patrón esocgido

El FRC continúa empleando un entorno heredado integrado para la transferencia de extractos de lotes
de un sistema ERP a un producto de administración de órdenes de compra (POAdmin). El entorno
ERP proporciona una API capaz de generar datos exportados desde su formato CSV nativo a una
estructura XML predefinida. El proveedor también puso a su disposición un servicio web ERP
wrapper para permitir el acceso a los datos extraídos a través de SOAP

Generar los extractos consumía mucho tiempo, especialmente si se solicitaban datos de pedido de
compra para un rango de fechas. Los archivos por lotes también pueden ser muy grandes, lo que
requiere tiempos de transferencia más largos. Como resultado, ha habido una variedad de problemas
de rendimiento debido al hecho de que el programa POAdmin tuvo que permanecer bloqueado y
suspendido mientras esperaba la respuesta de la API ERP, que requería un intercambio síncrono. Esto
también ocasionó el bloqueo ocasional del sistema ya que la solicitud de POAdmin expiraría, lo que
ocasionaría que el programa POAdmin se congelara.

18
También se han producido cortes en la red, lo que provoca interrupciones a mitad de una transferencia.
En esta situación, la transferencia completa debería repetirse. Esto requirió intervención
administrativa frecuente, y la gerencia percibió la solución como frágil e ineficiente. Como se ilustra
en la figura, el equipo del proyecto FRC decide volver a diseñar este entorno para mejorar la fiabilidad
de este intercambio, pero también para proporcionar un acceso más apropiado al entorno ERP para
servicios adicionales que pueden necesitar trabajar con sus datos.

Esta nueva arquitectura introduce una cola para almacenar y luego reenviar todas las solicitudes en
nombre del programa POAdmin. La cola está configurada para emitir una respuesta inmediata a
POAdmin para simular el intercambio síncrono. A continuación, se incorpora un nuevo servicio web
estandarizado para reemplazar el servicio ERP Wrapper anterior. Este nuevo servicio ERP Extract
proporciona una operación unidireccional que simplemente recibe el mensaje de solicitud de la cola.
Luego interactúa con un componente personalizado (también provisto recientemente) que interactúa
con la API de ERP. Una vez que se recibe el extracto, este componente reenvía directamente el
resultado a la cola, que a su vez accede a la API de POAdmin para transmitir el extracto de datos de
la orden de compra.

19
Implementación de asynchronuos queuing

Este patrón fue implementado por WSO2 es una compañía que desarrolla aplicaciones de software
abierto enfocadas en proveer una arquitectura orientada a servicios (SOA) para desarrolladores
profesionales.

La compañía implementa este patrón en la Mensajería asíncrona para microservicios. Las solicitudes
entran en el microservicio de compras a través de HTTP. Si los artículos en existencia caen por debajo
del nivel de reorden, se realiza una solicitud de pedido por medio de JMS al servicio de microservicio
Reordenar. Hay dos colas, Reordenar cola y Reordenar cola de respuesta que se crean en WSO2
Message Broker (MB). Una vez que se recibe la solicitud de reordenar a través de la cola de reorden,
el microservicio Reordenar procesará la solicitud y enviará un mensaje de respuesta de reordenar a la
cola de respuesta a reordenar.

Modelo de mensajería básica

 La mensajería se implementa con un intermediario.
 Los participantes envían mensajes y el intermediario los envían a los destinatarios.
 Dos modelos principales
o Punto a punto: los mensajes se entregan solo una vez y se guardan en una cola desde
la que el consumidor elige uno a la vez
o Publicar / Suscribir: los mensajes se transmiten a muchos consumidores a la vez.

Patron bus de mensaje de WSO2

Herramientas Usadas
La compañía WSO2 para Message Broker (MB) implementa las siguientes herramientas

 Implementa y admite JMS API con AMQP

20
  JMS (Java Message Service)
o Una API estándar de Java para que los programadores manejen la mensajería al
interactuar con un intermediario de mensajes
 AMQP (Advanced Message Queuing Protocol)
o Open Standard para pasar mensajes comerciales entre aplicaciones u organizaciones

Conclusión
 Un servicio puede intercambiar mensajes con sus consumidores a través de un búfer
intermediario, lo que permite que el servicio y los consumidores procesen los mensajes de
forma independiente sin que se bloqueen los recursos. (Abel Del Pezo)
 El patrón Asynchronous Queuing nos permite solucionar el problema del envío de mensajes
asíncronos enviando una solicitud que será recibida por la cola luego esta lo envía para su
extracción de forma independiente permitiendo que los recursos no se boqueen. (Xavier
Laborde)
 La especificación SOAP detalla el formato de los mensajes. También detalla la forma en que
las aplicaciones deben tratar determinados aspectos del mensaje, como los elementos del
“encabezado”, lo que le permitirá crear aplicaciones en las que un mensaje pasa entre
múltiples intermediarios antes de llegar a su destino final. Ahora bien, los patrones como
event driven messaging o cola asíncrona aportan métodos que nos ayudan a optimizar trabajo
y ahorrar recursos de los servidores que mantienen contacto, acotando de que son una
arquitectura abierta y que podemos adaptarla al tipo de problema que deseemos solucionar.
(Kerly Espinoza Burgos)
 La arquitectura orientada a servicio es una estrategia que se diseñó como una solución
a la integración de sistemas, aplicaciones y procesos de negocio. Implementar una
SOA no es implementar un conjunto de servicios web, ni tampoco se trata solamente
de integrar aplicaciones del negocio, sino que el tema de SOA va más allá, SOA debe
integrar los sistemas a los procesos del negocio de forma que se genere una ventaja
competitiva y se convierta en una estrategia de la empresa (Jean Beltrán)
 Los patrones de mensajería son usados para solucionar problemas que inclusive se
presentan en la vida cotidiana en programación pasaría igual ante cualquier problema
no tener una recepción eficiente en mensajería podemos aplicar uno de estos dos
patrones para corregir el problema en esta se estudian dos problemas y se entregan
dos soluciones. (Leyner Ortiz)

21
  Un servicio puede intercambiar mensajes con sus consumidores a través de un búfer
intermediario, lo que permite que el servicio y los consumidores procesen los
mensajes de forma independiente sin que se bloqueen los recursos.
El patrón Asynchronous Queuing nos permite solucionar el problema del envío de
mensajes asíncronos enviando una solicitud que será recibida por la cola luego esta
lo envía para su extracción de forma independiente permitiendo que los recursos no
se boqueen.
La implementación de colas entre servicios actúa como un administrador simple de
mensajería que coloca en bandeja de entrada y salida el mensaje para cada uno de los
suscriptores y/o consumidores de los servicios, logrando de esta manera una respuesta
optima al usuario final en razones de tiempo y recursos. (Fredd Ramos)

Preguntas:
1) ¿Que necesitamos para que nuestro servicio no se colapse o se bloquee al
momento de enviar una petición?
a) Cola de Memoria
b) Cola de procesos
c) Cola de almacenamiento
d) Cola Ascendente

Respuesta: literal A

2) ¿Cuáles son las extensiones claves que proporciona la relación de los patrones
Asynchronous Queuing y Reliable Messaging?

La extensión clave que proporcionan es la Qo2 que hacen atractivo el uso de

productos de ESB, especialmente en apoyo de composiciones de servicios complejos.

3) Contesta:
¿Cuál de los siguientes enunciados es correcto e Incorrecto?
a) Un lenguaje de patrón de diseño es un método estructurado para describir una
serie de buenas prácticas de diseño en un área particular. (v)

22
 b) La arquitectura orientada a servicios es un conjunto de buenas prácticas para
descomponer un sistema informático (f)
c) Los patrones compuestos se representan de forma secuencial (f)
d) Un lenguaje de patrón de diseño es un método estructurado para describir una
serie de buenas prácticas de diseño en un área específica. (f)
e) Los patrones compuestos se representan de forma jerárquica. (v)
4) ¿Qué puede proveer un patrón de diseño al momento de su implementación?
a) Provee solución
b) Provee mensajes
c) Provee herramientas
d) Provee argumentos

Respuesta: literal A

5) Uno de los patrones de diseño asociado con el ESB de manera opcional y que
generalmente es aplicado en conjunto con Asynchronous Queuing es:

a) Enterprise Service Bus

b) Event-Driven Messaging
c) Reliable Messaging
d) Service Broker

Respuesta: literal C

6) Seleccione la respuesta correcta:

El patrón Event-Driven Messaging utiliza mecanismos de:
a) Sondeo
b) Orientación de servicio
c) Orientación de paradigma
d) Sondeo y Orientación de Servicio

Respuesta: literal B

23