Apache Synapse Enterprise Service Bus (ESB) y WSO2

Esta es la serie de blogs dedicados al ESB de WSO2. Está basado en el ESB desarrollado por Apache Synapse. En esta introducción explico el funcionamiento básico del BUS y continuaré con todos los ejemplos explicados al detalle en cada blog.

La documentación original la podréis encontrar en la web de Synapse, y los ejemplos de Synapse están también en la web de WSO2. La ventaja es que en este blog analizaremos cada ejemplo añadiendo más comentarios y más gráficos a alto nivel, algo que es difícil de ver en la documentación de Synapse y WSO2. Además podéis incluir vuestras dudas o problemas si hay algún ejemplo que no os funcione. Me gusta añadir también la información que proporciona algún Sniffer como TCPMON de WSO2 para entender mejor los mensajes que viajan entre los componentes.

Nota:

En la web de WSO2 se puede descargar el ESB de dos formas:

– De manera independiente, seleccionando la versión del ESB que se desee descargar.

– O descargando el Enterprise Integrator. Este componente incluye: el ESB, Message Broker, Application Server, Business Process Server y Data Services Server.

Las ventajas: en primer caso solo se paga soporte a WSO2 por un solo componente. En el segundo caso se paga soporte a WSO2 por los componentes instalados independientemente. Es decir, es más rentable instalar el Integrator si se desea usar más de un componente WSO2. Pero esta nota es a nivel empresarial, por ejemplo para pagar soporte para el entorno de producción, por supuesto se puede descargar de forma gratuita en el portátil.

En este post se va a hacer uso de la versión 5.0.0 del ESB.

¿Qué es un ESB?

Básicamente un ESB (Enterprise Service Bus o Bus de Servicio Empresarial) es un middleware o mediador que actúa como puente entre distintas aplicaciones para realizar un procesamiento. Como por ejemplo, leer de unas colas y enviar los mensajes a un punto final o servicio en el BackEnd.

Hablaré más adelante de los distintos patrones de integración usando esta tecnología a través de ejemplos.

Apache Synapse posee soporte para mensajes de texto plano, binario, Hessian (protocolo de servicio web), XML como SOAP, JSON, servicios Web y REST. Otros protocolos que usa son: HTTP/S, Mail (POP3, IMAP, SMTP), JMS, TCP, UDP, VFS, SMS, XMPP and FIX.

ESB de Synapse

El bus es capaz de procesar un volumen grande de mensajes con un mínimo retardo y uso de recursos. Utiliza Axis 2 como motor de Servicios Web. Es configurable usando una serie de archivos en XML. Se puede clusterizar y usa un amplio conjunto de mediadores. Estos sirven para procesar los mensajes dentro del ESB. Además se pueden extender o crear mediadores personalizados. Es posible usar archivos de logs, para mostrar las trazas de ejecución del ESB. Hay una recolección de datos estadísticos como el numero de peticiones por segundo, errores en el procesamiento de mensajes, etc. Con la tecnología JMX se puede monitorizar el comportamiento de la herramienta.

-Quizá te interese: ¿qué necesitas para implementar WSO2 en tu empresa?-

Arquitectura de WSO2 ESB (ESB de Synapse integrado en la plataforma Carbon de WSO2)

En el diagrama se puede distinguir una serie de elementos bien diferenciados que explican el funcionamiento interno del ESB.

– La capa de transporte se encarga de enviar y reportar mensajes en distintos formatos. Se pueden incluir nuevos tipos de transporte a modo de plugin. Cada transporte usa un servicio para escuchar los mensajes entrantes y otro para enviar las respuestas.

– En la siguiente capa, el transporte que recibió el mensaje, selecciona el ‘Message Builder’ según el valor del ‘content type’ de la cabecera del mensaje. Lo que hace es transformar la carga útil al formato XML que entiende el motor de mediadores.

En la respuesta, de nuevo, según el valor del ‘content type’, se selecciona el ‘Message Formatter’, para convertir la carga útil al formato original. Estos dos componentes se pueden personalizar.

– La capa QoS (Quality of Service) añade seguridad al servicio proxy. Esto se realiza aplicando un archivo de políticas de seguridad en XML al servicio web. Hay varios escenarios de seguridad predefinidos, el de por defecto se llama: UsernameToken. Este token viaja en el mensaje y es usado para autenticación. Con otros escenarios de seguridad se puede especificar qué roles pueden tener acceso al servicio proxy.

– Seguidamente aparece el motor Synapse ESB. En él están los siguientes componentes:

Proxy: Es un servicio virtual en el ESB que recibe el mensajes y los procesa. Después lo entrega a un punto final fuera del ESB donde esta el Servicio Web real.
API: El Rest API es un punto final en el ESB con una URL. En esta dirección se indica el contexto y los recursos a los que se quiere tener acceso a través de un método o tipo de llamada HTTP como GET, PUT, POST, DELETE. Las peticiones llegan a la secuencia de entrada, el ESB procesa el mensaje con mediadores y se remite el mensaje al Backend. La secuencia de salida recibe la respuesta del backend, la procesa y remite el mensaje al cliente.
Inbound endpoints (Puntos finales de entrada): Se puede configurar de una manera dinámica sin reiniciar el servidor. Los mensajes se mueven desde la capa de transporte a la capa de mediación sin pasar por el motor Axis2.
Main: Esta es la secuencia principal en el ESB usado para reenviar las peticiones que no coincidan con ningún servicio definido.
Sequences: Las secuencias se usan en los servicios proxy y en las APIs REST. Cada secuencia es un conjunto de mediadores donde se procesan los mensajes.
Mediator: Es cada unidad de procesamiento o acción que se realiza sobre un mensaje. Por ejemplo para enriquecer un mensaje, para filtrarlo, para enviarlo a un punto final, para borrarlo, etc. Los mediadores se pueden personalizar.
Scheduled Tasks (Tareas programadas): Es un código que se va a ejecutar en un tiempo determinado. Las tareas también se pueden personalizar.
Endpoints: Es un destino, por ejemplo externo al ESB, para un mensaje, puede ser un servicio representado por una URL, mailbox, cola JMS, TCP socket. El mismo punto final se puede usar con distintos protocolos de transporte.
Message Store/Message Processors: Este patrón de diseño en integración se usa cuando se lidia con mensajería de una manera asíncrona. Es decir, el cliente no espera a la respuesta. El mensaje se almacena en memoria o disco, esto lo hace el Message Store. El procesador de mensaje extrae este de una cola, memoria o base de datos y lo envía a un punto final. Con este patrón se puede garantizar la entrega del mensaje al punto final ya que solo se borra del Store cuando el punto final recibe correctamente el mensaje.

– Registry: El registro es un contenedor de metadatos. Donde se guardan recursos como: WSDL, esquemas de mensajes para su validación, scripts, archivos XSLT, transformaciones Xquery, etc. Esta información se puede usar haciendo referencia de ella en los mediadores. Es un manera de organizar mejor la información dentro del ESB.

– Management UI: Es una Interfaz Gráfica de Usuario donde poder configurar todos los componentes por medio de menús y opciones.

– Carbon Platform: Es un middleware open source sobre el que se construye el resto de componentes de WSO2.

Conclusión

Este es el primer capitulo introductorio del ESB. En los restantes empezaremos con los primeros ejemplos del ESB. Desde el nivel básico a los más complejos. En resumen, con una herramienta como WSO2 ESB fácil de usar y descargar. Y sin no mucho trabajo a lo hora de configurarlo internamente por medio de archivos XML. Lo más interesante es que al ser de código abierto en java, facilita la personalización de la herramienta por medio de interfaces.

Descubre el siguiente episodio sobre ESB: “Guía de Instalación e Inicio rápido con WSO2 ESB“, ¡disfrútalo!

Referencias: