Integration_logo

Afortunadamente tenemos muchas opciones para implementar SOA en la empresa. Algunas de estas opciones son de pago y pertenecen a los grandes fabricantes de software como IBM o Oracle. Por otra parte, hay otras soluciones que pueden servir en determinados escenarios y que  son completamente gratuitas.

Así, puestos en la tesitura de tener que buscar una solución que nos sirva a nuestras necesidades y situación. ¿Qué aspectos deberíamos mirar?

Algunos de los criterios de comparación entre las distintas alternativas, de manera esquemática, podrían ser los siguientes:

  1. Conceptos básicos y arquitectura
  2. Capacidad de realizar tests
  3. Facilidad del despliegue
  4. Popularidad o índice de adopción del producto en la comunidad
  5. Soporte comercial
  6. Soporte de herramienta de desarrollo integrada (IDE)
  7. Manejo de errores
  8. Monitorización
  9. Lenguaje específico de dominio de integración (DSL)
  10. Número de componentes para interfaces, tecnologías y protocolos
  11. Extensibilidad

Evidentemente para realizar una comparativa hay que poner el foco en aquellas características distintivas de las alternativas analizadas. Y en estas alternativas disponibles quiero centrarme en lo que se conocen como «frameworks de integración». Que son son soluciones de más bajo nivel que las suites SOA de los grandes fabricantes pero que pueden perfectamente satisfacer nuestras necesidades en muchos de los escenarios más habituales.

Un framework de integración se caracteriza por lo siguiente:

  1. Implementación de los patrones de integración empresariales (EIP)
  2. Modelo consistente de integración y arquitectura de mensajes para dar soporte a diferentes tecnologías.
    Este tipo de soluciones tienen el mismo concepto de “flujo” de integración aunque se llamen con diferente nombre: “route”, “component” o “adapter”
  3. Son ESB “ligeros” frente a los ESB “pesados” de Oracle o IBM. En todos los casos, su uso se “reduce” a incorporar unas cuantas librerías de código a nuestro desarrollo de integración. Por lo tanto son capaces de ejecutarse en cualquier entorno: servidores de aplicaciones, batch, aplicaciones de escritorio, etc.
  4. Todas las opciones son open source. Y todas disponen de una comunidad de desarrolladores (usuarios) viva y dinámica que constantemente están probando el producto y dando feedback. Se dispone de documentación, blogs, libros, etc. Etc.
  5. Soporte de entorno integrado de desarrollo (IDE). Incluso disponen de editores visuales de los flujos o rutas de integración
  6. Características necesarias para su uso en la empresa como manejo de errores, test automáticos, transacciones, ejecución en paralelo con multi hebra, escalabilidad y monitorización

En cuanto a las diferencias entre las alternativas estudiadas, de manera resumida, serían las siguientes:

  1. Número de tecnologías soportadas. Es decir, cuantos «conectores» tenemos a nuestra disposición de caja. Para invocar a servicios SOAP y REST, invocación a SQL y stored procedures, colas, etc. etc.
  2. Lenguaje específico de dominio de integración. Es decir, como se plasma el flujo de integración. Puede ser mediante un XML con un espacio de nombres propio o puede ser en código java.

Afortunadamente, dentro de la oferta de soluciones de frameworks de integración tenemos varias opciones. Las más conocidas son estas dos:

Así pues, y respondiendo a la pregunta del título, creo que en muchos escenarios dentro de una empresa, e incluso en todos los casos de determinadas empresas, es suficiente con tener un framework de integración en lugar de un complejo suite SOA. La conclusión de todo esto, sería que, al menos, antes de adquirir un determinado producto analicemos cual es nuestra situación. No siempre nos conviene comprar lo más caro…