En nuestro trabajo, frecuentemente nos vemos en la necesidad de integarnos con aplicaciones o servicios de terceros. En esta entrada del blog, hago la siguiente reflexión: en este escenario y de una manera sencilla ¿que debemos tener en cuenta para esta integración?

  1. Que la integración se base en servicios web. En su defecto, podría valer un interfaz basado en XML sobre HTTP. Sin embargo, en el caso de un servicio web (SOAP sobre HTTP) tendremos una característica muy importante, el descriptor del servicio, el WSDL.
    Sin embargo, contrariamente a lo que podríamos suponer a estas alturas, la disponibilidad de servicios con interfaz web services, no está todavía muy extendida.
  2. Una vez que tenemos constancia de que existen los WSDL, lo siguiente a comprobar es si estos servicios cumplen con el Basic Profile 1.1 . Ya ha hablado alguna vez al respecto de esta especificación, pero por resumir, podríamos decir que sin ella, la interoperabilidad de aplicaciones mediante servicios no hubiese sido posible.
    Al cumplir el Basic Profile nos aseguramos esta interoperabilidad seal cual sea el sistema operativo y el lenguaje en el que se basa el cliente o el proveedor de servicio. Pero ¿como se comprueba si un web service cumple con el Basic Profile 1.1? afortunadamente con un IDE (entorno de desarrollo) se puede hacer fácilmente. No obstante, nunca está de más que se conozca al menos por encima esta especificación. Se puede ver aquí, aunque no es muy didáctico que digamos. Otro sitio donde se puede ver es aquí, una estupenda página que por cierto tuve que estudiar en profundidad para la certificación de servicios web de Sun (ahora Oracle).
  3. ¿está la interfaz del servicio correctamente declarado en el WSDL? ¿están claro los parámetros de entrada y salida o son de tipo “churro”?. Con demasiada frecuencia me he encontrado con servicios que no están descritos en el WSDL. Normalmente aparece un sólo campo de entrada y otro de salida, que suele llamarse “mensaje” o algo parecido. El proveedor nos dice entonces que en ese único mensaje tenemos que incluir un XML que es en realidad el verdadero mensaje. ¿por qué no está descrito entonces en el WSDL? ¿Cómo sabemos el formato de ese mensaje? ¿nos pasara un documento tipo Word para explicárnoslo? ¿como vamos a usar una herramienta que genera el cliente automáticamente si no está descrito en el WSDL?. En fin, que no nos den gato por liebre, un servicio con un sólo campo de entrada en el que hay que introducir un XML NO es un servicio web, es un CHURRO.
  4. ¿tienen sesión? Un servicio web por definición no tiene sesión. Dicho sea de manera práctica, no guarda nada en memoria. Por supuesto, si trabaja con entidades de negocio, del tipo “cliente”, “cuenta corriente” y póliza, el servicio podrá modificar la base de datos para reflejar estos cambios. Lo del estado es otra cosa, significa que un llamada a un servicio dependa de otras anteriores, o que deban ser invocadas en un determinado orden para que funcione. Un caso claro, y demasiado común por desgracia, de servicios con estado son aquellos que definen un servicio de login o y otro de logout. Así, por ejemplo, para dar de alta un cliente y asignarle un producto se realiza una serie de invocaciones a servicios de este estilo: login al sistema, alta del usuario, asignación del producto y finalmente,logout del sistema.
    Como es sabido, el uso de sesión implica el uso de recursos en el servidor (sobre todo memoria, pero también CPU para mantener la sesión sincronizada entre los distintos nodos del cluster). El uso de estos recursos, hace que un sistema basado en servicios con sesión sea menos escalable que otro que no la tenga, simplemente porque estos últimos no necesitan ninguna clase de recurso adicional para funcionar.
  5. ¿qué tipo de seguridad tiene? Lo mínimo que se puede pedir es autenticación BASIC con HTTPS. Otras formas de seguridad basada en el mensaje sería la cabecera estándar UserNameToken y otras binarias como por ejemplo LTPA, que es propietaria de IBM.
    También se podría tener, más difícil de ver algo basado en SAML.
    Si los servicios no son públicos, del tipo búsqueda de oficinas o algo parecido a los que no importa quien acceda, se deberá exigir al menos uno de estos tipos de autenticación (el mínimo es BASIC con HTTPS), aunque a estas alturas deberían también proporcionar alguno basado en seguridad en el mensaje.
    El problema que tienen la seguridad BASIC es que es fácilmente descifrable el usuario y la password ya que estos viajan en claro (en formato BASE64). Por eso se combinan con HTTPS, ya que de esta manera se hace imposible acceder a la comunicación.
    El problema que tiene HTTPS es que protege únicamente el canal. Es decir entre el emisor y el receptor. Si el mensaje da más de un “salto” entre servidores, es posible que alguno de estos tramos se hagan con HTTP y la seguridad estaría comprometida por tanto. Es decir, aseguramos con HTTPS cuando el mensaje pasa del emisor A al servidor B, pero si el B redirige el mensaje hacia el servidor C, entonces el mensaje puede ir sin seguridad.
  6. Proxies ya construidos. Con el fin de aumentar la productividad es muy común que el proveedor del servicio web también proporcione una librería cliente en uno o varios lenguajes (C, Java, PHP, etc.). El cometido de estas librerías es actuar de proxy del servicio. Abstrae al programador del trabajo con web services y la dificultad que esto podría implicar. Es decir, usa el proxy como si fuese un objeto o librería más de su programa, sin saber que por detrás se esta realizando una comunicación mediante SOAP sobre HTTP.En un principio podríamos considerar estas librerías como una ventaja para nuestro desarrollo, pero mi opinión dada mi experiencia con esto, es que es “pan para hoy y hambre para mañana”. ¿por qué digo esto? por lo siguiente:
    1. una de las grandísimas ventajas que tienen los servicios web es el desacoplamiento entre el consumidor y el productor. No hay protocolos ni  tipos de parámetros ni formas de invocación propietarias o “raras”. Todo se basa en un estándar que funciona igual en todos los sistemas operativos y lenguajes, está avalado por las grandes compañías del sector (IBM, Oracle, Microsoft, Software AG, etc. etc.). Si el proveedor nos proporciona una librería para hacer esta invocación nos estaremos perdiendo la ventaja del desacoplamiento.
    2. todas las herramientas de desarrollo (IDEs) actuales tienen la funcionalidad de generación de proxies. Es decir, si les proporcionamos los descriptores de los servicios (WSDL), con un sencillo asistente y pulsando “siguiente” unas cuantas veces nos generaran unos proxies parecidos pero con la diferencia de que somos enteramente independientes del proveedor (únicamente se ha de respetar el “contrato” del WSDL)

Conclusión: Cuando nos integremos con servicios de terceros, tengamos esto en cuenta:

  1. debe cumplir el basic profile 1.1
  2. los servicios NUNCA deben tener estado
  3. debe tener seguridad. Al menos BASIC+HTTPS aunque es recomendable seguridad en el mensaje XML (tipo UsernameToken)
  4. debe estar explícitamente descrito los parámetros de entrada/salida en el WSDL (nada de servicios tipo “churro”)
  5. Ojo con las librerías cliente que nos proporciona el proveedor del servicio, puede ser un arma de doble filo.

Si te ha parecido útil esta entrada, compártela:
Share