Leyendo el libro, "Software Architecture Patterns" les dejo este pequeño resumen:
El patrón arquitectónico Event-Driver se utiliza para crear arquitecturas escalables, se puede utilizar en grandes aplicaciones como en pequeñas.
Este patrón arquitectónico tiene 2 topologías, el mediador y el broker (corredor, como es una fea traducción dejo su nombre en ingles).
La topología del mediador se utiliza comúnmente cuando se necesita orquestar múltiples pasos dentro de un evento a través de un mediador central, mientras que la topología de broker se utiliza cuando se desea encadenar sucesos sin el uso de un mediador central. Debido a que las características de la arquitectura y las estrategias de implementación difieren entre estas dos topologías, es importante entender cada una de ellas para saber cuál es la más adecuada para cada situación particular.
La topología del mediador es útil para eventos que tienen varios pasos y requieren algún nivel de orquestación para procesar el evento.
Hay cuatro tipos principales de componentes de arquitectura dentro de la topología del mediador: colas de eventos, un mediador de eventos, canales de eventos y procesadores de eventos. El flujo de eventos comienza con un cliente que envía un evento a una cola de eventos, que se utiliza para transportar el evento al mediador de eventos. El mediador de eventos recibe el evento inicial y orquesta dicho evento enviando eventos asíncronos adicionales a los canales de eventos para ejecutar cada paso del proceso. Los procesadores de eventos, que escuchan en los canales de eventos, reciben el evento del mediador de eventos y ejecutan lógica empresarial específica para procesar el evento.
La implementación más simple y más común del mediador de eventos es a través de frameworks open source como Spring Integration, Apache Camel o Mule ESB. Los flujos de eventos en estos frameworks se implementan típicamente a través de código Java o un DSL (lenguaje específico de dominio). Para una mediación y una orquestación más sofisticadas, puede utilizar BPEL (lenguaje de ejecución de procesos empresariales) junto con un motor BPEL open source como Apache ODE. BPEL es un lenguaje XML estándar que describe los datos y los pasos necesarios para procesar un evento inicial. Para aplicaciones muy grandes que requieren una orquestación mucho más sofisticada (incluyendo pasos que involucran interacciones humanas), puede implementar el mediador de eventos utilizando un gestor de procesos empresariales (BPM) como jBPM.
La topología broker se diferencia de mediador porque no hay un mediador central y único, sino que el flujo de eventos esta distribuido a través de los componentes del procesador de eventos de una manera similar a una cadena a través de un agente de mensajes ligero (por ejemplo, ActiveMQ, HornetQ, etc.). Esta topología es útil cuando se tiene un flujo de procesamiento de eventos relativamente simple y no desea (o necesita) orquestación de eventos centrales.
Hay dos tipos principales de componentes de arquitectura dentro de la topología de intermediario: un componente de broker y un componente de procesador de sucesos. El componente de broker puede centralizarse o federarse y contiene todos los canales de eventos que se utilizan en el flujo de eventos.
El patrón de arquitectura event-driver es un patrón relativamente complejo de implementar, principalmente debido a su naturaleza asincrónica distribuida. Al implementar este patrón, debe abordar varios problemas de arquitectura distribuida, como la disponibilidad de procesos remotos, la falta de capacidad de respuesta y la lógica de reconexión de intermediarios en caso de un fallo del intermediario o mediador.
Una consideración a tener en cuenta al elegir este patrón de arquitectura es la falta de transacciones atómicas para un solo proceso de negocio. Debido a que los componentes del procesador de eventos están altamente disociados y distribuidos, es muy difícil mantener una unidad transaccional de trabajo a través de ellos. Por esta razón, al diseñar su aplicación utilizando este patrón, debe pensar continuamente sobre qué eventos pueden y no pueden ejecutarse de forma independiente y planificar la granularidad de los procesadores de sucesos en consecuencia. Si descubre que necesita dividir una sola unidad de trabajo en los procesadores de eventos, es decir, si utiliza procesadores independientes para algo que debería ser una transacción indivisa, probablemente no sea el patrón adecuado para su aplicación.
Dejo link: http://radar.oreilly.com/2015/02/variations-in-event-driven-architecture.html
Mostrando las entradas con la etiqueta Mule. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Mule. Mostrar todas las entradas
domingo, 16 de julio de 2017
martes, 1 de octubre de 2013
Download Free ebook
He recibido de una empresa llamada Attune el siguiente mail y lo comparto:
viernes, 20 de julio de 2012
lunes, 2 de abril de 2012
Mule ESB
Mule es un Enterprise Service Bus liviano dirigido a eventos y también es una plataforma de integración. Mule es uno de los ESB Open Sources más usados.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPshA0104FDEe9i8N6hAxV-E2G8Zu4NIiRNM6U9BEdI5G33H3sCCoQhmVtxg-ilxEUJWD8bO_2gsDChU2wttZFfJ8eix_oWaZRFImGDVWfNNiAjsQFchMKTWThUoJQ6wIgkrv6TGXaMIA/s200/mule.jpg)
El mensaje pasa por varias capas lógicas, la primera es la capa de modelo. Esta proporciona servicios, tales como las estrategiasde excepción. Además, presta servicios con valores por defecto para simplificar su configuración.
Luego viene la capa de servicios. La capa de servicio se compone de todas las entidades involucradas en el procesamiento, en particular peticiones de maneras predefinidas. En el ejemplo el servicio tendría que actuar como un puente entre la entrada HTTP y los mensajes salientes mensajes JMS.
La capa de transporte es la encargada de la comunicación entrante y saliente. Un transporte se representa en la configuración de los siguientes elementos: conectores, terminales y transformadores.
Un conector es responsable de controlar el uso de un protocolo particular. Está configurado con los parámetros que son específicos de este protocolo. Por ejemplo, un conector JMS está configurado con una conexión, que es compartida por las distintas entidades encargadas de la comunicación real.
Un endpoint representa el uso específico de un protocolo, ya sea para escuchar o publicar un servicio.
Transformer como su nombre indica, un transformador se encarga de traducir el contenido de un mensaje de una forma a otra.
Los Routers juegan un papel crucial en el control de la trayectoria de un mensaje es el que controla el transito en Mule.
Los Components son la pieza central de los servicios de mula. Cada servicio se organiza con un componente en su núcleo y los routers de entrada y salida a su alrededor.
Con esto vimos un poco de terminología de mule ESB, luego veremos un caso práctico.
domingo, 25 de marzo de 2012
Instalar Mule ESB en linux
Vamos a instalar Mule ESB en linux, Mule es un ESB que funciona muy bien y es el más usado de los ESB open sources.
Primero vamos a bajarlo de : http://www.mulesoft.org/download-mule-esb-community-edition
Luego de descargarlo vamos a copiarlo a opt (utilice root o un usuario con permisos)
mkdir /opt/muleESB
mv Descargas/MuleStudio-CE-for-Linux-64bit_20120120.zip /opt/muleESB/
Descomprimimos:
cd /opt/muleESB
unzip MuleStudio-CE-for-Linux-64bit_20120120.zip
Ahora damos permisos correspondientes:
chmod u+x MuleStudio/
Y con esto ya estamos. Para utilizar mule tienes que tener configurada la jdk de java. Para esto podemos descargar la jdk del siguiente link: http://www.oracle.com/technetwork/java/javase/downloads/index.html
Cuando descarguemos este .bin solo hay que ejecutarlo y luego configurar la variable de entorno JAVA_HOME.
export JAVA_HOME=/java/sdk/jdk1.6.0_26
Y luego podemos ejecutar Mule
cd MuleStudio
./muleStudio
Y ya esta!!
Suscribirse a:
Entradas (Atom)