Arquitectura orientada a servicios. Parte 1: integración de aplicaciones y orquestación de servicios

Actualmente, las empresas necesitan explotar sus intangibles: cultura, capacidad de aprendizaje y procesos, como ventaja competitiva para lograr un mayor beneficio de negocio. A lo largo de los años, ha existido un abismo entre las necesidades de las empresas por adaptarse a los cambios que el mercado demanda, y la facilidad de cambio en las aplicaciones para cubrir los nuevos procesos de negocio. Se han creado ecosistemas tecnológicos con sistemas legados, portales, ERPs, CRM, call centers y SCM, etcétera; en un intento por resolver el problema del cambio en demanda. Sin embargo, no ha sido suficiente, ya que la colaboración y la capacidad de cambio de los sistemas es tecnológicamente limitada, y de esta manera han surgido las islas de automatización donde la colaboración requerida se resuelve por procesos manuales de difícil adaptación.

Arquitecturas Orientadas a Servicios
Con el surgimiento de XML se han desarrollado estándares encaminados a resolver la interoperabilidad de los sistemas, como los servicios Web con SOAP. Esto permite que las aplicaciones expongan su funcionalidad como un conjunto de servicios reutilizables y preparados para colaborar entre ellos. También surge la necesidad de independencia de proveedor, abordar la diversidad tecnológica y protección a la inversión existente en las aplicaciones empresariales. Este es el concepto clave de SOA: exponer la funcionalidad de las aplicaciones con servicios estándares con XML que se puedan utilizar de forma ágil para lograr la flexibilidad tecnológica demandada por la dinámica de los procesos de negocio.

Los servicios Web con SOAP proporcionan un mecanismo estándar para la integración de las aplicaciones ampliamente adoptado en la industria. Sin embargo, esto no es suficiente. También se requiere de una nueva generación tecnológica que permita abordar la colaboración inteligente de las aplicaciones que requieren los procesos de negocio para integrar tecnología y personas. La respuesta de la industria de TI es la creación de nuevas herramientas que ayuden a incrementar la madurez de las empresas a través de una mejor capacidad de los procesos que realizan.

Cabe resaltar que SOA no es un componente tecnológico que pueda ser adquirido como una sola licencia, realmente es una estrategia tecnológica basada en servicios que permite a las empresas construirla de acuerdo a sus necesidades.

Las nuevas tecnologías se han diseñado en capas con funcionalidad definidas y encaminadas a resolver necesidades específicas:
1. Integración de aplicaciones y orquestación de servicios.
2. Gestión de procesos de negocio.
3. Integración de la información con una vista única.
4. Nuevas aplicaciones.
5. Metodología.
6. Modelo de gobierno.

En este artículo hablaremos de la integración de aplicaciones y orquestación de servicios. El resto de los temas serán abordados en subsecuentes oportunidades.

Integración de Aplicaciones y Orquestación de Servicios
A lo largo de los años las empresas se han apoyado en fuertes inversiones en tecnología y aplicaciones como soporte de los diferentes procesos de negocio. Los procesos son llevados a cabo entre diferentes áreas de las empresas donde la integración se ha llevado a cabo mediante personas o intercambio de documentos entre las mismas. Una consecuencia de esta necesidad es la latencia de la información, es decir, que existe aquella información en un área que es requerida por otra para tomar alguna decisión importante. Con esto queremos decir que la integración de los sistemas siempre se ha llevado a cabo a lo largo de los años.

El problema inicial es que la mayor parte de los sistemas, tradicionalmente, no fueron pensados en integrarse o colaborar, ni preparados para proporcionar funcionalidad en Internet. Esta brecha ha sido solucionada de diferentes formas en las empresas:
• Programación de interfases que puedan extraer la información de las aplicaciones y la puedan depositar en un formato o archivo intermedio que pueda ser tomado por la aplicación destino. Generalmente estas interfases dependen del lenguaje con que se programan. Si se tiene que transmitir la información por la red, se tiene que programar la interacción a bajo nivel o se realiza el intercambio por protocolos de transferencia como el FTP. También se deben resolver en la interfase programada, las diferencias de plataformas y transformación de la información. Las conexiones que se tienen son punto a punto.

• Middleware orientado a mensajes que proporciona un API estándar en cada una de las plataformas que resuelve sus diferencias. Sin embargo, todavía es necesario programar con su API. La ventaja sobre la programación de interfases en la estandarización de la integración bajo la visión con un solo método e independiente de lenguaje. La unidad de intercambio de información es un mensaje que contiene un buffer donde residen los datos. Durante la transferencia de datos no existe inspección sobre los mismos, este middleware sólo se encarga de asegurar la entrega a la aplicación destino, la transformación de la información todavía se tiene que programar en cada una de las aplicaciones integradas.

• Broker de mensajes que consiste en un middleware inteligente que contempla la inclusión de herramientas para elaborar mediante flujos de intercambio de información. En este nivel de integración es posible inspeccionar el contenido para cada uno de los mensajes y, con base en el mismo, aplicar características de transformación de datos, reglas de negocio y ruteo basado en su contenido. La interacción con las aplicaciones se basa en adaptadores que por un lado son capaces de comunicarse con la API de la aplicación y, por otro, generar un mensaje canónico que puede integrarse al ambiente; es posible tener reuso de componentes de integración, siempre y cuando no se salga del ambiente del Message Broker.

Se han desarrollado un mundo de herramientas que proveen esa funcionalidad, sin embargo, aunque proporcionaban ambientes distribuidos sobre la red y eliminaban las necesidades de programación, la comunicación entre cada uno de los componentes era propietaria, por lo que se dependía de un solo proveedor para enriquecer las ofertas. Hay quienes llaman a estos ambientes de integración aplicaciones legadas en la integración.

• Bus empresarial de servicios es la respuesta a las deficiencias de los Message Brokers. Se tienen las ventajas de transformación de datos, reglas de negocio, ambiente distribuido, ruteo basado en contenido, adaptadores, etc. La diferencia fundamental es que se basan en XML en la representación de los datos en los mensajes y la interacción se lleva a cabo mediante servicios Web, lo que incorpora una fuerte estandarización entre cada uno de los componentes que proporciona la flexibilidad de utilizar el proveedor que se requiera Esta capa está orientada al intercambio de información.

• La integración bajo el enfoque de arquitecturas orientadas a servicios permite utilizar componentes de las capas anteriores bajo estándares como XML y Servicios Web con un enfoque total que permita abrir la información de los sistemas como soporte a los procesos de negocio bajo un objetivo de negocio. La diferencia con las capas anteriores es que se dedican a resolver la integración desde el punto de vista de intercambio de datos y resolver problemas técnicos.

Los servicios Web son creados para exponer funciones de negocio en un formato y mecanismos estándar a diferentes niveles de granularidad. Por ejemplo, pueden ser necesarios servicios Web de transacciones puntuales de aplicaciones legadas, y por otro lado, necesitamos componer un nuevo servicio que requiera la invocación en secuencia de los servicios Web anteriores, esto es la orquestación de servicios, y permite crear servicios Web inteligentes y de gran valor coordinando; los servicios Web puntuales, lo que se conoce como servicio orquestado.

Desde un punto de vista lógico, la integración de las aplicaciones puede ser llevada a cabo de tres formas: sesión, transacción y datos. La integración de sesión se lleva a cabo mediante el uso de la funcionalidad que se obtiene de la navegación de la funcionalidad. La integración de transacción consiste en llamar directamente las transacciones existentes de las aplicaciones mediante un API oficial. Finamente la integración de datos se lleva a cabo con las fuentes directas de la información a partir de las bases de datos mediante los APIS de los manejadores de las bases de datos, ODBC o JDBC.

La integración de sesión claramente ofrece un gran valor en aquellos escenarios donde no se cuente con un API oficial de integración. Este tipo de integración es en un solo sentido. Por ejemplo, las aplicaciones de z/OS pueden ser expuestas como servicios Web pero no pueden participar como consumidores de otros servicios. También encapsulan generalmente la funcionalidad existente que cuenta con una interfaz de usuario o una rutina que permita llamarla.

En otros escenarios, las aplicaciones se encuentran bien estructuradas en capas de presentación, negocio y datos. Idealmente las transacciones que contienen lógica de negocio pueden ser llamadas desde SOA mediante servicios Web. La integración de transacciones se puede hacer bidireccional y asume que las aplicaciones se encuentran bien estructuradas, en caso contrario, deberán someterse a reingeniería. La funcionalidad de las aplicaciones expuesta puede ser tan puntual que es necesario utilizar la orquestación de servicios.

La integracion de datos se presenta cuando es necesario acceder a la información que almacena una aplicación, sin requerir de su lógica de negocio. Los retos a vencer son la encapsulación de los datos requeridos en sentencias SQL o que se puedan ejecutar procedimientos almacenados; el estándar de conectividad es generalmente JDBC o ODBC. Sin embargo, al acceder directamente a los datos, hay que tener en cuenta que se puede cometer errores de interpretación de datos, además de que se están saltando las reglas de validación e integridad de éstos.

Conclusiones
Cuando adoptamos la integración de aplicaciones con los estándares SOA nos permite preparar la estrategia estandarizada tecnológicamente que pueden convivir con cada una de las otras capas que discutiremos en artículos posteriores. Además de obtener flexibilidad en la elección de aquellos componentes tecnológicos y proveedores que más se adapten a su ecosistema tecnológico y necesidades que permitan por un lado proteger la inversión actual y, a la vez, potenciar sus procesos para lograr la agilidad de respuesta de la tecnología demandada por los procesos de negocio.