SOA en tiempos de crisis

Pero antes de decantarse por alguno de ellos, cada empresa debe evaluar cuidadosamente sus funciones y comprobar si la solución aportará valor a la compañía o por contra se convertirá en un obstáculo.

Al hablar de integración, estos ESBs ofrecen resultados similares a las ofertas comerciales, y tienen la ventaja de soportar los últimos estándares como JBI y contar con múltiples adaptadores para JDBC, SOAP, FTP, HTTP, POP3, TCP, UDP o incluso sistemas heredados como AS/400.

Además, las aproximaciones de código fuente abierto ponen al alcance de cualquiera los procesos de test y su documentación más actualizada de forma on line.

Sin embargo, alinear las necesidades de negocio con la infraestructura TI resulta esencial durante las primeras fases de implementación SOA, y ése es el principal escollo de los ESBs open source.

XML y Java
En este sentido, los profesionales TI no tendrán problema en trabajar con lenguajes XML y/o Java, pero los analistas y directivos de negocio no corren la misma suerte.

El personal de negocios normalmente demanda a la infraestructura tecnológica  un entorno visual para poder orquestar los procesos de negocio, efectuar cambios en tiempo real, ajustar los acuerdos de Nivel de Servicio (SLAs) o reemplazar unos servicios por otros.

Es así como los ESBs de pago se han centrado en la mayor flexibilidad de uso, apostando por soluciones ‘Plug & Play’ que simplifican la reutilización de servicios.

Por su parte, los ESBs open source proporcionan resultados similares, pero con la condición de que los usuarios tengan conocimientos y experiencia en XML y Java para poder utilizarlos correctamente.

Así por ejemplo, una compañía que pretende desplegar un sistema para recibir, validar y procesar pedidos a través de la web tendrá que lidiar con definiciones  XML y Java de los conectores, enrutadores y procesos de validación si se opta por una solución como Mule ESB.