Imagen vía (http://nicolas-zozol.developpez.com)

Recientemente he asistido al curso que imparte Extrema Solutions sobre Spring MVC y Rich Web Applications, un curso oficial de Spring Source sobre el desarrollo de aplicaciones web con este framework. Precisamente en el transcurso del mismo surgió el tema de los servicios tipo REST, una forma de implementar aplicaciones que aunque no es nueva en absoluto, sí se ha puesto muy de moda últimamente. En este blog mismo ya he tocado el tema.

Y siempre que sale este tema me pregunto lo mismo:
¿son los servicios tipo REST adecuados para una arquitectura SOA? Es decir, ¿una implementación basada en este tipo de servicios en lugar de los habituales servicios web SOAP es correcta desde el punto de vista de los requisitos que debe cumplir una arquitectura orientada a servicios?

el contrato del interfaz

Según Gartner un servicio debe seguir cinco principios. El tercero de ellos es el de ser claramente definido. En el caso de servicios SOAP, esto se cumple con el uso del fichero de descripción WSDL. Sin embargo, en el caso de REST, ¿cómo se define el contrato? es decir, ¿como sabe el cliente del servicio que parámetros de entrada/salida tiene el servicio?

Obviamente esta no es una cuestión trivial, ya que el contrato de un servicio es la esencia misma del servicio. Y no es una cuestión teórica en absoluto, es bastante práctica. En un escenario habitual en el que el cliente lo desarrolla una empresa y el servicio lo hace otra. ¿cómo se hace entonces la comunicación del interfaz del servicio de la empresa o el equipo que construye el servicio al equipo que va a consumirlo? ¿en un correo? ¿en un documento word? ¿con qué formato? ¿con texto libre?

Creo que queda claro que con un WSDL, aunque tiene un formato poco “amigable”, es un contrato rígido, no ambiguo y que puede incluso ser aplicado de manera automática. Es normal además usar una herramienta o asistente en el entorno de desarrollo que automáticamente genera un cliente para este servicio (lo que se conoce como cliente proxy).

Por otra parte, aunque los servicios REST no tienen que basarse exclusivamente en XML ya que es posible por ejemplo usar un formato JSON, sí se puede aprovechar la características que ya tiene el XML para la definición del interfaz. Éste ya lleva incluido “de fábrica” los esquemas (archivos XSD) que definen cómo se tiene que construir este XML (la gramática del mismo). Este mismo XSD es el que se usa dentro de los WSDL para este mismo cometido: definir el contrato o interfaz del servicio.

WADL, el WSDL de los servicios REST

Profundizando en internet sobre el tema de la descripción de un servicio REST, me encuentro con el formato WADL. La verdad es que no lo conocía. Precisamente este formato viene a llenar en el vacío que teníamos respecto a la descripción de un servicio REST.

En esta página podemos ver un ejemplo de WADL que describe un servicio REST de manera similar a cómo el WSDL describe un servicio SOAP

Debido a la propia naturaleza de REST, muchísimo más simple que SOAP, el fichero de descripción es mucho más sencillo. Las operaciones únicamente pueden ser los verbos de HTTP: GET, POST, PUT y DELETE. Los mensajes de error serían los códigos de error que define el protocolo HTTP.

Registro de servicios

Otro de los servicios que tiene que cumplir (según Gartner) es que sea distribuible, es decir, que para el cliente sea transparente su localización física. De esta manera el servicio se puede desplegar en cualquier máquina, y cambiarlo cuantas veces sea necesario sin impactar a los clientes.
En el caso de los servicios web, esto se soluciona con el uso de un registro de servicios, un servidor UDDI. ¿cómo hacemos esto con los servicios REST? Tendríamos que ver que soporte dan actualmente este tipo de servidores al formato WADL aunque me temo que todavía no es muy popular (revisaré esto en profundidad en una futura entrada del blog).

Conclusión
En mi opinión, para que los servicios REST sean considerados “ciudadanos de primera clase ” en SOA, deben cumplir los requisitos de:

  1. tener un fichero de descripción, tipo WADL
  2. Poder ser publicados en un registro de servicios

Comparte esta entrada:
Share

Anuncios