Una vez definido lo que un web service es capaz de hacer nos encontramos con la tarea del modelado, la planeación de este tópico nos entrega la eficiencia en recursos, el acceso a estos, entre otras tareas, mismas que deben ser calculadas de acuerdo a nuestras
necesidades, por ello parece pertinente hacer una comparación entre las posibles alternativas. En la actualidad el modelado o estilo de arquitectura recae en los siguientes listados:
• RPC (Remote Procedure Calls, Llamadas a procedimientos remotos). Son las primeras herramientas presentadas para servicios web, se caracterizan por ser fuertemente acoplados18 y se implementan por el mapeo de servicios directos a funciones o llamadas a métodos. La unidad de comunicación en la operación es el documento WSDL.
• SOA (Service-Oriented Architecture, Arquitectura Orientada a Servicios). La unidad básica de comunicación es el mensaje, estos servicios están débilmente acoplados19, además, encapsulan la implementación volviéndose altamente interoperables. Identifican la utilización del servicio por un “contrato” empleando SOAP y WSDL.
• REST (REpresentation State Transfer). Emulan el protocolo HTTP restringiendo la interfaz a un conjunto de operaciones, este estilo se centra en la interacción del recurso en lugar del mensaje u operaciones.
En la actualidad, las arquitecturas de modelado de web services más populares son SOA y REST, es por ello que se entra en debate acerca de cuál sería más adecuado para un problema propuesto, es por ello que se deben contemplar las ventajas y desventajas de cada una de ellas, éstas se muestran en la tabla 3.1:
18
En una modelo fuertemente acoplado las aplicaciones o componentes mantienen un alto grado de dependiencia entre ellos, perjudicando la interoperabilidad de componentes y la tolerancia a fallas. 19
Una arquitectura débilmente acoplada favorece la interoperabilidad y la tolerancia a fallos o cambios, esto es debido a que los componentes mantiene un alto grado de independencia, esto es, en esta arquitectura debe aceptarse y compartirse lo menos posible las funciones correspondientes al componente.
REST SOA
Ventajas Bajo consumo de recursos.
Los clientes pueden tener una interfaz de escucha para notificaciones.
Fácil de construir y adoptar. Instancias creadas explícitamente
Fácil de utilizar.
Las operaciones complejas pueden ser encapsuladas.
Variedad de herramientas de desarrollo.
Desventajas Se genera un gran número de
objetos.
Descripción informal.
Los clientes necesitan conocer el contrato de uso antes de consumirlos. Las instancias se crean implícitamente.
Tabla 3.1 – Comparación de las arquitecturas de servicios web REST y SOA.
Existen varias diferencias entre ambas arquitecturas, a continuación se señalan algunas de ellas:
• Manejo del protocolo.
REST utiliza HTTP como protocolo de aplicación, esto es, crea un conjunto de reglas acerca de cómo utilizar el protocolo HTTP, además tiene una cantidad de operaciones conocidas sobre éste protocolo para realizar tareas específicas del lado del servidor, estas son PUT, POST, DELETE y GET, correspondientes a las tareas de escribir un recurso, procesar una petición, borrar un recurso y obtener un recurso, mientras que SOA lo utiliza como un protocolo de transporte, para enviar los mensajes dentro de una “envoltura” sobre dicho protocolo. Este manejo también es aplicable a la versión segura de protocolo HTTP, HTTPS. Este manejo de la seguridad del protocolo en la arquitectura REST afecta directamente al paquete enviado, mismo que contiene la tarea, mientras que para el caso de la arquitectura SOA, el paquete se realiza de la manera habitual en cuanto a cuestiones de seguridad, debido a que la “envoltura” nada tiene que ver con la petición , si no con el “payload” o carga de transferencia.
En la figura 3.5 se muestra la manera de envío de mensajes bajo ambas arquitecturas:
Figura 3.5 – Diferencias entre las arquitecturas a) REST y b) SOA para el manejo del protocolo
HTTP.
• Estado de la comunicación.
La falta de estado mejora el rendimiento de un web service y simplifica el diseño e implementación de componente del lado del servidor, esto es debido a que el servidor no tiene la necesidad de sincronizar los datos de sesión con una aplicación externa.
En la figura 3.6 se muestra un servicio con estado, la petición a una página implica el conocimiento de un estado anterior, es por ello que se muestra la petición hacia una página siguiente en lugar de una página en específico, en un diseño con estado el servicio incrementa y guarda el resultado de la página previa para saber en qué estado se encuentra y asumirlo para la siguiente consulta. Con respecto a los mensajes, estos solo contienen los datos más no alguna información del estado de la conversación.
Figura 3.7 – Comunicación basada en una arquitectura sin estado.
Cuando se realiza un diseño sin estado, como el mostrado en la figura 3.7, el servicio genera una respuesta que se enlaza con un número de página y deja al cliente realizar lo necesario para guardar este valor, es decir, los recursos contienen además de los datos los enlaces a un estado válido, debido a esto un diseño REST descansa sobre las responsabilidades de ambas partes que son:
• Servidor. Genera respuestas que incluyen enlaces a otros recursos que permiten a las aplicaciones navegar entre recursos relacionados, las respuestas indican si se guarda o no caché para mejorar el rendimiento reduciendo el número de peticiones a recursos duplicados.
• Cliente. Envía peticiones completas que pueden ser provistas independientemente de otras peticiones, con esto, mantienen el estado siguiendo los enlaces provistos por el servidor.