Solución:
Como los términos implican, una Arquitectura Orientada a Servicios está orientada a servicios y una Arquitectura Orientada a Recursos está orientada a recursos. En general, las diferencias entre dos cosas A y B a menudo se explican mejor definiendo la esencia de A y B. Así que todo se reduce a la pregunta, ¿qué es un ‘servicio’ y qué es un ‘recurso’?
Se lo dejo principalmente al lector, ya que la mayoría de los desarrolladores probablemente tengan una idea de lo que es. Aunque en realidad no es tan fácil, ya que una cosa podría verse como un servicio y como un recurso (similar a la clásica dualidad de luz onda-partícula en física). Por ejemplo, Flickr es un servicio que le proporciona fotografías, pero también puede verse como un recurso para las fotografías. Pero básicamente, un recurso es más datos estáticos (como una foto) y un servicio es más procesamiento (por ejemplo, entregar una foto o cambiar el tamaño de una foto para que puedan mostrar una miniatura de una).
Entiendo mejor la diferencia al observar la forma en que una aplicación implementa su ‘funcionalidad’:
- Una aplicación construida con un Arquitectura orientada a Servicios es más una ‘fachada’, por ejemplo, combina o compone su funcionalidad saliente en función de la funcionalidad que se encuentra en los servicios que utiliza ‘detrás de las pantallas’ (posiblemente a través de la red). Por ejemplo, su procesamiento central consiste en llamar a servicios externos, proporcionarles parámetros y combinar los resultados con posiblemente algún procesamiento adicional o algoritmos para el usuario.
- Una aplicación construida con un Arquitectura orientada a recursos realiza más de su procesamiento internamente (por ejemplo, en lugar de llamar a componentes externos) pero utiliza recursos externos como entrada. Por ejemplo, su procesamiento principal consiste en recuperar recursos estáticos y luego hacer más cálculos internamente.
Primero rectificaré 🙂
Para el propósito de esta respuesta, digamos que REST es una forma de organizar los recursos y las operaciones que realiza en ellos.
SOA utiliza el protocolo SOAP o REST para transferir documentos XML o JSON entre varios servicios.
Absolutamente no. REST no es un protocolo. SOAP es un protocolo, eso es cierto. Se utiliza con frecuencia en arquitecturas SOA, particularmente para la implementación de SOAP sobre HTTP o SOAP sobre JMS. Sin embargo, SOA no implica SOAP. Podrías usar cualquier otro protocolo. Lo mismo se aplica a XML y JSON. Puede utilizar cualquier otro idioma o dialecto.
Ahora la explicación. SOA es una arquitectura orientada a servicios. Por lo tanto, todo el sistema está compuesto por servicios que normalmente realizan algunas operaciones. La arquitectura se basa en esto. Imagine una nube de servidores donde cada uno tiene al menos un servicio, por ejemplo WeatherPredictor, ForexCalculator, etc.
En oposición a esto, tiene la arquitectura orientada a recursos, ROA, donde el sistema está compuesto por recursos. Imagina una nube de servidores donde cada uno representa uno o más recursos, por ejemplo Weather, Euro, Dollar, …
El ROA se utiliza normalmente en sistemas grandes y abiertos, debido a las ventajas que aporta. En las arquitecturas ROA, normalmente encontrará servicios RESTfull. En la actualidad, los servicios RESTfull se implementan normalmente con solo JSON sobre HTTP o XML sobre HTTP.
SOA se usa un poco en todas partes. En SOA, comúnmente encuentra SOAP sobre HTTP, SOAP sobre JMS, etc.
Pero algún día puede encontrar un servicio web RESTfull que, por alguna extraña razón, use SOAP (quizás los desarrolladores necesitaban incrustar el mensaje en el sobre SOAP por alguna extraña razón). Creo que no encontrarás este ejemplo en la vida real, pero solo para mostrarte que SOA o ROA no implican el protocolo a utilizar, en este caso SOAP.
Espero que esto ayude.
Según mi experiencia, mi comprensión es la siguiente:
ROA son envoltorios de API sobre modelos de datos, SOA es API sobre módulos funcionales.
ROA se utiliza para proporcionar operaciones CRUD. SOA se utiliza para vincular módulos en tiempo de ejecución.
ROA aísla a los consumidores de API de los cambios en los modelos de datos. SOA permite colocar reemplazos de módulos, lo que simplifica la implementación y la personalización.