El uso de un ESB se ha puesto de moda. No estoy diciendo que la tecnología no sea adecuada, pero el uso de un ESB no significa necesariamente tener SOA. Mi objetivo aquí es dar mi punto de vista sobre ESB, y de cómo y cuando puede ser usado en una solución SOA y en soluciones que no son SOA.
Exactamente, si fuesemos por la traducción literal significa servicio de ómnibus corporativo. La idea es muy simple: el bus lleva y trae datos para nosotros, luego nosotros no tenemos que preocuparnos sobre algunos detalles. Imagine que los pasajeros son los datos y que cada parada del autobús es un sistema que se accede con un protocolo diferente. El concepto de bus no es nuevo en el área, si miramos a las placas madre ya teníamos el concepto allí, sólo él fue adaptado para la integración de sistemas.
En la práctica, usar un ESB nos trae más abstracción que, por ejemplo, usar JMS. Debido a que el bus está en un nivel más alto provee más abstracciones y facilidades. El uso de un ESB trae una serie de facilidades para la integración de sistemas y es de lo que vamos a hablar.
¿Implementar un ESB == SOA?
De ninguna manera. ESB se centra en la integración de sistemas, específicamente hablando de los protocolos, plataformas y formas de acceso como http, ftp, sockets, etc ... En cuanto a SOA trata de contratos y reutilización de sistemas.
Tengamos en cuenta que la integración es una parte importante, pero SOA es mucho más que eso. Incluso si utilizamos un ESB eso no hace que tengamos SOA; lograr SOA va a depender de la forma en que modelamos y concebimos a nuestros sistemas. No podemos tener SOA solo teniendo un ESB. Sin embargo, el ESB es un componente importante en una solución SOA, toda integración de sistemas pasa a través de él.
Como te habrás dado cuenta un ESB es sobre la comunicación, claro que con esto tenemos necesidad de más cosas como la trasformación, enrutamiento, orquestación, etc ... Vamos a ver en la práctica lo que son cada uno de estos temas y si necesita o no de todos.
Componentes básicos de un ESB
- Invocación: Se encarga de proporcionar apoyo a los protocolos de transporte de manera sincrónica y asincrónica.
- Routing: Responsable para el envío de la información para un lugar u otro, lo hace de un modo estático o dinámico. Podemos usar el enrutamiento basado en reglas con Drools por ejemplo.
- Mediación (Trasformación): Se encarga de proporcionar la transformación de protocolos, por ejemplo entrar en una http y salir en un SFTP.
- Mensaje: Se encarga de proporcionar el tratamiento, procesamiento y el refuerzo de mensajes. Por ejemplo, si lee un xml el ESB debe ser capaz de añadir o eliminar información de ese XML antes de llegar al destino.
- Orquestación / Coreografía: Se refieren a procesos complejos y BPMN / BPEL si no usamos BPEL no precisaremos de estas dos, muchas personas piensan que están obligados a usar estos dos en un ESB, y en muchos casos no existe tal necesidad.
Ciertamente nosotros necesitamos de seguridad, además porque SOA sin seguridad no existe! Podemos pensar en otras cosas como el monitoreo (BAM) y procesamiento de eventos complejos (CEP) y aquí ya estamos hablando de algo que está fuera del ESB, que no es su responsabilidad, si desea ver más información acerca de estos dos puede leer estas post:
¿Código de negocio dentro del ESB?
Al comienzo puede parecer una buena idea para poner su sistema dentro del ESB, pero creemos que no es una buena idea. Debemos hacer nuestros sistemas fuera del ESB y hacer como que el ESB va a atender su sistema y va a conversar con él, desarrollar el sistema dentro del ESB sólo crea más complejidad y acoplamiento.
¿Java Business Imtegration?
Esa es la JSR 208/312 para la implementación de SOA en Java. La especificación es simple y tiene pocos conceptos como: SE, BC, NMR. Vamos a hacer una pausa en la sopa de letras y vamos a ver qué significa cada sigla y para que sirven.
Binding Components
Son responsables de la comunicación con protocolos remotos y también deben normalizar / desnormalizar mensajes. Usamos un BC específico para cada protocolo con el que querramos conversar, como http, ftp, RMI, JMS, XMPP, etc ...
Service Engines
Son motores que proveen servicios de diversos tipos para la NMR. Algunos ejemplos de SE son los motores de reglas, motores de BPEL, motores de XSLT, los motores de scripting, EJB containers. Podemos utilizar el servicio de camel de apache para enrutamiento, por ejemplo.
Normalized Message Router
Básicamente estamos hablando del propio ESB en si la visión de JBI. Dado que la mediación es a través del ESB, la NMR proporciona transparencia de ubicación a los servicios también.
Una excelente solución de ESB
Hoy en día la mejor solución en términos de ESB para mí es ServiceMix de apache. ¿Por qué él usa Spring? No. ¿Por qué implementa JBI? No. ¿Por qué es todo plugable y puede remover lo que no quiera? No. Porqué ServiceMix responde a todas estas preguntas y muchas otras, y además que la solución está bien madura y funciona bien con Maven 2, que es otra gran ventaja.
Visión general de ServiceMix
La forma en que ServiceMix separa la lógica de la comunicación de la lógica de procesamiento es muy buena y todo eso a través de JBI. Lo bueno es que se puede distribuir de forma cargada con todo el soporte de Spring Framework o de manera stand alone, incluso con otro ESB. Podemos utilizar Drools con ServiceMix, esta integración ya está lista, así podemos exponer las reglas de enrutamiento para un analista de negocio o hasta el mismo usuario de un sistema.
¿Ahora tenemos SOA?
Todavía no. Podemos utilizar todos los recursos que hablamos en este post y todavía no tendrá SOP, pero eso no significa que no tengamos una buena solución. Esta solución es muy válida en los escenarios de integración de sistemas.
Bueno, siempre usaré un ESB ahora!
¡Nopes! Un ESB puede no ser la mejor solución a tu problema, deberíamos usarlo cuando tenemos varios sistemas que necesitan conversar de diferentes maneras y a veces están distribuidos a través de la web. Si sólo disponemos de 2 sistemas Java en nuestra empresa, consideremos la posibilidad de utilizar algo mas sencillo, como por ejemplo JMS.
Hablando de SOA, el contrato de los sistema no será definido por el ESB, la ESB solo será la manera que puede utilizar los contratos en las fronteras, pero no es pensando en él que debemos definir ese contrato. Para definir bien los contratos hay que pensar sobre la interfaz pública y y no sobre la interfaz privada, pero eso es otro post.