Ir al contenido principal

Guía de Instalación e Inicio rápido con WSO2 ESB

Guía de instalación e inicio rápido WSO2 ESB

¿Preparado para un nuevo post de la sección de ESB? Te contamos como hacer la instalación e inicio rápido de WSO2 ESB

Instalación del entorno WSO2 ESB

En este nuevo capítulo dedicado al ESB instalaremos la herramienta y algunas utilidades más necesarias para ejecutar los ejemplos que vienen con WSO2, que son los mismos que vienen en la distribución de Synapse con ligeras modificaciones.

-Antes de continuar, quizá te ayude conocer mejor: ¿qué es un esb?-

Java

Usaremos un Ubuntu 16.04 LTS, Intel® Core™ i7-2630QM CPU @ 2.00GHz × 8, de 64-bit.

Para poder ejecutar WSO2 se necesita instalar un entorno de ejecución de Java, ya que WSO2 se ha desarrollado en este lenguaje. Lo conseguiremos descargando la Java SE Development Kit (JDK).

Para ello es necesario primero que compruebes si la máquina virtual está instalada en tu equipo, para ello teclea en el terminal:

java -version

Si no es así, se debe instalar desde el repositorio. Primero añadir el repositorio para poder descargar la JDK:

sudo add-apt-repository ppa:sun-java-community-team/sun-java6

Tras ello, hay que actualizar el repositorio e instalar la máquina:

sudo apt-get update

sudo apt-get install sun-java6-jdk

Otra herramienta interesante que se puede emplear para instalar distintas versiones de la máquina virtual en tu equipo, se llama: SDKMAN. Se trata de un gestor de kits de desarrollo de software, como la jdk. La instalación es muy sencilla, tan solo tendrás que seguir estos pasos.

Por ejemplo en mi caso, con Ubuntu para listar todas las máquinas virtuales gestionadas e instaladas por esta herramienta: sdk list java

Aparece un listado de las máquinas virtuales y la herramienta señala cual es la que actualmente se está utilizando en la consola. Si quieres usar una máquina distinta:

En el caso de no estar en el sistema puedes instalarla nueva. Teclea:  Y

Para confirmar que se ha instalado:

SDK además crea y actualiza la JAVA_HOME cada vez que se usa una JDK distinta:

Así, resulta mucho más cómodo.

Por si aún tienes dudas de todo lo que WSO2 ESB puede hacer por ti,¡descúbrelo en este post!

Proveedor JMS (Java Message Service)

Dado que con el ESB se puede trabajar con colas, se puede emplear el proveedor WSO2 Message Broker o Apache ActiveMQ. Las instrucciones para la instalación las comentaré más adelante, cuando entremos en el capítulo del Message Store y Message Processor.

Apache Ant

Es necesario instalar la herramienta Ant, la cual sirve para compilar los ejemplos del cliente de ESB y los backends..

Para instalarlo:

sudo apt-get install ant

Y para verificar la instalación:

ant -version

Maven

Con Maven recopilaremos los ejemplos del ESB.

La instalación:

wget http://www.apache.org/dist//maven/binaries/apache-maven-3.0.3-bin.tar.gz

Ahora extraemos el archivo, por ejemplo en el directorio /opt:

cd /opt

sudo tar -zxvf apache-maven-3.0.3-bin.tar.gz

Añade al path la home de Maven al final del archivo .bashrc :

export M2_HOME=/opt/apache-maven-3.0.3

export PATH=${M2_HOME}/bin:${PATH}

Para verificar la instalación:

MAVE

Explorador

Por último, para acceder la consola del WSO2 ESB hace falta un explorador como Firefox. https://www.mozilla.org/en-US/firefox/new/

Inicio rápido

En este apartado estudiaremos el modelo de mensajes de Synapse con el uso de mediadores de mensajes y mediadores de servicios, pues se trata del ejemplo más básico.

Primero comenzaremos con  WSO2 ESB, en este caso uso la versión 4.9.0, pero es igualmente válido para el resto de versiones. A lo largo del curso se irán presentando ejemplos con distintas versiones del ESB y en máquinas Linux y con Mac. Ahora, vamos a la carpeta ‘bin’ para ejecutar el ESB:

sudo ./wso2server.sh

Utiliza sudo porque el script necesita acceder y modificar una serie de archivos. Variables de entorno interesantes que aparecen en el log son: JAVA_HOME y CARBON_HOME., para guardar la JDK de Java y la ruta donde fue instalado WSO2.

Más abajo aparecen la Java Key Store, donde se guardan los certificados y claves encriptadas con el certificado de WSO2.

En esta segunda imagen de la inicialización, se aprecian los puertos para los servicios HTTP y HTTPS que son 8280 y 8243 respectivamente. A la consola WSO2 se accede a través de la url mostrada en rojo.

Hay que añadir como excepción de seguridad la url del ESB de WSO2,  pues no se había procedido a incluir el certificado de la keystore en el repositorio de certificados del explorador. Una vez resuelto este pequeño inconveniente,  visualizamos la pantalla de login.

En rojo aparecen la url del ESB que se ha  escogido del log en la consola. Como usuario y contraseña por defecto: admin, admin.

En la siguiente pantalla en el lado izquierdo aparecen los menús de la herramienta, y en la parte central información del host donde se está ejecutando WSO2: datos del SO, de la JRE (Java Runtime Environment usada por WSO2), y la base de datos por defecto H2 donde se guarda información del repositorio de metadatos. WSO2 recomienda no usar esta Base de Datos en el entorno de producción.

Ahora hay que desplegar el backend de ejemplo que viene con WSO2. Este backend se encarga de recibir los mensajes que vienen del ESB. El ESB los remite después al cliente

que envió la petición o la request.

INICIO RÁPIDO V

Para desplegar el backend en Axis2 se debe ir al directorio:

cd samples/axis2Server/src/SimpleStockQuoteService/

Ejecutar el comando ant.

Tras esto, se debe ejecutar el servidor Axis2 donde fue desplegado el servicio web:  SimpleStockQuoteService

Para ello hay que ejecutar el comando: sudo ./axis2server.sh

Tal y como se puede observar en el  recuadro azul, aparecen los puertos donde escucha el servidor. 9000 para el servicio HTTP y 9002 para el HTTPs.

El servicio web desplegado en el servidor tiene un archivo de contrato WSDL que se puede ver en el explorador:

INICIO RÁPIDO VIII

En los cuadrados rojos se puede ver la url donde se guardan los servicios, y el servicio desplegado con las operaciones disponibles. La operación que voy a usar en este ejemplo es: getQuote. Si pulsas en el link aparece el archivo WSDL del servicio.

En el archivo WSDL se definen los puntos finales que serán usados por el ESB o por el cliente para redirigir las requests a este mismo servicio.

Mediadores de Mensajes

El mediador por defecto del ESB lo puedes encontrar en el menú izquierdo, opción “Sequences”. Ahora, se debe  pulsar “Edit” en la secuencia “main”.

Selecciona “switch to source view”, para ver el código fuente se la secuencia:

– Secuencia main: Por aquí pasan todos los mensajes, ya que es la secuencia por defecto. Hay un mediador para mensajes entrantes, in, que logra los mensajes por la consola. Después aparece un filtro, para enviar/enrutar al punto final los mensajes que tienen en la cabecera To el valor http://localhost:9000.*

Los mensajes salientes, out, se envían directamente al cliente, send.

<?xml version="1.0" encoding="UTF-8"?>
<sequence name="main" xmlns="http://ws.apache.org/ns/synapse">
   <in>
       <!-- Log all messages passing through -->
       <log level="full"/>
       <!-- ensure that the default configuration only sends if it is one of samples -->
       <!-- Otherwise Synapse would be an open proxy by default (BAD!)               -->
       <filter regex="http://localhost:9000.*"
           source="get-property('To')" xmlns:ns="http://org.apache.synapse/xsd">
           <then>
               <!-- Send the messages where they have been sent (i.e. implicit "To" EPR) -->
               <send/>
           </then>
           <else/>
       </filter>
   </in>
   <out>
       <send/>
   </out>
   <description>The main sequence for the message mediation</description>
</sequence>

Ahora voy a enviar un mensaje usando el Servicio Web cliente. El mensaje se envía al backend a través del ESB. Para ello, hay que ir al directorio:

/wso2esb-4.9.0/samples/axis2Client

En la línea de comandos teclear:

sudo ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280 -Dmode=quote -Dsymbol=IBM

-Daddurl: Es el punto final donde se quiere mandar el mensaje.

-Dtrpurl: Es el punto final del ESB.

El nuevo precio de stock enviado desde el backend es: $145.44733097959232

Como el mensaje ha pasado por el ESB, y existe un medidor para lograr los mensajes:

<log level=”full“/>

se puede visualizar el contenido del mismo, en la consola del ESB:

-Formateado el mensaje:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
     <wsa:To>http://localhost:9000/services/SimpleStockQuoteService</wsa:To>
     <wsa:MessageID>urn:uuid:a1995447-5102-45ad-8d36-541da41c0657</wsa:MessageID>
     <wsa:Action>urn:getQuote</wsa:Action>
  </soapenv:Header>
  <soapenv:Body>
     <m0:getQuote xmlns:m0="http://services.samples">
        <m0:request>
           <m0:symbol>IBM</m0:symbol>
        </m0:request>
     </m0:getQuote>
  </soapenv:Body>
</soapenv:Envelope>

En la cabecera del mensaje aparece la propiedad To, para indicar hacia donde va el mensaje o la url del backend.  MessageID  es el identificador del mensaje.  Action es el método en el servicio web del backend que se va a llamar.  Body es el payload o carga útil del mensaje.

Los mensajes de log del servicio en el backend, axis2 server, son:

Indicando que se ha recibido un mensaje solicitando la última cotización para IBM. El dato que recibe el cliente fue, como sabemos,  $145.44733097959232.

Mediadores de Servicios (Servicio Proxy)

En este otro caso el cliente lidia con un servicio virtual. Para éste, este servicio es el único punto final, aunque el servicio virtual no use ninguno o varios puntos finales en el backend.

Esta es la diferencia con respecto al ejemplo anterior, ya que es el cliente quien manda las peticiones al ESB y dentro del mensaje se especifica la dirección del punto final o del backend en Axis2Service. Además, este servicio virtual se puede publicar con un protocolo, esquema, archivo WSDL o calidad del servicio distinto al punto final al que van dirigidas las peticiones. Utiliza también, como en el ejemplo anterior, secuencias y mediadores, lo que quiere decir que el mensaje de entrada, desde el cliente, o de salida, desde el backend, puede ser procesado o mediado.

La definición del servicio virtual en el ESB es la siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
      name="StockQuoteProxy"
      transports="https,http"
      statistics="disable"
      trace="disable"
      startOnLoad="true">
  <target>
     <outSequence>
        <log level="full"/>
        <send/>
     </outSequence>
     <endpoint>
        <address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
     </endpoint>
  </target>
  <description/>
</proxy>

El servicio proxy publica su contrato de comunicaciones a través del archivo WSDL, publishWSDL. El punto final del Servicio Virtual es el Servicio Web publicado en Aix2Service, SimpleStockQuoteService.

Ahora procederemos a publicar ese servicio en el ESB. Para ello se debe seleccionar Proxy Service.

Tras ello, hay que seleccionar Custom Proxy.

A continuación pulsar switch to source view:

Dentro del recuadro rojo puede empezar a teclear el contenido o definición del Servicio Proxy.

El resultado final se puede observar en la siguiente pantalla. Pulsar el botón Save.

El servicio queda de la siguiente forma desplegado en el ESB:

Como se puede comprobar en el pantallazo, el servicio que queda definido como Proxy, no tiene seguridad asignada, queda accesible a través de dos contratos WSDL1.1 y WSDL2.0, se puede testear, tiene vista de diseño o vista del código fuente.

Si pulsa en el nombre del servicio StockQuoteProxy puedes visualizar más información del mismo, como por ejemplo el punto final que se tiene que usar para poder acceder al servicio Proxy, el recuadro en rojo.

Puedes ver el contenido del contrato del servicio en el enlace WSDL2.0.

En el explorador puedes ver la URI para acceder al archivo WSDL:

http://trm-dell-system-xps-l702x:8280/services/StockQuoteProxy?wsdl2

El puerto 8280 es el habilitado para el protocolo HTTP en el ESB. Dentro del archivo WSDL puedes ver el nombre del servicio y el punto final para poder acceder a él:

http://trm-Dell-System-XPS-L702X:8280/services/StockQuoteProxy.StockQuoteProxyHttpEndpoint

Para probar el servicio debes teclear en la línea de comandos:

sudo ant stockquote -Dtrpurl=http://localhost:8280/services/StockQuoteProxy -Dmode=quote -Dsymbol=IBM

Como puedes ver, el único punto final que se especifica es el del Servicio Virtual. Este a su vez redirige la petición al Backend. A continuación puedes ver la respuesta del servicio en el backend.

El log que genera el ESB es:

Dicho log mediator del outSequence imprime ese mensaje que fue generado en el backend y va hacia el cliente que realizó la petición o request. El mensaje de respuesta formateado es:

To: http://www.w3.org/2005/08/addressing/anonymous,

WSAction: urn:getQuoteResponse,

SOAPAction: urn:getQuoteResponse,

ReplyTo: http://www.w3.org/2005/08/addressing/anonymous,

MessageID: urn:uuid:e7372891-a7ad-4a8e-870b-5f8487367736,

Direction: response,

Envelope:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
     <wsa:Action>urn:getQuoteResponse</wsa:Action>
     <wsa:RelatesTo>urn:uuid:95dcd642-92ef-4797-9dcc-c9941422c273</wsa:RelatesTo>
  </soapenv:Header>
  <soapenv:Body>
     <ns:getQuoteResponse xmlns:ns="http://services.samples">
        <ns:return xmlns:ax21="http://services.samples/xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ax21:GetQuoteResponse">
           <ax21:change>4.498546820367199</ax21:change>
           <ax21:earnings>12.582807320308271</ax21:earnings>
           <ax21:high>-146.55980144781606</ax21:high>
           <ax21:last>147.91774407057486</ax21:last>
           <ax21:lastTradeTimestamp>Sun Mar 04 20:45:40 GMT 2018</ax21:lastTradeTimestamp>
           <ax21:low>152.4077138700047</ax21:low>
           <ax21:marketCap>-5137701.204639474</ax21:marketCap>
           <ax21:name>IBM Company</ax21:name>
           <ax21:open>154.6561907290828</ax21:open>
           <ax21:peRatio>23.638753365530036</ax21:peRatio>
           <ax21:percentageChange>2.6971428631778473</ax21:percentageChange>
           <ax21:prevClose>166.78934148363535</ax21:prevClose>
           <ax21:symbol>IBM</ax21:symbol>
           <ax21:volume>7055</ax21:volume>
        </ns:return>
     </ns:getQuoteResponse>
  </soapenv:Body>
</soapenv:Envelope>

En la dirección del mensaje, Direction: response, es una respuesta, mensaje que por tanto viene del backend y que se dirige al cliente que lanzó la request. El texto en amarillo es el valor que el cliente visualiza en la pantalla de comandos.

TCPmon

En la instalación del ESB viene incluido un sniffer llamado tcpmon. Es una herramienta muy interesante para interceptar mensajes al vuelo que van a un servicio y vienen como respuesta de otro. Permite debugear y entender mejor cómo funciona la integración de los distintos componentes entre sí. Esta instalado en el directorio: wso2esb-4.9.0/bin (4.9.0 es la versión del ESB que estoy usando en este Blog). Aparece con extensión bat para Windows o sh para Linux. Para ejecutarlo: sudo ./tcpmon.sh Para el ejemplo de este blog, me refiero al del Servicio Virtual se puede usar entre el servicio Cliente y el ESB, y entre el ESB y el backed para interceptar todos los mensajes entrantes y salientes.

TCPMON

1) Cliente/TCPmon/ESB

En este caso el Cliente Web tiene que enviar el mensaje al puerto donde el sniffer está escuchando. Mientras que el sniffer a su vez, reenvía dicho mensaje al puerto 8280 del ESB donde se desplegó el Servicio Proxy, a la vez que imprime el contenido del mensaje. El mensaje de respuesta también se imprime.

La petición o comando request del Cliente sería entonces:

sudo ant stockquote -Dtrpurl=http://localhost:8281/services/StockQuoteProxy -Dmode=quote -Dsymbol=IBM

Como se puede observar, el puerto ya no es el 8280, sino el 8281 que es por donde el sniffer está escuchando.

La configuración de TCPmon es la siguiente:

El cuadrado rojo muestra el puerto por donde está escuchando el sniffer, 8281. El cuadrado azul indica el puerto a donde se reenvía el mensaje, 8280, es decir, el puerto por donde nuestro Proxy está escuchando.

Una vez enviada la petición el sniffer, éste intercepta los mensajes request y response:

Se puede ver el puerto por donde escucha TCPmon 8281, así como el puerto a donde se dirige el mensaje 8280. Aparece el tipo de request, es un verbo POST /Services/StockQuoteProxy.

El mensaje request del Cliente:

POST /services/StockQuoteProxy HTTP/1.1

Content-Type: text/xml; charset=UTF-8

SOAPAction: “urn:getQuote”

User-Agent: Axis2

Host: 127.0.0.1:8281

Transfer-Encoding: chunked

1d6

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
     <wsa:MessageID>urn:uuid:f7c0f72a-27dd-44ef-a9d9-b1f7aab08bc3</wsa:MessageID>
     <wsa:Action>urn:getQuote</wsa:Action>
  </soapenv:Header>
  <soapenv:Body>
     <m0:getQuote xmlns:m0="http://services.samples">
        <m0:request>
           <m0:symbol>IBM</m0:symbol>
        </m0:request>
     </m0:getQuote>
  </soapenv:Body>
</soapenv:Envelope>

El mensaje response del backend es:

HTTP/1.1 200 OK

Content-Type: text/xml; charset=UTF-8; charset=UTF-8

Date: Sun, 04 Mar 2018 22:47:36 GMT

Transfer-Encoding: chunked

44c

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing" />
   <soapenv:Body>
      <ns:getQuoteResponse xmlns:ns="http://services.samples">
         <ns:return xmlns:ax21="http://services.samples/xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ax21:GetQuoteResponse">
            <ax21:change>-2.5841872904853656</ax21:change>
            <ax21:earnings>12.399799910092177</ax21:earnings>
            <ax21:high>77.22015514490265</ax21:high>
            <ax21:last>73.57205995197508</ax21:last>
            <ax21:lastTradeTimestamp>Sun Mar 04 22:47:36 GMT 2018</ax21:lastTradeTimestamp>
            <ax21:low>-72.04349708004447</ax21:low>
            <ax21:marketCap>-5962331.904617637</ax21:marketCap>
            <ax21:name>IBM Company</ax21:name>
            <ax21:open>-71.98873049366591</ax21:open>
            <ax21:peRatio>24.59327295219441</ax21:peRatio>
            <ax21:percentageChange>3.7860003496820887</ax21:percentageChange>
            <ax21:prevClose>-68.25639333874759</ax21:prevClose>
            <ax21:symbol>IBM</ax21:symbol>
            <ax21:volume>15110</ax21:volume>
         </ns:return>
      </ns:getQuoteResponse>
   </soapenv:Body>
</soapenv:Envelope>

El valor en negrita 73.57205995197508, es el que visualiza el cliente en la línea de comandos.

2) ESB/TCPmon/Backend

En este caso el sniffer muestra el mensaje de request que sale del ESB, además del mensaje de response que parte del backend. Para ello se debe modificar el Proxy del ESB para que dirija el tráfico al sniffer, y éste al backend. Resulta importante cambiar el puerto del punto final. En este caso se está empleando el: 9001

    …

     <endpoint>

        <address uri=”http://localhost:9001/services/SimpleStockQuoteService“/>

     </endpoint>

    

Al salvar el Proxy, el ESB despliega éste con la nueva configuración. Ahora se debe configurar TCPmon:

El cuadrado rojo contiene el puerto por el que escucha el sniffer. Es el mismo puerto usado por el Proxy para enviar los mensajes al punto final. A su vez TCPmon reenvía los mensajes al backend a través del puerto 9000 que está en el recuadro azul.

Ahora se envía de nuevo la request desde el Cliente:

sudo ant stockquote -Dtrpurl=http://localhost:8281/services/StockQuoteProxy -Dmode=quote -Dsymbol=IBM

Y efectivamente,  el Sniffer ha capturado los mensajes al instante:

El mensaje request del Cliente que sale del ESB:

POST /services/SimpleStockQuoteService HTTP/1.1

Content-Type: text/xml; charset=UTF-8

SOAPAction: “urn:getQuote”

Transfer-Encoding: chunked

Host: 127.0.0.1:9001

Connection: Keep-Alive

User-Agent: Synapse-PT-HttpComponents-NIO

1d6

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
      <wsa:MessageID>urn:uuid:247acf74-7d08-4af9-bc33-cab657fc7003</wsa:MessageID>
      <wsa:Action>urn:getQuote</wsa:Action>
   </soapenv:Header>
   <soapenv:Body>
      <m0:getQuote xmlns:m0="http://services.samples">
         <m0:request>
            <m0:symbol>IBM</m0:symbol>
         </m0:request>
      </m0:getQuote>
   </soapenv:Body>
</soapenv:Envelope>

El mensaje response del backend que va hacia el ESB:

HTTP/1.1 200 OK

Content-Type: text/xml; charset=UTF-8

Date: Mon, 05 Mar 2018 20:03:17 GMT

Transfer-Encoding: chunked

Connection: Keep-Alive

4d9

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
      <wsa:Action>urn:getQuoteResponse</wsa:Action>
      <wsa:RelatesTo>urn:uuid:247acf74-7d08-4af9-bc33-cab657fc7003</wsa:RelatesTo>
   </soapenv:Header>
   <soapenv:Body>
      <ns:getQuoteResponse xmlns:ns="http://services.samples">
         <ns:return xmlns:ax21="http://services.samples/xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ax21:GetQuoteResponse">
            <ax21:change>-2.7094263029413312</ax21:change>
            <ax21:earnings>-9.121962748944178</ax21:earnings>
            <ax21:high>189.6192278787645</ax21:high>
            <ax21:last>184.43627910988891</ax21:last>
            <ax21:lastTradeTimestamp>Mon Mar 05 20:03:17 GMT 2018</ax21:lastTradeTimestamp>
            <ax21:low>-181.01566760388548</ax21:low>
            <ax21:marketCap>5.490809216978071E7</ax21:marketCap>
            <ax21:name>IBM Company</ax21:name>
            <ax21:open>190.55371322846588</ax21:open>
            <ax21:peRatio>24.83163812408509</ax21:peRatio>
            <ax21:percentageChange>1.5047337464878308</ax21:percentageChange>
            <ax21:prevClose>-180.06018069743897</ax21:prevClose>
            <ax21:symbol>IBM</ax21:symbol>
            <ax21:volume>18494</ax21:volume>
         </ns:return>
      </ns:getQuoteResponse>
   </soapenv:Body>
</soapenv:Envelope>

Como puedes comprobar, los mensajes son exactamente los mismos. Aunque el contenido del payload en cada response es distinto, debido a que se han generado con dos requests distintas.  

– Antes de finalizar, seguro que te interesa… –

Conclusión

El uso de Proxy Services resuelve muchos problemas de integración en los sistemas de información empresarial. No solo porque es capaz de mediar con muchos protocolos,  sino que también permite añadir una capa de seguridad, procesar los mensajes (con filtros o enriqueciéndolos con más información de otros servicios) y abstrayendo al usuario del resto de servicios del backend.

Por otro lado y siguiendo las buenas prácticas en el desarrollo dentro del ESB, para el Enterprise Integrator ya no es posible la edición de secuencias directamente en el editor del ESB, ahora todo eso se realiza en el entorno de desarrollo de Eclipse con los plugins de WSO2 instalados.

En los próximos capítulos profundizaremos más en el uso del ESB con ejemplos concretos y categorizados.

Si te perdiste el primer capítulo de la saga ESB por Tomás Rabazo, ¡ponte al día en un click!