Integración “a la carte” – Nivel de Presentación

 Comenzando  a detallar los niveles de la serie bosquejados en un post anterior, nos toca en esta ocasión el Nivel de Presentación. Este nivel se adecúa a escenarios donde las aplicaciones a integrar no ofrecen acceso directo a sus capas interiores (si es que las tienen). Es un caso típico de las aplicaciones legadas (legacy systems) o aplicaciones sobre los que no tenemos, practicamente, acceso ni a su código fuente, ni a su diseño, ni incluso al equipo (sea o no externo a la organización) que lo mantiene

En concreto, esa aplicación o sistema es una "cosa", un "ente" que está ahí, que conocemos su interfaz de usuario (user interface o UI) pero no conocemos a su interior. La caja es negra. Por consiguiente, a esta aplicación la podremos acceder por ese único lugar conocido: por la UI

El beneficio de este approach es que no es invasivo respecto de las aplicaciones que van a ofrecer funcionalidades (en integración decimos que un sistema consume información o procesos que otra información ofrece o expone). Respecto de los otros niveles de integración mencionados al comienzo de la serie, esa característica podría darse o no dependiendo de la aplicación. Pero acá se da siempre

Como contra, debo destacar que si realmente no tenemos control alguno del sistema proveedor, éste podría cambiar su UI, provocando incompatibilidades en el esquema de integración. Campos que cambien de nombre, posición o contenido semántico, campos que se agreguen o que se saquen, y cualquier otra alteración en aquello que creíamos que era lo único que conocíamos, ahora quizás sea algo más de lo que ignoramos
Al respecto, habrá que analizar antes de adoptar este nivel de integración, qué tanto nivel de anticipación tenemos respecto de futuros cambios en la UI, y en qué medida esa integración es crítica para la organización (la eficiencia operacional quedaría severamente afectada). Por ejemplo, en una aplicación departamental, dentro de nuestra organización (escenario EAI), podríamos ser anunciados de que la interfaz esté por sufrir modificaciones, de modo de planificar actualizaciones en el esquema de integración (y quizás, negociar los cuándos de los cambios)
En una aplicación externa a la organización (escenario B2B), ese nivel de anticipación sólo estaría garantizado por un contrato o algún otro instrumento legal
Casi que sonaría que es más factible elegir integración a nivel de Presentación en EAI que en B2B. Curiosamente, no obstante, en escenarios EAI las posibilidades de tener acceso e incluso influenciar en aplicaciones más allá de sus UI’s es más alta, y eso eleva las chances de integrar por los niveles de Proceso, Dato o Comunicación (el resto de la serie)

Pasemos a ver las estrategias para integrar a este nivel

Estrategia I – Portales
Se trata de contenedores que permiten consolidar en una interfaz de usuario única la agregación de las interfaces originales de las partes integradas. Ofrecen como ventaja un manejo unificado de los contextos de las aplicaciones embebidas. Un beneficio inmediato que esto trae aparejado es que cierta información de salida de algunas vistas puede ser capturada y usada como datos de entrada en otra de las vistas, brindando productividad al proceso de carga de datos y de obtención de resultados

Esto a dado lugar a nuevos rangos de productos: los servidores de Portal, que consolidan aplicaciones Web; y contenedores análogos para aplicaciones de escritorio (estos últimos evolucionando en forma incipiente debido a la alta demanda de soluciones para CRM (Customer Relationship Management) o Call Centers (mesas de ayuda telefónicas), donde hay que consolidar vistas de clientes a partir de un número amplio de aplicaciones)

De la margen web, podemos destacar a Windows SharePoint Services, una pieza integrante de Windows Server 2003. Una variante más robusta, con más prestaciones aunque no incluída en el sistema operativo es Microsoft SharePoint Portal Server, un portal de colaboración más alineado a la estrategia de manipulación de información (information working) de Microsoft Office. Este link explica la relación entre ambos, en tanto que este otro muestra escenarios favorables a cada uno

Portales "de lado cliente", vale la pena mencionar el recientemente lanzado Composite UI Application Block que el comité de Patterns & Practices liberó en Diciembre pasado. Vale la pena echar un vistazo por lo bien documentado, y los talleres que se provéen para aprenderlo y dominarlo

Estrategia II – Raspado de Pantalla (Screen Scraping)
Consiste en simular la intervención humana sobre una interfaz de usuario ejecutada en background. Normalmente encontramos esta técnica presente en emuladores de terminal, o también en API’s de programación que permiten interceptar secuencias de datos (data streams) previo a su despliegue
En esta estrategia podría tornarse compleja la simulación de la lógica de navegación e inclusive el manejo de la sesión en cada interacción

Microsoft no tiene una biblioteca separada para aplicar esta estrategia, si bien una solución conocida como Microsoft Customer Care Framework (CCF) la trae implementada y lista para aplicar

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s