Hoy en día podemos encontrar gran cantidad de soluciones ESB y BPMN Open Source, la competencia es grande y las organizaciones están realizando grandes esfuerzos para mejorar su escalón frente a la competencia. Nuevas funcionalidades, flexibilidad, robustez, etc. son unas de las características que intentamos encontrar en el software adquirido, pero, ¿Cúal es la combinación perfecta para satisfacer nuestras necesidades?¿Qué nos aporta un ESB o un Workflow Process Designer? ¿Cúal es la arquitectura idonea para este proyecto? Son unas de las preguntas más frecuentes al inicio de un SOA project.

El objetivo de este post no es mostrar las diferentes posibilidades que se pueden encontrar en Internet sino explicar en que caso y para que puede servir la adopción de un ESB junto con un BPM. En todo caso, en los siguientes dos links se pueden encontrar comparaciones válidas para una posterior elección: Soluciones ESB y BPM.

Un Enterprice Service Bus (ESB) puede tener varias funciones dentro de una arquitectura pero la mayoría de las veces se utiliza como “punto de unión” entre diferentes sistemas o módulos, es decir, es capaz de enrutar mensajes entre distintos objetos, estandarizando el protocolo de comunicación entre ellos. Ejemplo: El cartero (ESB) puede repartir cartas en los portales/casas (módulos) pudiendo construir más casas en el pueblo, eso sí, en caso de que esta nueva casa quiera comunicarse con el resto deberá tener un número y un buzón, es decir, debe avisarle al ESB y seguir un patrón. Esto, aporta gran escalabilidad y flexibilidad.

Una solución BPM en cambio, es simplimente un software/librería gráfica para el modelado de procesos de negocio o workflows. Muy parecido a los diagramas de actividades y maquinas de estados del estandar UML de OMG, sirve para dibujar nuestros procesos. ¿Es un enrutardor como el ESB? La respuesta es si pero con más funcionalidades, es decir, el ESB es capaz de ejecutar una serie de tareas secuenciales pero no permite implementar uniones, decisiones y otro tipo de tareas propias de un BPM. ¿No se solapan entre sí? Se debe tener claro para que queremos utilizar cada uno de ellos. Por ejemplo, podemos utilizar un BPM para la definición de procesos de negocio pero estos a su vez se comunican con tareas del ESB (tareas secuenciales, un service pipeline por ejemplo) y este último es capaz de traducir los distintos mensajes y transformarlos.

Resumiendo, no son incompatibles, pero pueden llegar a serlo en caso de uso inapropiado. Por otro lado, si se tiene claro para que se necesita cada uno de ellos pueden aportar gran escalabilidad, agilidad y robustez a una arquitectura SOA.

Anuncios