20120428-092557.jpg

Desde el punto de vista técnico podemos considerar a los servicios web como el último estadio, el más avanzado, en la particular evolución de los programas software (al menos de momento).

¿Por qué digo esto? Entre otras cosas que veremos más adelante en próximas entradas, digo esto por la mínima dependencia que requiere un servicio web entre el cliente y el proveedor del servicio, es decir del máximo desacoplamiento que ofrece este tipo de tecnologia.

Como todo, esto se ve mejor si lo comparamos con cualquier otra forma de comunciación entre funciones o módulos software.

Casi en el principio de los tiempos, se vio que con la programación estructurada, la división de un gran programa en módulos software reutilizables favorecia la claridad del código, la productividad, la disminucion de errores y la posibilidad de realizar pruebas de manera aislada para cada uno de estos módulos o procedimientos.

Sin embargo, en este caso, se tiene un fuerte acoplamiento porque el módulo o procedimiento del cliente y el procedimiento del proveedor tienen dependencia incluso a nivel de compilación. No es posible siquiera programar la llamada si no disponemos del código del programa al que vamos a invocar. Normalmente esto provoca que ambos programas deben estar hechos en el mismo lenguaje aumentando aún más la dependencia entre ambos

Y no sólo eso, ambos programas se tienen que ejecutar en la misma máquina y normalmente incluso en el mismo espacio de memoria.

Esto se mejorará lo largo del tiempo con otro tipo de tecnología, como la de objetos remotos distribuidos como CORBA o RMI/IIOP en el caso de java. En este caso, el programa cliente y el programa proveedor de la funcionalidad pueden ejecutarse en diferentes máquinas. Sin embargo seguimos teniendo presente el gran problema de la dependencia en compilación.

Además, como el java es un lenguaje fuertemente tipado, podemos tener un gran problema con la evolución de nuestro “servicio”. En este caso, es necesario que una pequeña librería de código del programa servidor sea distribuido por todos los clientes. En esta libreria está el código compilado del interfaz del programa que queremos llamar, al menos un método de una clase y todas las clases que definen este interfaz de entrada/salida,

Imaginemos ahora que añadimos un nuevo parámetro de salida al método del servicio. Es un parámetro opcional, así que tendría que ser compatible hacia atrás. Es decir, los clientes que tenemos ahora no deberían verse afectados, simplemente “ignorarán” este nuevo parámetro. Sin embargo, los nuevos clientes, que ya saben de la existencia del nuevo parámetro pueden usarlo si lo mecesitan.

Pues bien, esto no funciona así por desgracia. Como el interfaz es código compilado si se añade un campo más, codificado en el bytecode, el interfaz antiguo (la librería anterior distribuida en los clientes sin el nuevo campo) es imcompatible con la nueva. Por restricción del propio mecanismo, la versión de la librería de interfaz en el lado cliente debe ser la misma que en el lado servidor. Conclusión, es necesario cambiar la librería en todos los clientes, no sólo en los nuevos. Y además hay que hacerlo en todos a la vez.

Como mejora a esta situación tenemos los servicios web, con su interfaz completamente definido en el fichero WSDL. No tenemos ninguna dependencia de compilacion, el proveedor puede estar en otra maquina, y tanto es así, que el cliente ni siquiera tiene que saber en cual.

¿Todo perfecto? Por desgracia no. Y aquí es donde viene el “misterioso” titulo de esta entrada. La paradoja del desacoplamiento de los servicios web

¿Que quiero de ir con esto? Que aunque no reparemos en esto en un primer momento, resulta que un sistema software construido con una arquitectos orientada a servicios tiene más dependencias que otros sistemas anteriores, basados en aplicaciones silo.
Pero no son dependencias técnicas, casi podríamos calificarlas de dependencias “políticas”.
Y es que la reutilización de los servicios tiene un precio. Nuestra aplicación o conjunto de servicios usará varios servicios de otra mucha gente, otros departamentos e incluso otras empresas. A su vez, de nuestros servicios dependen otras muchos. Y cuando más éxito tenga SOA más reutilización y más dependencia.

Para no caer en el caos, esto tiene que ser gestionando eficazmente, con un compromiso claro por todas las partes de respetar el contrato de los servicios. Además se debe contar con un repositorio de servicios donde se puedan buscar los servicios ya existentes para no hacerlos por duplicado. En este repositorio debe estar recogido claramente tanto el contrato, una explicación de la funcionalidad del servicio y también la identidad de su responsable. Es este responsable del servicio que utilicemos, el que marcará la particular dependencia de nuestro servicio.

Anuncios