¡Bienvenido a un capítulo más de la sección ESB! En este post vamos a detallar un catálogo de ejemplos de Synapse con WSO2 ESB.
1.Introducción
En esta entrega vamos a comenzar analizando los ejemplos que provienen con Synapse, los cuales son los mismos que aparecen en la documentación online de WSO2. Todos los ejemplos están categorizados:
- Mediación de Mensaje.
- Puntos finales.
- Adición y eliminación de Calidad de Servicio con Mediación de Mensajes.
- Servicios Proxy.
- Adición y eliminación de Calidad de Servicio con Servicios Proxy.
- Transportes.
- Tareas Programadas.
- Mediadores Avanzados.
- Eventos.
- Modelo de configuración de Synapse.
- Mediación basada en prioridad.
- Almacenamientos de mensaje y procesadores de mensaje.
- Plantillas.
- API Rest
- Librería EIP de Synapse.
Dentro de cada categoría existe un extenso conjunto de ejemplos que analizaremos a lo largo del post detenidamente.
2.Mediación de Mensaje
-
Introducción a Synapse (Ejemplo 0).
En este básico ejemplo, Synapse está configurado para logear mensajes que pasan a través de este middleware. El esquema de lo que se va a realizar es el siguiente: [Diagrama-1]
Desde el cliente Axis2 se envía un mensaje que va hacia el ESB, y desde éste a Axis2 Server donde se procesa y se remite una respuesta. En la secuencia hay dos mediadores principales: uno es el IN para procesar las requests y otro es el OUT para procesar las responses que vienen del backend. Todo esto se realiza dentro del mismo thread, de modo que las variables que pongamos en el mediador de entrada estarán disponibles en el mediador de salida.
Otro mediador importante es el SEND, que se usa para enviar el mensaje a su destino que es el Backend o el Cliente. El mediador LOG muestra el mensaje en la consola según la configuración del log4java que hayamos configurado en el ESB.
La secuencia se puede escribir usando el editor del ESB, pero como las buenas prácticas indican es siempre mejor usar el entorno WSO2 de desarrollo, o mejor dicho el WSO2 Developer Studio.
-
WSO2 Developer Studio
En el siguiente enlace podrás descargar el entorno de desarrollo:
https://wso2.com/products/developer-studio/
Entonces se mostrará una pantalla como la siguiente:
En nuestro caso al hacer uso de Ubuntu, seleccionamos LINUX 64BIT, tal y como se muestra subrayado en el cuadrado rojo.
A continuación se descarga un archivo zip:
developer-studio-eclipse-jee-luna-linux-gtk-x86_64-3.8.0.zip
Se descomprime en una carpeta, y dentro de ésta seleccionamos con doble click el archivo: eclipse.
Tras ello, se inicia la carga de Eclipse:
Tras ello, se debe seleccionar el espacio de trabajo de Eclipse, lugar donde guardaremos nuestros proyectos.
Pulsamos OK. Se abre entonces el entorno de desarrollo de Eclipse con los plugins necesarios para el desarrollo en la plataforma Carbon de WSO2.
Como se puede observar en la pantalla, los tipos de proyectos que utilizaremos serán:
— Maven Multi Module Project: Este es un proyecto Maven que aglutina todos los demás proyectos como si fueran módulos del proyecto principal.
–ESB Config Project: Este proyecto se utiliza para escribir la configuración del ESB.
–Composite Application Project: Este es el proyecto que genera un archivo CAR, el cual será el que utilicemos para desplegar las secuencias en el servidor ESB.
Para ello, primero generamos un proyecto Multi Module:
Donde se indica el Group Id, el Artifact Id y Versión del proyecto. Como en todo proyecto Maven. Pulsar Finish.
El proyecto Multi Module se ha creado con el archivo pom asociado. Dentro de este proyecto creamos el proyecto ESB. Selecciona el proyecto Multi Module, botón derecho y crear proyecto de Configuración del ESB.
Pulsar Next. El nombre del proyecto es Sample0.
-Antes de continuar, descubre este caso de éxito sobre la implantación de la arquitectura WSO2-
Este proyecto de Configuración del ESB se crea dentro del proyecto Multi Module.
Como se puede observar, en el cuadrado azul se encuentra el proyecto de configuración del ESB. En el archivo pom del Proyecto Multi Module aparece el nuevo módulo Sample0, (cuadrado rojo).
El siguiente proyecto que debemos crear dentro del proyecto Multi Modulo, es el Composite Application Project, donde se va a generar el archivo CAR con toda la configuración del ESB.
Este archivo es el que se importa en WSO2ESB para generar la secuencia. ¿Nos sigues?
Ahora, debemos seleccionar ‘Next’. El nombre del proyecto es: Sample0CAR. Pulsar Next.
Como en el proyecto de Configuración del ESB, seleccionar el Proyecto Multi Modulo como proyecto “padre” y pulsar Finish.
Ahora en el proyecto Multi Module se añade el nuevo módulo del proyecto Composite Application Project. La estructura quedaría del siguiente modo:
A la izquierda se encuentra la estructura jerárquica del proyecto MultiMódulo y a la derecha los dos módulos añadidos: el módulo del ESB y el módulo del proyecto CAR.
Ahora debemos seleccionar el proyecto Sample0, el proyecto de Configuración del ESB con botón derecho seleccionar: New→Sequence.
Pulsar Next. El nombre de la secuencia es main. Tras ello, pulsar Finish.
El next step es copiar en el archivo main.xml la siguiente secuencia:
<?xml version=“1.0” encoding=“UTF-8”?>
<sequence name=“main” xmlns=“http://ws.apache.org/ns/synapse”>
<in>
<!– log all attributes of messages passing through –>
<log level=“full”/>
<!– Send the message to implicit destination –>
<send/>
</in>
<out>
<!– log all attributes of messages passing through –>
<log level=“full”/>
<!– send the message back to the client –>
<send/>
</out>
</sequence>
El resultado final sería:
-¿Consejos para alcanzar la transformación digital de tu compañía?-
Ahora se debe seleccionar en el proyecto Sample0CAR el archivo pom.xml. Elegir el artefacto: Sample0, que es la secuencia del ESB y salvar.
Ahora en la línea de comandos, debemos compilar con maven el proyecto Multi Módulo.
Si todo se ha compilado correctamente se mostrará el mensaje de BUILD SUCCESS, como se muestra en la siguiente imagen.
El archivo CAR se ha generado entonces en la carpeta target:
Este archivo lo importamos en el WSO2ESB, para ello se debe ejecutar el ESB:
./wso2server.sh Una vez logado seleccionar Add en el menú Carbon Applications.
Ahora, seleccionar el archivo CAR generado:
Si hemos realizado correctamente los pasos, WSO2ESB nos mostrará el mensaje felicitándonos por ello, tal que así:
A través de la consola de comandos también podemos ver la salida del log del ESB. En ella se muestra el resultado del despliegue del archivo CAR en el ESB.
En el ESB aparece la secuencia en la lista de aplicaciones Carbon.
Si deseas ver la secuencia desplegada, debes ir a: Service Bus→ Sequences → Edit y ¡listo!
Si pulsas el enlace Switch to Source podrás ver la secuencia:
-
Probando la secuencia
Para probar la secuencia se debe enviar una request desde Axis2 Client a Axis2 Server, pasando por el ESB. Para ello primero hay que ejecutar el servidor Axis2 o backend:
/wso2esb-4.9.0/samples/axis2Server$ sudo ./axis2server.sh
Como se aprecia en la imagen, Axis2Server usa dos puertos para recibir peticiones, el HTTP 9000 y el HTTPS 9002.
-Un pequeño break: ¿Está tu empresa preparada para el GDPR? –
Ahora hay que usar el cliente para enviar la request. El cliente está en el directorio:
/wso2esb-4.9.0/samples/axis2Client
a) El cliente
El cliente que vamos a usar es el: stockquote
Crea y envía una solicitud de cotización de acciones. Puede ejecutarse en los modos ‘cliente inteligente’, ‘proxy’ y ‘puerta de enlace’ al especificar WSA, transporte y puntos finales / URL HTTP proxy.
Opcionalmente, se podría aplicar una política (seguridad) a las solicitudes. El símbolo de stock requerido y la operación se pueden especificar de la siguiente manera:
Ejemplos:
1) ant stockquote
2) ant stockquote [-Dsymbol=IBM|MSFT|SUN|..]
[-Dmode=quote | customquote | fullquote | placeorder | marketactivity]
[-Daddurl=http://localhost:9000/soap/SimpleStockQuoteService]
[-Dtrpurl=http://localhost:8280]
[-Dprxurl=http://localhost:8280]
[-Drest=true]
[-Dwsrm=true]
[-Dpolicy=../../repository/samples/resources/policy/policy_1.xml]
Modos :
quote – envía una solicitud de cotización para una sola acción
customquote – envía una solicitud de cotización en un formato personalizado
fullquote – obtenga informes de cotización por un período (es decir, los 365 días del año)
placeorder – realiza un pedido de acciones con un pedido de ida (one way request)
marketactivity – obtenga un informe de actividad del mercado.
b) El servicio
El servicio que vamos a usar es el: SimpleStockQuoteService
Este servicio tiene cuatro operaciones; getQuote (in-out), getFullQuote (in-out), getMarketActivity (in-out) y placeOrder (in-only). La operación getQuote generará una cotización de stock de muestra para un símbolo dado. La operación getFullQuote generará un historial de cotizaciones de acciones para el símbolo durante varios días, y la operación getMarketActivity devuelve cotizaciones de acciones para una lista de símbolos dados. La operación placeOrder aceptará un mensaje de ida para un pedido.
c) Petición en modo cliente inteligente
sudo ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/
addurl: Con esta propiedad se indica el punto final al cual va dirigida la petición (WS-Addressing EPR).
Trpurl: Transport URL, en este caso es el ESB, como mediador de la petición o request.
d) TCP Monitor de Eclipse
Antes de enviar la petición vamos a configurar TCP Monitor en Eclipse para mostrar los mensajes entre el Cliente y el ESB y entre el ESB y el Backend. Para configurarlo hay una pestaña en Eclipse llamada TCP Monitor. Aquí configuramos esos dos sniffers exactamente igual a como lo hicimos en el capitulo anterior.
Ahora hay que modificar ligeramente la llamada para usar los puertos por los que escucha el Sniffer.
sudo ant stockquote -Daddurl=http://localhost:9001/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8281/
La salida del log del cliente refleja que la petición se realizó correctamente ya que nos llega una respuesta desde el servidor.
Stock price = $72.14561840612878
La petición SOA que recibe el primer Sniffer entre el Cliente y el ESB es:
En la imagen anterior se muestra la configuración del TCP Monitor de Eclipse y la petición y respuesta en XML. A continuación aparece el mensaje que ha recogido el primer Sniffer.
El método o acción al que se llama es el getQuote. Éste generará una cotización de stock de muestra para el símbolo IBM. La dirección del destino final del mensaje está en wsa:To.
A continuación se muestra el log que ha generado el mediador en el ESB:
Como puede comprobar el mensaje es idéntico. La diferencia se encuentra en las nuevas cabeceras del mensaje que Synapse ha añadido.
To, para indicar el destino del mensaje.
MessageID, como el identificador del mensaje.
Direction, indica si el mensaje es una request o response (petición o respuesta).
Este es el mensaje request que ha capturado el segundo sniffer. Se trata del mensaje que sale del ESB:
Este mensaje llega al Servicio SimpleStockQuoteService y genera un mensaje de log en la consola.
La respuesta de este servicio a la petición la recoge el segundo Sniffer:
El símbolo asociado a la request es IBM, como se ve en el cuadrado rojo. En el azul esta la última cotización que muestra el Cliente.
El log del ESB es el siguiente:
Como se puede ver en las cabeceras, no hay destinatario del mensaje en la propiedad To. Por otro lado, tampoco hay Action ya que es un mensaje response como se indica en la cabecera Direction.
Al ser un nuevo mensaje se genera un nuevo MessageID.
Por último, la respuesta que muestra el primer Sniffer es la siguiente (Respuesta que viene del ESB):
El payload es idéntico al mensaje de respuesta del resto de mediadores, ESB y el segundo Sniffer. El valor del campo ax21:last es el que refleja el log del cliente, como hemos visto.
e) Petición en modo cliente proxy
Para ejecutar la petición en el cliente en el modo proxy:
ant stockquote -Daddurl=http://localhost:9001/services/SimpleStockQuoteService -Dprxurl=http://localhost:8281/
prxurl: En este modo, el cliente usa el ‘prxurl’ como un proxy HTTP para enviar la solicitud. Por lo tanto, al configurar ‘prxurl’ en Synapse, el cliente puede asegurarse de que el mensaje llegue a Synapse para la mediación.
Una vez lanzada la petición el primer Sniffer muestra este mensaje request:
La carga útil es siempre la misma.
El encabezado de la solicitud HTTP Proxy-Authorization contiene las credenciales para autenticar un agente de usuario en un servidor proxy. En este caso no hay credenciales que usar. Éstas están codificadas en Base 64 (https://www.base64decode.org/). El valor codificado es el username:password, en este caso no hay ningún valor.
También se puede observar el contenido del segundo Sniffer y del log del ESB, así como el valor de response que obtiene el primer Sniffer. No es necesario mostrarlos, pues son muy parecidos a los que ya se ha expuesto.
3. Conclusión
En esta ocasión hemos empleado WSO2 Developer Studio para generar la configuración del ESB, y seguir con las buenas prácticas,y el TCP Monitor como Sniffer integrado en Eclipse.
Todos estos plugins del entorno facilitan mucho la tarea de trabajar con las herramientas de integración de WSO2. No solo con el ESB, también con WSO2API Manager por ejemplo.
El detalle de la configuración del entorno es siempre la misma en todos los capítulos. Si tienes dudas en futuras entregas, no dudes en remitirte a este documento. ¡Ah y si te perdiste la segunda entrega de esta sección de ESB: Guía de Instalación e Inicio rápido con WSO2 ESB, descúbrela aquí.
