domingo, 22 de mayo de 2011

Mecanismos de integración

En la publicación anterior escribí sobre los puntos a tener en cuenta a la hora de definir una integración entre sistemas. Ahora, voy a comentar, desde mi punto de vista y experiencia, los diferentes mecanismos que existen para resolver esta cuestión, y cual es la relación entre estos y los atributos de calidad anteriormente mencionados.
Antes de empezar, voy a dividir los mecanismos, solo por claridad en la comunicación, entre mecanismos puntuales y masivos. Los primeros son aquellos mecanismos que permiten intercambiar información entre un sistema y otro en forma puntual, digamos de una interacción a la vez (por ejemplo, la solicitud del alta de un cliente, o la consulta de tweets ingresados por un usuario el último mes). Los segundos permiten la integración entre dos sistemas intercambiando grandes volúmenes de información. Los primeros generalmente son utilizados para interacciones online, mientras que los segundos son utilizados para integración batch. Los primeros son generalmente sincrónicos (o el usuario los ve de esa manera), mientras los segundos son naturalmente asincrónicos.
Ahora, una vez establecida esta división, transcribiré en resumidas cuentas cada uno de los mecanismos.

Mecanismos puntuales
Web Services
Los web services son un mecanismo de integración basado en una colección muy amplia de protocolos y estándares, basados todos sobre los mismos estándares sobre los que funciona la web (aunque existen implementaciones de los mismos sobre tecnologías de mensajería). El principal protocolo y estándar en el que se basa es SOAP (Simple Object Access Protocol), que define el formato en que se intercambia la información, dividiendolo básicamente entre header (cabecera que permite configurar el transporte), y el body (que contiene los datos a transmitir). Otro estándar importante es WSDL (Web Service Description Language), que define la estructura del mensaje, estableciendo los tipos de datos, campos y estructura de información a transmitir, sumado a UDDI (Universal Description, Discovery and Integration) para el registro de servicios web.
Con el paso del tiempo, se sumaron otros estándares al stack, para cubrir diferentes funcionalidades o atributos de calidad. De esta forma, tenemos por ejemplo WS-Security, WS-Reliablemessaging, o WS-transaction, que cubrieron aspectos que fueron dejados de lado por la definición inicial de SOAP, aunque agregándole complejidad.
Desde mi punto de vista, es una buena alternativa para interoperabilidad en ambientes heterogéneos, siempre y cuando nos basemos en el estándar SOAP sin ningún adicional del stack WS-*, ya que estos últimos no fueron implementado de la misma forma por todos los vendors. Aunque, si los sistemas a integrar son desarrollados en la misma tecnología y vendor tecnológico, el uso del stack WS-* soluciona diferentes cuestiones que son necesarias tener en cuenta.
Con respecto a la relación con los atributos de calidad, si se aplican bien los conceptos de WS, este mecanismo de integración se encuentra muy a favor de la coherencia semántica, unificación de mensajes y reusabilidad (heredado de la orientación a servicios). En lo que respecta a interoperabilidad, esto es una promesa, que no siempre es bien cumplida y en diferentes ocasiones presenta sus dificultades. El rendimiento de las integraciones se ve menguado debido a lo verboso de los mensajes (se estima que del total de un mensaje WS, solo el 30% representa datos con significado funcional). En lo que respecta a robustez, escalabilidad, facilidad de administración y disponibilidad, los mismos dependerán mucho de las plataformas donde se implementen los servicios (ESB, Application Server, Web Server). En lo que respecta a los tests, tener el contrato (WSDL) separado de la implementación permite crear servicios "mockeados" que implementen la funcionalidad necesaria para realizar los tests, mientras que los contratos pueden verse como auto-documentados, un beneficio que da XML y el estándar WSDL a este tipo de integraciones.

Cuando utilizarlo:Debido a la carga en cuanto a performance, lo utilizaría en aquellos casos en los que se requiera seguridad, trazabilidad, y cuando la performance no sea un requerimiento fuerte. Si se requieren interfaces autodocumentadas, es la opción por la que se debe ir. También es apto en aquellos desarrollos donde se requieran facilidad de pruebas.

REST
Este mecanismo de integración, cuyas siglas significan REpresentational State Transfer, aparece como una alternativa a los web services, para integraciones basadas en la arquitectura WEB y HTTP como transporte. Es muy utilizado por los grandes jugadores de la WEB 2.0 (Facebook, Google, Twitter y otras lo utilizan para sus APIS).
REST presenta las integraciones basado en los recursos de los sistemas (principal diferencia con respecto a los web services, que se basan en funcionalidades), basándose en la arquitectura HTTP, e implementando los siguientes principios:
  • Identificación de recursos a través de URIs (Uniform Resource Identifier)
  • La manipulación de los recursos se realiza a través de sus representaciones, utilizando los métodos HTTP de manera explícita (GET - consultar un recurso, POST - crear un recurso, PUT - modificar un recurso, DELETE - eliminar un recurso), y basándose en la información obtenida de la representación de los recursos.
  • Mensajes auto-descriptivos, de forma tal que cada mensaje tenga la información necesaria para procesarlo (por ejemplo, estableciendo su MIME type y gestión de cache)
  • La hypermedia se usa como motor de gestión de estado. Si bien es un mecanismo de integración stateless (sin estado), la interacción entre consumidor y proveedor se realiza a través de hyperlinks o hypertext presente en la representación.
Como se basa en un estándar ampliamente aceptado (HTTP), intercambiando mensajes JSON (Java Script Object Notation), XML o YAML(Yet Another Markup Language), una de sus principales ventajas son la interoperabilidad, reusabilidad, unificación de mensajes y coherencia semántica (heredados de la orientación a servicios), sumado a un gran soporte de la escalabilidad (heredado de HTTP). Representa una gran mejora en lo que respecta a performance comparado con los web services, ya que disminuye la cantidad de datos innecesarios y sin significado de negocio. Otra vez, la robustez, facilidad de administración y disponibilidad, los mismos dependerán mucho de las plataformas donde se implementen los servicios (web server). La seguridad es una de sus falencias, ya que como mecanismo básico tiene lo soportado por HTTPS (Secure HTTP), requieriendo agregados como proxies o firewalls para mayor complejidad (por ejemplo, un appliance de HW como Datapower podría cubrir estos requerimientos). El formato de mensaje, si bien no es tan autodocumentado como en el caso de web services, da un cierto soporte a la documentación y comunicación, siempre y cuando se establezcan criterios claros entre las partes.

Cuando utilizarlo: Este mecanismo es una muy buena alternativa a web services. Es fácil de usar cuando los recursos del sistema proveedor están claramente identificados, y no se tengan grandes requerimientos en cuanto a seguridad, trazabilidad y transaccionabilidad (ya que agregar estas características complejizarían el desarrollo). Si lo que se requiere es performance e interoperabilidad, es una excelente alternativa.

XML over HTTP
Este mecanismo se podría ver como un subconjunto de REST, ya que se basa en HTTP como transporte, y para la definición de los datos sensibles al negocio se establece XML para representar los mismos.
La única diferencia entre REST y este mecanismo, es que no cumple los principios establecidos por REST, ya que por ejemplo las interfaces o servicios expuestos pueden no estar representados como recursos, ni hacer uso de URIs para identificarlos.
También puede verse como una simplificación de los Web Services, ya que si bien utilizan XML para la transmisión de datos, no supone la carga de SOAP y WSDL.
Tiene, entonces, una mejor performance que los web services, pero no cuenta con la ventaja de ser autodocumentado, ya que no se requiere un estándar de definición de protocolos, y los mensajes muchas veces son definidos previamente entre las partes. La interoperabilidad estará dada, mientras se mantengan los acuerdos entre las partes, pero nada de los protocolos estándar utilizados juega en contra de esta calidad.
Otra vez, la robustez, facilidad de administración y disponibilidad, los mismos dependerán mucho de las plataformas donde se implementen los servicios (web server, application server).
La seguridad estará dada por las plataformas subyacentes, mientras que la claridad de documentación y comunicación no es una característica de este mecanismo.

Cuando utilizarlo: No recomendaría utilizarlo, ya que es una versión mala de REST. En caso de aparecer como una alternativa, evaluaría seriamente el uso de REST antes que este.

RSS
RSS (Really Simple Sindication), es básicamente un estándar XML para sindicar o compartir contenidos en la WEB. Su principal uso es la difusión de información a usuarios que se subscriben a una fuente de contenidos.
Su principal uso es la lectura de noticias o novedades en sitios web o blogs, mediante herramientas "agregadoras" (web browsers, Google reader, Bloglines).
La arquitectura que implementa este mecanismo es básicamente un publish-subscribe, en el cual un ente publica información, que interesa a uno o mas consumidores, los cuales no son conocidos por el publicador.
Es muy útil para sistemas que requieran compartir información multimedia, o solo-texto, a diferentes aplicaciones implementadas en diferentes tecnologías, y desconocidas. No es simple realizar este tipo de integraciones, pero existen frameworks como RSS 2.0 (en C#), o RSS Framework (en PHP).
No es un mecanismo que este acorde a la comunicación entre personas o documentación, y cuyo soporte a la performance, disponibilidad, robustez dependerán del tipo de desarrollo implementado.
Por su poca o nula políticas de seguridad, debe usarse en aquellos casos en que la información sea pública y poco sensible.

Cuando utilizarlo: Implementarlo en aquellos casos donde se quiera dar a conocer información que no requiera demasiada seguridad, y que interesa a diferentes consumidores desconocidos, distribuidos en internet.

LDAP
LDAP (Lightweight Direct Access Protocol), permite en su utilización mas común la comunicación con un directorio de identidades, utilizando esta integración para autenticación y autorización.
Pero, por la forma de estructuración basada en una entidad principal, diferentes roles o características de dichas entidades, y dependencia entre entidades, es muy útil en algunos casos. Por ejemplo, en una empresa proveedora de internet, podría tenerse una estructura por ubicación geográfica (AMBA, NORTE, SUR), dentro de cada uno podría establecerse una división por tipo de cliente (gran cuenta, individuo), de los cuales se desprenderían los diferentes servicios que tiene activo el cliente, para su uso por la red, o los sistemas de CRM. ¿como se conectarían estos sistemas con el repositorio? a través de LDAP.
Tiene un uso muy acotado a ciertas funcionalidades, pero es bueno tenerlo en cuenta para no realizar un desarrollo importante teniendo herramientas que puedan resolver la problemática. Las herramientas van desde componentes software pagos (Microsoft Active Directory, Oracle Identity Management) a aplicación gratuitas (Microsoft ADAM, open LDAP).
Es aplicable solo a intranet, debido a la simpleza del protocolo. Las calidades de tiempo de ejecución dependerán de la solución de directorios seleccionada, mientras que las calidades de comunicación no son muy bien implementadas.

Cuando utilizarlo: En aquellos casos en que se requiera implementar una funcionalidad basada en una entidad, que permita establecer una estructura jerárquica centrada en la misma, estableciendo características en dicha entidad, implementar un motor LDAP y realizar la integración mediante dicho protocolo.

Sockets TCP
El protocolo TCP basa su fortaleza en la conexión de sistemas a bajo nivel, siendo uno de los protocolos fundamentales de internet. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el orden en que fueron transmitidos.
Al ser un protocolo de bajo nivel, las funcionalidades que soporten las calidades de tiempo de ejecución deben implementarse desde cero, siendo una solución poco simple de desarrollar. No es una buena solución para cuestiones asociadas al diseño de interfaces (salvo un gran esfuerzo de estandarización y acuerdos entre los participantes), ni para documentación.
Es uno de los mecanismos que mejor performance tiene, siempre y cuando el mensaje a enviar sea simple y no verboso (recordemos que los web services, por debajo, hacen uso de TCP).
La interoperabilidad puede verse como un fuerte, ya que este protocolo es aceptado por aplicaciones que van desde C o C++ hasta Ruby, .NET o Java.

Cuando utilizarlo: Cuando se requiera integraciones simples entre diferentes sistemas, sin requerimientos de seguridad, y cuando la performance sea una necesidad imperiosa.

CORBA
CORBA (Common Object Request Broker Architecture) es un estándar que permite el desarrollo de sistemas distribuidos facilitando la integración mediante invocación a métodos remotos, siendo los sistemas orientados a objetos.
Definido por el OMG (Open Management Group), establece las APIs, los protocolos y mecanismos necesarios para asegurar la interoperabilidad entre aplicaciones. Básicamente lo que hace es transformar la especificación de los servicios en cada tecnología a un IDL establecido y estandar, realizando las transformaciones necesarias. Existen implementaciones estándares para ADA, C, C++, Smalltalk, Java, Python, Perl y Tcl. Existen también proyectos como Remoting.Corba, que intenta integrar aplicaciones .NET con CORBA, o Corba-Ruby para aplicaciones en Ruby.
Su gran fuerte y objetivo es la interoperabilidad, aunque ya no se ve mucho en los nuevos desarrollos, ya que producen un detrimento de la performance y no siempre es tan independiente como se dice de la tecnología subyacente.
Produce dependencia entre las aplicaciones, ya que hace que un sistema conozca los objetos de otro sistema, lo que no es nada bueno para las calidades de diseño, y en tiempo de ejecución tiene diferentes cuestiones que depende de la tecnología en la que se encuentre implementada cada una de las aplicaciones involucradas.

Cuando utilizarlo: Cuando exista una aplicación CORBA que deba integrarse con otros sistemas.

Otros mecanismos
Existen otros mecanismos, que por su poca importancia, o implementaciones no vale la pena bajar a detalle. Estos son por ejemplo Etch, creado por CISCO como un reemplazo a los web services, sin demasiado éxito; o DCOM (Distributed Component Object Model), tecnología propietaria de Microsoft ampliamente usada en VB 6, caida en desuso en nuevas implementaciones.

Mecanismos masivos
Una problemática que se tiene a la hora de decidir utilizar este tipo de integraciones es la definición de cual es el volumen de información que me hace utlizar un medio masivo y cuando usar un online. A los efectos prácticos, vamos a decir que cuando la necesidad de obtener la información es puntual, o puede deberse a una única operatoria de negocio en un corto lapso de tiempo, y cuando dichas operatorias pueden darse desde diferentes fuentes - o usuarios, en un mismo momento, utilizaremos medios puntuales. En cambio, cuando las solicitudes o información provenga en un mismo momento, en forma masiva y en bloques, utilizaremos mecanismos masivos.

ETL
ETL (Extract, Transform and Load) se refiere al proceso implementado para extraer información de una fuente de datos, transformarla, reformatearlos, limpiarlos e introducirlos en otro medio de almacenamiento (DataMart, base de datos, archivos).
Es ampliamente usado en DataWarehouse, pero es muy útil para realizar integraciones que requieran un movimiento de un volumen grande de información.
Desde el punto de vista de diseño son buenas alternativas, ya que se pueden reutilizar los componentes de extracción, transformación y carga, sirviendo los mismos para definir diferentes flujos de integración, aunque hace que sea necesario conocer la estructura de datos de los sistemas origen y destino, lo que hace muy grande el acoplamiento. La performance dependerá de la forma en que se implemente, siendo muy buenas estas soluciones para asegurar robustez, seguridad, disponibilidad e interoperabilidad.
En cuestiones de diseño no es tan bueno, ya que pocas soluciones son auto-documentadas.
Existen en el mercado diferentes soluciones que implementan este tipo de integraciones, como Informática PowerCenter, Oracle WareHouse Builder, o Microsoft SQL Integration Services.

Cuando utilizarlo: Cuando se requiera integración mediante movimiento masivo de información entre diferentes plataformas heterogéneas utilizando diferentes fuentes de datos, y en los que no sea inconveniente el acoplamiento entre sistemas (cabe aclarar que las soluciones de ETL del mercado tienen la capacidad de desarrollar conectores, lo que minimiza el acoplamiento).

Mecanismos híbridos
Colas / Mensajería

Un sistema de mensajería permite la comunicación entre aplicaciones de forma indirecta. Esto se logra mediante el envío de mensajes a un administrador de mensajes, al cual están asociadas las aplicaciones, y es este último quien se encarga de administrarlos y distribuirlos según diversas configuraciones.

N

o es necesario especificar una aplicación de destino a la hora de enviar mensajes, sino que especifica el nombre de una cola.

Una aplicación puede tener una o mas colas de entrada y una o diversas colas de salida.

No es necesario preocuparse por de la tecnología existente en la aplicación destino, o si la aplicación destino no se encuentra disponible (en el caso de los mensajes asincrónicos), sino que el motor de colas se encarga de reenviar el mensaje si la misma se encuentra detenida o bien de iniciarla dependiendo del caso.

Un mensaje consta de dos partes básicas: el header (que contiene información de control que facilita el funcionamiento del administrador), y la data (información a intercambiar entre las aplicaciones).

En la implementación básica, una aplicación entrega un mensaje al administrador (motor) de mensajería, el cual mantiene el mensaje vivo hasta que llegue su tiempo de expiración, o hasta que el consumidor del mensaje lo tenga en su poder.

La integración vía mensajería se basa en la robustez mediante la persistencia de los mensajes enviados, la gestión de prioridades de entrega (por defecto, el mecanismo de entrega es FIFO, pero existen formas de adaptarlo), o expiración de los mensajes (ya que los mismos no pueden estar presentes en la infraestructura del administrador por siempre).

La implementación de colas de mensajería aseguran un bajo acoplamiento entre los sistemas (ya que implementa un modo de comunicación asincrónico, siendo el administrador quien se encargue de entregar el mensaje), al mismo tiempo que asegura la interoperabilidad (siempre y cuando se utilicen motores de colas estándares, estándares de facto o con conectores multi-tecnológicos, como IBM MQ, o implementaciones JMS como ActiveMQ o RabbitMQ).

Las calidades relacionadas a diseño dependerán del buen criterio que se implemente para crear las integraciones, lo mismo que sucede con las cuestiones de comunicación. No es una solución buena para el test.

Existen diferentes motores en el mercado, pasando de los propietarios (Microsoft MSMQ), a los estándares "de facto" (IBM MQ, Oracle AQ), y los estándares tecnológicos (Rabbit MQ, Apache Active MQ).


Cuando utilizarlo: Siempre que se pueda, y cuando el manejo de mensajería asincrónica no sea una contra (ya que, por ejemplo, se requiera conocer en el momento la entrega del mensaje y su respuesta). Tener en cuenta las tecnologías involucradas para seleccionar el motor de colas.


Archivos
La integración a través de archivos es una de los mecanismos mas utilizados desde hace ya mucho tiempo. Se basa en el acuerdo entre las partes involucradas acerca del contenido y formato del archivo, para que luego el proveedor de la información genere un archivo basado en el mismo ante cada necesidad de integración, y lo deposite en un repositorio pre-acordado. Luego, el o los consumidores de la información proceden a la lectura, interpretación, y actuación en consecuencia de la información contenida.
Este mecanismo de integración permite manejar la independencia entre aplicaciones, siempre y cuando los datos involucrados en los archivos no incluyan información relacionada a la implementación de un determinado sistema, y asegura la robustez y disponibilidad de la información (aunque la interoperabilidad esta asegurada). La seguridad es manejada a través de permisos en los repositorios, y mecanismos de encriptación (como PGP - Prety Good Privacy). No es bueno para documentación, ya que no es un mecanismo auto-documentable, salvo en los casos en que se utilicen estándares de integración masiva, como por ejemplo EDIFACT (Estandar desarrollado por la ONU para intercambio de documentos comerciales).

Cuando utilizarlo: Siempre que se pueda usar un ETL, lo priorizaría ante este mecanismo. En caso de no poder utilizarse ETL (por costos, por ejemplo), usarlo en cualquier integración masiva que no pueda reemplazarse por colas.

Base de datos
No voy a explayarme mucho sobre el uso de una base de datos para integrar varias aplicaciones. Solo voy a decir que, si bien es simple de realizar (ya que la conexión a base de datos es lo segundo mas estandarizado luego de los archivos), y que es un mecanismo robusto y seguro, no recomiendo su uso, ya que genera una dependencia muy fuerte entre los sistemas involucrados, hecho que luego es muy difícil de cambiar. Cualquier integración que se piense a través de base de datos, se puede reemplazar por los mecanismos antedichos.

0 comentarios:

Publicar un comentario