REST vs SOAP

SOAP vs REST 

Llegado el momento de desarrollar nuestros servicios web, tenemos que tomar la decisión acerca de la arquitectura más apropiada para nuestro sistema y el uso que vayamos a darle. En esta entrada mencionare las características de SOAP y REST, dos técnicas de arquitectura software orientadas a Webservices.

SOAP (Simple Object Access Protocol)

Es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambios de datos XML, el punto identificativo de SOAP es que las operaciones son definidas como puertos WSDL (Web Services Description Language). Es por esto que será aconsejable utilizar este protocolo en entornos donde se establecerá un contrato formal y donde se describirán todas las funciones de la interfaz así como el tipo de datos utilizados tanto de entrada como de salida. El lenguaje WSDL nos permitirá definir claramente cualquier detalle de las funciones de nuestro WS.

REST (Representational State Transfer)

Es un estilo de arquitectura de software para sistemas distribuidos tales como la web, a diferencia de SOAP, se centra en el uso de los estándares HTTP y XML para la transmisión de datos sin la necesidad de contar con una capa adicional. Las operaciones(o funciones) se solicitarán mediante GET, POST, PUT y DELETE, por lo que no requiere de implementaciones especiales para consumir estos servicios. Además se podrá utilizar JSON en vez de XML como contenedor de la información, por lo que será aconsejable utilizar este protocolo cuando busquemos mejorar el rendimiento, o cuando disponemos de escasos recursos, como sería el caso de los dispositivos móviles.

Antes de elegir una de las opciones, deberemos valorar cuál de ellas se adapta mejor al entorno de nuestra aplicación.

Aquí les menciono algunas características de cada arquitectura:


REST

• Los servicios Web RESTful son completamente sin estado. Esto se puede comprobar al reiniciar el servidor y comprobar si las interacciones son capaces de sobrevivir.
• Servicios RESTful proporcionan una buena infraestructura de almacenamiento en caché a través de HTTP GET método (para la mayoría de los servidores). Esto puede mejorar el rendimiento, si los datos devuelve el servicio Web no se altera con frecuencia y no de naturaleza dinámica.
• El productor y el consumidor de servicios necesitan tener una comprensión común del contexto, así como que se pasa el contenido a lo largo como no hay un conjunto estándar de reglas para describir la interfaz de servicios web REST.
• REST es particularmente útil para-Perfil restringido dispositivos tales como teléfonos y PDAs para la que la sobrecarga de parámetros adicionales como los encabezados y otros elementos de soap son menos.
• Servicios REST son fáciles de integrar con los sitios web existentes y están expuestos con XML para que las páginas HTML pueden consumir la misma con facilidad. Casi no hay necesidad de refactorizar la arquitectura web existente. Esto hace que los desarrolladores sean más productivos y cómodo, ya que no tendrán que volver a escribir todo desde cero y sólo hay que añadir en la funcionalidad existente.
• Aplicación basada en REST es simple en comparación con SOAP.

SOAP

• El Web Services Description Language (WSDL) contiene y describe el conjunto de normas comunes para definir los mensajes, enlaces, operaciones y ubicación del servicio Web. WSDL es un tipo de contrato formal para definir la interfaz que ofrece el servicio Web.
• SOAP requiere menos código de desarrollo y diseño de servicios REST, (es decir, las transacciones, la seguridad, la coordinación, el direccionamiento, la confianza, etc.) La mayoría de las aplicaciones del mundo real no son simples y apoyan las operaciones complejas, que requieren estado conversacional e información contextual que se mantenga. Con el enfoque de SOAP, los desarrolladores no tienen que preocuparse acerca de cómo escribir el código de desarrollo en la capa de aplicación a sí mismos.
• Servicios web SOAP (como JAX-WS) son útiles en el manejo de procesamiento asincrónico e invocación.
• SOAP soporta varios protocolos y tecnologías, incluyendo WSDL, XSD, SOAP, WS-Addressing

Pipes and Filters

Sistema de Mensajes

 Pipes and Filters

Utilizar la arquitectura Pipes and Filters, nos ofrece una estructura de procesamiento de flujo de datos. Cada de procesamiento está encapsulado en un componente filtro y los datos son transportados mediante tubos (pipes) que están entre filtros. Cada componente tiene un conjunto de entradas (inputs) y un conjunto de salidas (outputs). Un componente lee flujo de datos en sus entradas y produce flujos de datos sobre sus salidas. La transformación interna comienza a producir salidas antes de que se consuma toda la entrada.

Invariantes

• Los filtros deben ser entidades independientes. 
• No deben compartir estado con otros filtros. 
• Los filtros no conocen la identidad de sus filtros de entrada ni de salida. 
• Pueden restringir qué debe aparecer en las entradas, o garantizar qué saldrá por sus salidas. 
• La corrección de la salida de una red pipe-and-filter no depende (en general) del orden en el cual los filtros realizan el procesamiento incremental.

Especializaciones

• Pipelines: Restringen la topología a una secuencia lineal
• Pipe limitados: Restringen la cantidad de datos que puede residir sobre un pipe
• Pipes Tipificados: Restringen que los datos en los pipes sean de un tipo bien definido
• Sistemas Batch secuencial: Un filtro procesa todos sus datos de entrada como una entidad simple.

Ejemplos

• Programas escritos en Unix shell
• ps -ef | grep amsn; ls -l | more
• Compiladores tradicionales
• Dominios de procesamiento de señales
• Programación Paralela
• Programación funcional
• Sistema distribuido

Ventajas

• Permite comprender el comportamiento de entrada / salida de un sistema como la composición del comportamiento de los filtros individuales.
• Soportan reutilización
• Facilita el mantenimiento y crecimiento
• Permiten realizar análisis de ‘deadlock’ y rendimiento
• Soporte de ejecución concurrente

Desventajas

• Frecuentemente tienden a una organización de procesamiento batch
• No son buenos para aplicaciones interactivas.
• Pueden complicarse al tener que mantener dos flujos separados pero relacionados.
• Puede ser necesario agregar a los filtros conversión de datos de entrada y salida
• Pérdida de performance e incremento de complejidad de los filtros.

Ejemplo:

“Capitalize”: transforma un ‘stream’ de caracteres pasando a mayúsculas y minúsculas caracteres alternativamente.

Una solución pipe-filter:

Filtro ‘Split’: divide el stream de entrada.

Filtros ‘Upper’ y ‘Lower’: manipulan cada substring resultante en forma separada.

Filtro ‘Merge’: une nuevamente los substrings transformados.

Algunas consideraciones sobre el diagrama

•      Las relaciones de interacción están resaltadas.
•           Las dependencias de implementación son suprimidas
•      Claramente resalta el diseño arquitectónico

Una Representación Alternativa:

Algunas consideraciones sobre el segundo diagrama

• Este diagrama falla para capturar la composición arquitectónica
• Indica los módulos que están presentes en el sistema, y qué módulos se refieren a la implementación.
• No muestra los ‘pipes’