Hace unos días revisando el blog de MULE me topé con esta entrada del 3/04/2014 donde se explica como con la nueva versión 3.5 se ha añadido una funcionalidad para eliminar algunos problemas de las versiones anteriores a la hora de implementar el patrón de integración "Scatter-Gather".
Este patrón define la forma de enviar un mismo mensaje a diferentes destinos con un objetivo determinado y luego procesar la respuesta de una manera específica, tal como pueden ver en la imagen siguiente.
Un objetivo que nos llevaría a implementar este patrón puede ser el mandar un mismo request a diferentes sistemas que se encargan de procesar reservaciones de vuelos y a partir de la respuesta recibida de cada uno seleccionar la mejor para la solución final, tanto los ejemplos de MULE como de WSO2 seleccionan de las respuestas recibidas la más barata. Es solo un ejemplo pero les puede dar idea de la utilidad del patrón.
MULE antes de la versión 3.5 implementaba este patrón usando un router multicasting <all>, el cual presentaba las siguientes limitantes según se comenta en el propio artículo:
Lo interesante es que MULE hace esto ahora, pero WSO2 lo tiene hecho desde hace un tiempo ya y no con un mediador si no con la combinación de varios mediadores, lo que implica que la solución aunque parezca un poco más complicada técnicamente permite una mayor personalización para los desarrolladores. Y creo que esto es genial, el tener pequeños bloques de construcción que puedan ser usados para casi cualquier cosa y pienso que esa es la idea de WSO2. Si a esto le sumamos que podemos crear templates a partir de una solución en particular y luego usar dicho template para recrear una nueva implementación del patrón, pues nos ahorramos mucha configuración.
Solo les dejo el XML del servicio proxy para que lo vean:
La solución que propone WSO2 para este patrón la pueden encontrar en este enlace muy bien documentada y lista para ser probada con un paso a paso, así que no la recrearé en esta entrada.
Este patrón define la forma de enviar un mismo mensaje a diferentes destinos con un objetivo determinado y luego procesar la respuesta de una manera específica, tal como pueden ver en la imagen siguiente.
Un objetivo que nos llevaría a implementar este patrón puede ser el mandar un mismo request a diferentes sistemas que se encargan de procesar reservaciones de vuelos y a partir de la respuesta recibida de cada uno seleccionar la mejor para la solución final, tanto los ejemplos de MULE como de WSO2 seleccionan de las respuestas recibidas la más barata. Es solo un ejemplo pero les puede dar idea de la utilidad del patrón.
MULE antes de la versión 3.5 implementaba este patrón usando un router multicasting <all>, el cual presentaba las siguientes limitantes según se comenta en el propio artículo:
- Procesamiento en secuencia, o sea uno detrás del otro.
- Problemas en el manejo de los errores.
- Poca personalización de la solución para adecuarla a las necesidades específicas de los desarrolladores.
Lo interesante es que MULE hace esto ahora, pero WSO2 lo tiene hecho desde hace un tiempo ya y no con un mediador si no con la combinación de varios mediadores, lo que implica que la solución aunque parezca un poco más complicada técnicamente permite una mayor personalización para los desarrolladores. Y creo que esto es genial, el tener pequeños bloques de construcción que puedan ser usados para casi cualquier cosa y pienso que esa es la idea de WSO2. Si a esto le sumamos que podemos crear templates a partir de una solución en particular y luego usar dicho template para recrear una nueva implementación del patrón, pues nos ahorramos mucha configuración.
Solo les dejo el XML del servicio proxy para que lo vean:
<proxy xmlns="http://ws.apache.org/ns/synapse" name="ScatterGatherProxy" transports="https http" startOnLoad="true" trace="disable"> <description/> <target> <inSequence> <clone> <target> <endpoint name="vendorA"> <address uri="http://localhost:9000/services/SimpleStockQuoteService/"/> </endpoint> </target> <target> <endpoint name="vendorB"> <address uri="http://localhost:9001/services/SimpleStockQuoteService/"/> </endpoint> </target> <target> <endpoint name="vendorC"> <address uri="http://localhost:9002/services/SimpleStockQuoteService/"/> </endpoint> </target> </clone> </inSequence> <outSequence> <log level="full"/> <aggregate> <completeCondition> <messageCount min="3"/> </completeCondition> <onComplete xmlns:m1="http://services.samples/xsd" xmlns:m0="http://services.samples" expression="//m0:return"> <enrich> <source xmlns:m1="http://services.samples/xsd" clone="true" xpath="//m0:return[not(preceding-sibling::m0:return/m1:last <= m1:last) and not(following-sibling::m0:return/m1:last < m1:last)]"/> <target type="body"/> </enrich> <send/> </onComplete> </aggregate> </outSequence> </target> </proxy>
La solución que propone WSO2 para este patrón la pueden encontrar en este enlace muy bien documentada y lista para ser probada con un paso a paso, así que no la recrearé en esta entrada.
MULE vs WSO2 en el patrón de integración Scatter-Gather.