¡Bienvenido de nuevo a la sección especial de nuestro post dedicada a ESB!
Introducción
Siguiendo con el catálogo de ejemplos de Synapse, durante el post de hoy veremos cómo funciona el enrutamiento de mensajes basado en su contenido. En este caso nos centraremos en el valor de la propiedad TO de la cabecera del mensaje. Su valor indica dónde se dirigen los mensajes.
Mediación de Mensaje
Enrutamiento Simple Basado en el Contenido (Filter Mediator).
En este ejemplo el Cliente envía un mensaje al ESB. Éste actúa como un gateway aceptando todos los mensajes, y enrutando aquellos con un contenido particular en la propiedad de la cabecera TO. También se podría realizar el enrutamiento basándose en el contenido del payload del mensaje.
Esto es lo que realizaremos:
Para ello, primeramente hay que desplegar el archivo CAR con todas las secuencias en WSO2 ESB. Para más detalles, consulta nuestro anterior post, ¡te ayudará mucho!
Ahora se desplegarán una serie de Servicios Web expuestos a través de SOAP que redireccionan las requests a los puntos finales en el Backend de Axis2 Server o el servicio mock en SOAPUI. En el ESB aparecen desplegados esos servicios web que redireccionarán los mensajes a los puntos finales del backend:
http://localhost:8280/services/StockQuote?wsdl
http://localhost:8280/services/mockSampleServiceSoapBinding?wsdl
Como se puede ver en el soap12:address location, de cada uno de los archivos wsdl, los mensajes se redireccionan al backend, en AXIS2Server.
<soap12:address location=”http://172.17.0.1:9000/services/SimpleStockQuoteService.SimpleStockQuoteServiceHttpSoap12Endpoint”/>
Y en el segundo wsdl a SOAPUI.
<soap:address location=”http://trm-Dell-System-XPS-L702X:8088/mockSampleServiceSoapBinding”/>
Para arrancar el servidor AXI2Server:
wso2esb-4.9.0/samples/axis2Server$ ./axis2server.sh
Ahora tenemos que implementar un servicio mock SOAP en SOAPUI. En la imagen siguiente encontrarás toda la configuración.
-Descubre el primer post de la saga ESB: Apache Synapse Enterprise Service Bus (ESB) y WSO2-
Como se muestra en la Imagen en la parte superior aparece el símbolo de una carpeta SOAP. Pulsando sobre esta carpeta se puede crear el mock de un servicio web SOAP. En los siguientes recuadros aparecen el nombre de la carpeta ‘sample-service’, el nombre del servicio de ejemplo ‘SampleServiceSoapBinding’ y por último el nombre del mock service.
En el lado izquierdo de la pantalla aparece en el primer recuadro rojo la definición de la request y más abajo la respuesta definida dentro del servicio mock. En el lado derecho aparece el ejemplo del xml de la request y a la derecha el xml de la response que proviene de servicio mock.
Al seleccionar la Response 1, aparece el xml de la respuesta que envía el mock a la Request 1.
Si selecciona con doble click el nombre del servicio mock, en el pantallazo a la izquierda, en el lado derecho aparece la definición de las operaciones para este Web Service. Nosotros usaremos una llamada a la acción, operación login. Si pulsa ahora arriba en la rueda dentada, como muestra la imagen, aparecen las opciones del Servicio, con la ruta, puerto y nombre del host donde está desplegado.
Para ejecutar el servicio debemos pulsar el icono verde en forma de triángulo.
Tal y como muestra la pantalla, el servicio se ejecuta ahora en el puerto 8088.
Probando el enrutamiento.
Servicio AXIS2.
Una vez que tenemos ejecutando el backend Axis2Service y el servicio web en SOAPUI, podemos enviar las requests a través de WSO2 ESB.
Primero podemos probar el enrutamiento hacia Axis2Service. Para ello debemos ejecutar este comando, dentro de la ruta wso2esb-4.9.0/samples/axis2Client:
sudo ant stockquote -Dtrpurl=http://localhost:8280/services/StockQuote
Como se puede observar enviamos la request al WSO2ESB puerto 8280. La respuesta que nos llega del ESB, que a su vez viene del backend Axis2Service, es:
Ahora volvemos a la pantalla de comandos donde se ejecuta el ESB para ver la request y response que ha generado el log mediator del ESB. Resulta importante recordar que existen dos log mediators: uno en el In sequence, y el otro en el Out sequence.
La request que envía AXI2Client formateada del In sequence es esta:
To: /services/StockQuote,
WSAction: urn:getQuote,
SOAPAction: urn:getQuote,
ReplyTo: http://www.w3.org/2005/08/addressing/anonymous,
MessageID: urn:uuid:36ddb3e7-9679-48b7-8d58-66c604860847,
Direction: request,
Envelope:
Como se observa en la cabecera, el mensaje se envía al servicio: /services/StockQuote. El cliente está desacoplado del punto final, ni siquiera sabe dónde está el servicio, ese trabajo de direccionamiento es del ESB. Dentro del ESB el primer filtro toma el valor del parámetro TO. La expresión regular es verdadera y envía la request a:
http://localhost:9000/services/SimpleStockQuoteService
Este es el enrutamiento basado en el contenido, en este caso el contenido del parámetro TO.
Esta request se reenvía a Axis2Server, tal y como muestra la imagen la request es procesada en el backend:
El log mediator del out sequence en el ESB muestra la response que viene del backend:
To: http://www.w3.org/2005/08/addressing/anonymous,
WSAction: ,
SOAPAction: ,
ReplyTo: http://www.w3.org/2005/08/addressing/anonymous,
MessageID: urn:uuid:a73ebbc0-ca82-4053-981c-e7cb1279c277,
Direction: response,
Envelope:
Como se aprecia en el recuadro rojo, ése es el valor que muestra el cliente en la línea de comandos como ya vimos anteriormente.
Servicio SOAPUI.
Ahora enviaremos la request a SOAPUI. Para ello se debe ejecutar el siguiente comando:
curl –header “Content-Type: text/xml;charset=UTF-8” –header “SOAPAction:http://www.example.org/sample/login” –data @request.xml http://trm-Dell-System-XPS-L702X:8280/mockSampleServiceSoapBinding
La request está dirigida hacia el ESB por el puerto 8280 y la operación solicitada está en el valor de la cabecera SOAPAction.
El valor del archivo request.xml, es la carga útil que espera nuestro servicio mock en el SOAPUI.
La respuesta que recibe el cliente curl es:
Este es el response que se definió en el mock del SOAPUI para el SOAP action /login.
El ESB muestra la request que viene del comando curl.
To: /mockSampleServiceSoapBinding,
WSAction: http://www.example.org/sample/login,
SOAPAction: http://www.example.org/sample/login,
MessageID: urn:uuid:7b86babe-5349-4ec6-b960-dbecee0a7da8,
Direction: request,
Envelope:
Como se aprecia el valor del parámetro TO ha cambiado, ahora es: mockSampleServiceSoapBinding, que coincide con el valor de la expresión regular del segundo filtro en el ESB. Por tanto la request se enruta hacia el mock del SOAPUI.
Como se ve en la imagen, en el lado izquierdo aparece la request que se ha recibido y en el derecho la response del mock service.
El log mediator del out sequence del ESB muesta esa misma response:
To: http://www.w3.org/2005/08/addressing/anonymous,
WSAction: ,
SOAPAction: ,
MessageID: urn:uuid:ef3596b7-e6eb-4349-aaa3-380e8c556ecc,
Direction: response,
Envelope:
Conclusión
El enrutamiento de las requests por parte del ESB es una tarea muy sencilla. Se pueden usar los valores de las cabeceras como del payload de la requests. Además el ESB desacopla el punto final del Cliente, ya que éste solo necesita conocer el nombre del servicio que se pone como valor en la cabecera TO. El enrutamiento forma parte del patrón de integración Message Routing y dentro de este del Content-Based Router.
Si te perdiste nuestro último post sobre “Message Mediation: Catálogo de ejemplos de Synapse, WSO2 ESB”, no pierdas la oportunidad y ¡descúbrelo aquí!
La sección de posts ESB continúa, ¡nos leemos!
