¿Se puede diseñar una SOA con REST?

Question

He estado leyendo mucho sobre SOA últimamente, pero la mayor parte del contenido está relacionado con SOAP y tiene muchas cosas "burocráticas" que pertenecen a los sistemas C#/Java. Honestamente, creo que esa burocracia, especialmente SOAP, es un dolor en el trasero. Entonces, tengo curiosidad, ¿se puede diseñar una SOA con REST?

Ahora mismo en las aplicaciones de Ruby, hago que todos mis controladores sean RESTful. Mi interfaz web (formularios, etc.) realiza solicitudes GET/POST/PUT/DELETE al núcleo, que es un servicio web REST. Todos los demás sistemas que usan el núcleo le hacen solicitudes RESTful. ¿Es esto una SOA?

Answer 1

En un nivel alto, la respuesta es Sí, aunque no del todo.

SOA requiere pensar acerca del sistema en términos de

• Servicios (funcionalidad de negocio bien definido)
• componentes (piezas discretas de código y/o estructuras de datos)
• Procesos (orquestaciones de servicios. Generalmente utilizando BPEL)

Ser capaz de componer nuevos servicios de nivel superior o procesos de negocio es una característica básica de una buena SOA. XML, servicios web basados ​​en SOAP y estándares relacionados son adecuados para realizar SOA.

también SOA tiene unos principios aceptados - http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles

• contrato de servicio estandarizado - Servicios adhieren a un acuerdo de comunicaciones, tal como se definen en conjunto por uno o más servicios de descripción de documentos.
• Service Loose Coupling - Los servicios mantienen una relación que minimiza las dependencias y solo requiere que se conozcan entre sí.
• Abstracción de servicio: más allá de las descripciones en el contrato de servicios, los servicios ocultan la lógica del mundo exterior.
• Reutilización del servicio: la lógica se divide en servicios con la intención de promover la reutilización.
• Autonomía del servicio: los servicios tienen control sobre la lógica que encapsulan.
• Granularidad del servicio: una consideración de diseño para proporcionar el alcance óptimo y el nivel granular correcto de la funcionalidad del negocio en una operación de servicio.
• apatridia - Servicios de minimizar el consumo de recursos mediante el aplazamiento de la gestión de la información de estado cuando sea necesario
• Servicio de detectabilidad - Los servicios se complementan con los metadatos de comunicación por el cual pueden ser descubiertos e interpretados de manera efectiva.
• Capacidad de compilación del servicio: los servicios son participantes eficaces en la composición, independientemente del tamaño y la complejidad de la composición.

Se espera que una arquitectura basada en SOA tenga una definición de servicio. Como los servicios web RESTful carecen de una definición definitiva de servicio (similar a wsdl), es difícil que un sistema basado en REST cumpla con la mayoría de los principios anteriores.

para lograr el mismo usando REST, que había necesidad de contar con servicios web RESTful + orquestación (posible uso de algún ligero ESB como MuleESB o camello)

Por favor, vea también este recurso - From SOA to REST

---

Agregando esta parte como aclaración para el siguiente comentario:

Se requiere orquestación para componer procesos. Eso es lo que proporciona el principal beneficio de SOA.

Digamos que tiene una aplicación de procesamiento de pedidos con operaciones como -

• addItem
• addTax
• calculateTotal
• PlaceOrder

Inicialmente se creó un proceso (usando BPEL) que usa estas operaciones en secuencia. Usted tiene clientes que usan este servicio compuesto. Después de unos meses llega un nuevo cliente que tiene exención de impuestos, luego, en lugar de escribir un nuevo servicio, puede crear un nuevo proceso omitiendo la operación addTax. De este modo, podría lograr una realización más rápida de la funcionalidad empresarial simplemente reutilizando el servicio existente. En la práctica, hay varios servicios de este tipo.

Por lo tanto, la tecnología BPEL o similar (ESB o enrutamiento) es esencial para SOA. Sin uso comercial, una SOA no es realmente una SOA.

Cruz publicado en mi blog personal - http://blog.padmarag.com

También puedes ver este nuevo recurso me encontré - REST based SOA

Answer 2

El servicio en términos de SOA es un componente que resuelve un determinado problema comercial. SOAP/WCF están más relacionados con la interfaz/parte de entrega de SOA. El enfoque REST se puede usar también. El contrato de servicio, las políticas, el control de versiones y otras características SOA "estándar" también se pueden implementar con el servicio RESTful.

El principal problema REST es que está dirigido a CRUD, por lo tanto, no sería la mejor opción para la implementación de lógica compleja. Pero si su lógica comercial es completamente CRUD (o converge a CRUD), entonces debería estar bien.

Btw, parece que Microsoft agregó operaciones a los servicios de datos WCF especialmente para emular SOAP con REST.

Answer 3

Lo más importante acerca de SOA es los factores blandos por ejemplo, hacer que otras personas a utilizar sus servicios y visados Por el contrario, tener un enlace wsdl desde el que pueda construir un proxy fácil de usar es casi esencial. Los servicios deben poder componerse ... pero NO es necesario que orchestration, BPEL o un bus elegante lo haga y no los recomendaría cuando comience con SOA. (de hecho, habiendo usado estos, creo que puede obtener mejores resultados sin ellos, pero sí necesita eventos)

Tenga en cuenta que productos como WCF le permiten crear un servicio que expone un wsdl, pero además de SOAP también puede usar REST/Json o incluso mejores puntos finales binarios TCP. Esto es ideal ya que usa SOAP para simplificar y cambia a binario (que saca REST fuera del agua) cuando lo necesita.

En cuanto a SOAP en 8 años de construir sistemas SOA de alto rendimiento con WCF, nunca he notado que SOAP estaba allí ... eso es porque trabajo principalmente en C# y tenemos una buena pila de SOAP ... la mayoría de los demás idiomas no haga.