Como es habitual, me toca asistir a muchas reuniones para revisar, evaluar y proponer soluciones para la integración entre los sistemas del cliente y los productos de Paperless. Una reunión de este tenor, casi siempre gira en torno a buscar la mejor manera (más barata, de menor impacto) de lograr que los dos sistemas conversen y/o intercambien información. Adicionalmente, típicamente el sistema del cliente es un sistema antiguo y/o en operación (la manera elegante de decir que ya está estable), por lo que cualquier intención de tocarlo o modificarlo es liquidada rápidamente. Claramente, la opción más natural es adaptarse a cualquier tipo de salida y/o esquema de integración ya existente.
En mi experiencia, cada cliente tiene una realidad particular que impide enfrentar este tipo de problemas con una oferta de interfaces estándar. Por tal razón, mi visión, es la de ofrecer diversos esquemas más o menos conocidos y comenzar a evaluarlos con él. Según el perfil con el que se realice la reunión, ésta puede ser una reunión exitosa (desde el punto de vista de encontrar la mejor solución) o un fracaso (en caso de no encontrar una salida). En general, el desafío es encontrar la alternativa más concreta y eficiente para la integración, es decir, aquella para la cual el cliente tiene algún tipo de conocimiento y/o expertise, tiene la tecnología, los recursos, etc. Muchas veces he visto proyectos de integración en los que se deciden estrategias entre cuatro paredes y, al intentar implementarlas, los problemas son infinitos.
En este contexto, los WebServices han pasado a convertirse en un salvavidas de dominio público, desde mi punto de vista, nunca antes visto. En muchas reuniones en las que me ha tocado participar y después de estar un buen rato buscando la alternativa correcta, aparece un iluminado (A) que, sin tener la más mínima idea de lo que significa, hace su gran aporte:
- ¿Y si hacemos un WebServices? – nótese la ‘s’ al final, fundamental para identificar este perfil.
Lo más simpático de esta situación es lo siguiente:
- Posicionamiento. Casi inmediatamente A sube de rango entre sus pares. Pasa a ser un referente, el experto en integración. La persona que sabe y que va a resolver todos los problemas.
- Optimismo. Los problemas de integración se terminan. Mágicamente, la palabra WebService se convierte en un salvavida, algo así como un WD40 que permitirá desentrabar la integración y avanzar y, en los casos más extremos, se concluye que este es el mecanismo de integración y la reunión avanza hacia otras problemáticas.
Desde el punto de vista de la integración vía WebService, ésta requiere dos componentes:
- WebService. El WebService propiamente tal. Es un punto de entrada expuesto, típicamente, desde un servidor web hacia el resto del mundo. La
- Consumidor. El cliente que consume (usa) el WebService. Esta, probablemente, es una de las ventajas más grandes de esta tecnología y es que, actualmente, existen diversas bibliotecas integrables a nivel cliente que permiten hacer uso cualquier WebService fácilmente. Visual Studio provee herramientas visuales para incorporar referencias a un WebService. Java posee la herramienta wsdl2java que permite hacer lo mismo y, para los otros lenguajes, hay muchas alternativas para lograr lo mismo.
Considerando lo anterior, es fundamental tener presente que la integración vía WebService no es bidireccional por naturaleza. Esto implica, básicamente, que si se desea que dos sistemas, S1 y S2, puedan intercambiar información, se requiere que S1 implemente un WebService y S2 también y, a su vez, S1 consuma el WebService de S2 y vice versa. Lo importante de esto es tener claro cuál es el objetivo de la integración. Por ejemplo, si se tiene un sistema legacy que no posee una implementación para publicar un WebService, sería absurdo proponer esta tecnología como esquema de integración bidireccional.
Mi experiencia personal es que los WebServices son una alternativa más de integración, no son necesariamente la única ni la mejor, como muchas personas hoy en día sienten. Esta es una situación similar a lo que pasa con el XML en que cualquier cosa, en formato XML, pasa a ser “estándar” y cumplir con las buenas prácticas de uso de esta tecnología. En este contexto, ejemplos me sobran.
No hay comentarios.:
Publicar un comentario