|
Mostrando las entradas con la etiqueta Apache ActiveMQ. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Apache ActiveMQ. Mostrar todas las entradas
jueves, 3 de diciembre de 2020
Libros Gratuitos de Java Code Geeks
miércoles, 17 de junio de 2020
Libros de Java Geeks
|
jueves, 19 de diciembre de 2019
Libros de Java Code Geeks
|
martes, 4 de diciembre de 2018
Apache ActiveMQ Cookbook y Amazon AWS Tutorial
|
domingo, 16 de julio de 2017
El patrón arquitectónico Event-Driver
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
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
domingo, 11 de marzo de 2012
Agregar ActiveMQ al ejemplo de ServiceMix
Continuando con el ejemplo:
http://emanuelpeg.blogspot.com/2012/03/usando-apache-camel-desde-apache.html
En el anterior ejemplo creamos una ruta que movía un archivo de una carpeta a otra, bueno ahora vamos a crear un evento de ActiveMQ cuando se mueva un archivo.
Por lo tanto el archivo xml que habia llamado copia queda así:
FileMovedEvent(file: ${file:name}, timestamp: ${date:now:hh:MM:ss.SSS})
Donde FileMovedEvent va ser un evento generado por la copia y va a ser publicado en activemq://events
Si vemos el log no vamos a ver nada porque los eventos no sos consumidos por un cliente por lo que vamos a hacer un cliente:
Guardamos este archivo tambien en la carpeta deploy con el nombre que quieran, yo le voy a poner cliente.xml
Con este cliente vamos a poder ver en el log las copias.
Reiniciamos copia.xml
osgi:stop 156
osgi:start 156
Y listo!
Dejo link de la fuente:
http://servicemix.apache.org/docs/4.4.0/quickstart/
jueves, 8 de marzo de 2012
Apache ServiceMix
Apache ServiceMix es un flexible ESB open source, que integra funcionalidad de diversos productos de Apache como Apache ActiveMQ, Camel, CXF, ODE y Karaf. Provee el funcionamiento de un ESB integrado a una herramienta OSGI.
Las características de Apache ServiceMix son:
- Mensajería segura gracias a Apache ActiveMQ
- Mensajería, enrrutamiento y patrones de integración para Empresas con Apache Camel
- ServiceMix NMR incluye eventos ricos, mensajería y auditoría lo que permite una integración con bajo acoplamiento.
- Completo WS-BPEL con Apache ODE.
- Basado en OSGI con la utilización Apache Karaf.
Además es licencia Apache 2.
Dejo Link:
http://servicemix.apache.org/
Suscribirse a:
Entradas (Atom)
