design - definicion - soa architecture example

¿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?

En este momento, 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

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.

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

Answer 2

En un nivel alto, la respuesta es Sí, pero no completamente.

SOA requiere pensar en el sistema en términos de

• Servicios (funcionalidad comercial bien definida)
• Componentes (piezas discretas de código y / o estructuras de datos)
• Procesos (orquestaciones de servicios. Generalmente usando BPEL)

Ser capaz de componer nuevos servicios de alto nivel o procesos de negocios 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 algunos principios aceptados: http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles

• Contratos de servicios estandarizados: los servicios se adhieren a un acuerdo de comunicaciones, tal como se define colectivamente por uno o más documentos de descripción del servicio.
• Acoplamiento suelto de servicios: los servicios mantienen una relación que minimiza las dependencias y solo requiere que se mantengan informados unos a otros.
• Abstracción del 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 de servicios: los servicios minimizan el consumo de recursos al diferir la administración de la información de estado cuando sea necesario
• Descubrimiento del servicio: los servicios se complementan con metadatos comunicativos mediante los cuales pueden descubrirse e interpretarse con eficacia.
• Capacidad de 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 lo mismo usando REST, necesitarías tener RESTful Web Services + Orchestration (posible usando algunos ESB livianos como MuleESB o Camel)

También vea este recurso: de SOA a 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.

Supongamos que tiene una aplicación de procesamiento de pedidos con operaciones como:

• añadir artículo
• addTax
• calcularTotal
• realizar pedido

Inicialmente 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.

Publicado en mi blog personal - http://blog.padmarag.com

También verifique este nuevo recurso que encontré - RESTO basado en SOA

Answer 3

Lo más importante de SOA son los factores suaves, por ejemplo, hacer que otras personas usen tus servicios y viceversa, para eso tener un enlace wsdl del que puedes 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 puedes obtener mejores resultados sin ellos pero necesitas eventos)

Tenga en cuenta que los 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 cambiar a binario (que sopla DESCANSO fuera del agua) cuando lo necesite.

En cuanto a SOAP en 8 años de construir sistemas SOA de alto rendimiento con WCF, nunca me había dado cuenta de que SOAP estaba allí ... eso es porque trabajo principalmente en C # y tenemos una buena pila de SOAP ... la mayoría de los otros idiomas no.