La orquestación de servicios es
un modelo centralizado que permite realizar interacciones entre los servicios
web a través de una entidad que define la lógica de dicha interacción. Es
necesario precisar que SOA se caracteriza por implementar un esquema basado en
servicios interoperables, que se acoplan
débilmente desde sistemas ubicados en diferentes dominios del negocio para
lograr así un sistema empresarial único. En ese contexto, es precioso señalar
que implementar un sistema que cumpla con los principios SOA depende mucho de
una exitosa orquestación de servicios. En tal sentido, encontrar una plataforma
que soporte la orquestación de los servicios es una tarea crítica dentro de un
proyecto de integración.
Como bien sabemos, los servicios
individualmente no se programan para comunicarse con otros (al menos no
explícitamente), entonces es necesario que los mensajes entre los mismos, deban
intercambiarse de acuerdo a la lógica de negocio predeterminada. Para lograr
este cometido, existen patrones de integración empresarial (EIP: Enterprise
Integration Patterns), los cuales cuentan con un motor central de mensajería
para la integración de datos. Este motor se implementa a través de un Bus de
Servicios Empresariales (ESB: Enterprise Services Bus) el cual nos permite
enrutar, transformar y enriquecer mensajes. Cuando logramos una arquitectura
verdaderamente orientada a servicios, las nuevas aplicaciones no deben ser
reescritas, sino, se crean a partir de nuevas orquestaciones en los servicios.
En un alto nivel, la orquestación
de servicios y SOA son conceptos relativamente simples. Sin embargo, si no se
cuenta con la herramienta adecuada, se hacen muy difíciles de implementarlas.
En este contexto, ESB surge como una alternativa altamente demandada para la
orquestación de servicios dentro de un patrón de integración. Es así, como
surgen diversos estándares representados en productos que siguen el patrón ESB
para lograr una “integración orquestada”. En este escenario, hablamos de estándares
como BPEL o productos open source como Mule.
A continuación un resumen que
describe de manera acotada, cada uno de los productos mencionados.
BPEL
“Business Process Execution Language”. Es
un lenguaje utilizado en la composición de servicios web. Está diseñado bajo
XML y ejecuta un control centralizado de todos los servicios web diseñados.
BPEL contempla lógica de negocio y es uno de sus hitos, pues depende bastante
de este factor para que la composición y orquestación sean más eficaces. La razón
de ser de BPEL es definir procesos de negocio que interactúen con entidades
externas. Entre sus principales características tenemos:
-
Define una serie de conceptos de orquestación de
servicios web que pretenden ser usados por vistas internas y externas de un
proceso de negocio.
-
Provee de sistemas de control jerárquicos y
estilo grafico que permitan que su uso sea lo más fusionado posible.
-
Provee
funcionalidades de manipulación de datos
simples para definir datos de proceso y flujos de control
-
Usa servicios Web como la técnica para descomponer y ensamblar
modelos
Mule
Mule se presenta más como un “gestor
de eventos” y ofrece escalabilidad. Es decir que además de SOA su paradigma también
es EDA (Event Driven Arquitecture). Es un framework liviano que trabaja
nativamente con aplicaciones JAVA. Cumple con muchos patrones de integracion
definidos Gregor Hohpe y Bobby Woolf . El Proyecto Mule también tiene un
Contenedor Java Business Integration (JBI/JSR-208) llamado MuleJBI y se
distribuye con un IDE basado en Eclipse llamado MuleIDE, el cual es un set de
Plug-Ins para Eclipse que sirven para desarrollar, desplegar y gestionar los
proyectos. Entre sus principales características tenemos:
-
Manejea canales de comunicación llamados “end
points”
-
Incentiva la reutilización de aplicaciones
existentes
-
Acelera la integración de sistemas heterogéneos
-
Admite múltitud de formatos de mensajes: SOAP,
REST..
-
Mediación y enrutamiento de servicios:
Protección en el formato de los mensajes separándolos de la lógica de negocio.
Enrutamiento de los mensajes basados en reglas
-
Soporta diferentes lenguajes de programación:
Java, Groovy, Javascript, JRuby, etc.
-
Es opensource.
Conclusión
No es preciso definir cuál es la mejor opción para
orquestar arquitecturas SOA. En ese proceso intervienen muchos factores como
requerimientos funcionales y no funcionales, presupuesto, experiencia de desarrollo,
etc. Lo importante es saber identificar cuando usar cual y como usarlos para
poder crear una arquitectura escalable, de alta disponibilidad y que conserve
siempre la estructura SOA. Ello garantizará el éxito de una integración
empresarial.
No hay comentarios:
Publicar un comentario