Por definición, los web services, son programas, rutinas o piezas de software (como se quiera decir) que están débilmente acoplados. Únicamente exponen al exterior su interfaz, su contrato, con el cliente. Con el descriptor del servicio (el fichero WSDL) es suficiente para que el cliente pueda invocar al servicio. Así pues, con la promesa de una arquitectura débilmente acoplada, la secuencia normal en una organización es embarcarse en la construcción de decenas, si no cientos de web services que a medida que se va necesitando se van invocando unos a otros.

Hasta aquí, todo bien, sin embargo si hacemos un análisis más profundo, o dejamos que pase el tiempo y el número de web services crezca, nos damos cuenta de un problema. Estos servicios se están llamando entre sí directamente, punto a punto. Y llega un momento en que las relaciones entre los mismos, se convierte en una maraña difícil de seguir y gestionar. A esto hay que añadir que en nuestro fichero WSDL, no sólo está la definición de los parámetros de entrada/salida, sino que también se encuentra la dirección física de la localización del servicio (donde realmente se ejecuta), el llamado endpoint.

Por lo tanto, lo que inicialmente era una arquitectura débilmente acoplada, con todas las ventajas en cuanto a sustitución de un web service por otro (sin afectar a los clientes) se convierte en una estructura rígida, con la mayoría de los servicios que tienen dependencias unos de otros, un clásico “espagueti” en toda regla. Precisamente una de las características de muchas aplicaciones “tradicionales” y la que pensábamos evitar con la adopción de los web services.

¿cómo evitamos esto? Pues las soluciones son conocidas y relativamente fáciles de aplicar:

En primer lugar, tenemos que romper la dependencia con la localización física de los servicios. Para ello está el middleware conocido como UDDI o Registry. Es en este tipo de servidor donde se alojará el WSDL del servicio. El cliente consultará al registro de servicios por este WSDL y obtendrá el endpoint que le señalará la máquina y el puerto de destino donde debe invocar al servicio. Si queremos cambiar el servicio de localización, únicamente tendremos que cambiar el endpoint en el registro. Obviamente, éste debe ser consultado en tiempo de ejecución por el cliente y no puede estar codificado (“harcodeado”) en el código del cliente o en un fichero de propiedades propio.

Otro paso más allá en la soluciones a emplear sería el uso de un ESB.

ESB

Con un ESB estamos estableciendo un sitio de obligado de paso para la invocación del servicio, un “middleware” por el que pasan las peticiones a los servicios. Con esto estamos rompiendo la relación “punto a punto” que pueda existir entre los servicios. Además se reducen exponencialmente las relaciones (puntos de acoplamiento) ya que en lugar de cada servicio esté relacionado con n servicios, únicamente lo estará con el Bus. Así es fácil, reemplazar un servicio de por otro, ya que lo que se hará es “desengancharlo” del Bus y enganchar el nuevo servicio en su lugar.

Por supuesto, el ESB, además de servir de “concentrador” de los servicios también aporta otras ventajas inherentes a su uso como la transformación de datos, el propio enrutado, un tratamiento homogéneo de la seguridad, composición sencilla de servicios compuestos a partir de otros simples, etc, etc.

El problema del “punto a punto” en los servicios web se considera un anti-patrón en  SOA.

Comparte este artículo…