a) Acá encuentro un primer mal entendido.
Dentro de los elementos de este estilo arquitectural a mí entender dos de ellos son fundamentales:
Proceso de negocio: es un conjunto de tareas que se relacionan lógicamente para conseguir un resultado bien definido dentro de un negocio. Por ejemplo uno puede pensar en el proceso de: comprar libro en un ecommerce. Si no estoy mal aquí hay lenguajes como BPMN que permiten describir un proceso de negocio.
Servicio: Esos son los que implementamos los desarrolladores normalmente y corresponden a definiciones de software concretas de los conceptos de negocio.
Los procesos NO hacen parte de SOA. Sí es un estilo arquitectónico, pero le falta apellido: es un estilo arquitectónico para sistemas distribuidos.
Los procesos se pueden (y lo hacen y han hecho) sin tener en cuenta las restricciones de SOA. Finalmente un proceso es un conjunto de actividades con orden lógico y cronológico que tienen un objetivo de negocio definido.
Ud está definiendo un servicio desde el punto de vista de un desarrollador. Este es el punto de quiebre de su discurso. Un servicio es una capacidad de negocio. No me importa sabor, color, olor.
No es una "definición de software concreta de los conceptos de negocio". Quizás una "definición de software concreta de los conceptos de negocio" sea un objeto, un actor o una función, pero no un servicio.
b)
De los servicios es importante mencionar las siguientes restricciones:
- Son independientes
- No dependen del contexto o del estado de otros servicios
- Cumplen un objetivo de negocio predeterminado
Un servicio casi nunca es independiente pues para ser una capacidad de negocio, requiere muchas veces, de la interacción con muchos más servicios (orquestados o coreografeados). De hecho, creo, que usted está mezclando mecanismos de despliegue con definiciones "ontológicas" de ser un servicio.
De nuevo, al decir que "No dependen del contexto o del estado de otros servicios" mezcla peras con manzanas: modos de despliegue o configuración vs una capacidad de negocio.
Quizás en la tercera característica "Cumplen un objetivo de negocio predeterminado" es tan ambiguo que ahí cabe la descripción de un proceso de negocio, de un servicio, de un objeto, de un actor, de un usuario, de cualquier cosa.
c)
Si para SOA el elemento clave es el servicio para REST lo es el recurso.
Aqui le hago una pregunta: En su opinión ¿qué diferencia existe entre: (una url que localiza un recurso + un media type + http status codes + http verb) y un "servicio" SOA?
La respuesta puede esclarecer muchas de sus preguntas y malentendidos.
d) El modelo de madurez lo definió Richardson en us libro "Restful web services" en el 2007. Luego, escribió otro libro "Restful web api" junto con Mike Amundsen donde deroga su modelo de madurez que, en términos prácticos, sólo sirve para fomentar la superficialidad técnica. (Apoyado públicamente por Fielding. Lo puede googlear.)
La fomenta porque con ver la gráfica los impávidos lectores piensan que hay versiones para hacer REST y, si se leyó el capítulo 5 de la tesis de Fielding, las cosas son blanco o negro: cumple con todas las restricciones o no. De hecho, si no estoy mal, Fielding en el capítulo 3 o 2 se mata la cabeza tratando de explicar qué es un estilo arquitectónico, cuales son los estilos disponibles (curioso que no haya metido a SOA en esa sopa, ¿no?) y cómo las restricciones permiten definirlas. Si una arquitectura de una aplicación no cumple con una restricción del estilo arquitectónico, pues no es ese estilo arquitectónico.
Cojamos pipe&filters por ejemplo. Si le quito los filters a pipe&filters ¿puedo decir que estoy siguiendo el estilo arquitectónico? En este caso no hay discusión.
e) De nuevo cae en el error de tratar los servicios como un artefacto de desarrollador.
Estamos acostumbrados a escuchar los Web Services como sinónimo de SOA. De nuevo esta comparación no esta muy bien vista. Hay dos puntos que creo cierran esta discusión:
Los Web Services no son la única implementación de SOA. Uno podría pensar en SOA usando cosas viejas como RMI o CORBA. La verdad es que yo soy medio pelado para estás tecnologías y nunca alcancé a utilizarlas.
Una aplicación que exponga Web Services no es necesariamente parte de un sistema SOA.
No se qué dicusión cierra pues no la hay. Que en el medio hay un mal entendido, sí, definitivamente. ¿Pero web service no es un recurso REST? El hecho de qe sea "web" ¿no implica de http?
Si partimos de la definición de un "web service", puede uno argumentar que web hace referencia a http, haciendo que su definición "ontológica" pierda validez al separar "SOAP services" de "RESTful services" (sea lo que sea que ud quiera decir con esa falacia) y de "HTTP services".
f)
No deberían ser una categoría, pero los menciono porque son los que la mayoría hemos implementado (yo nunca he implementado RESTful web services, siempre llego hasta el Nivel 2).
No hay niveles. Por favor lea el libro de Amundsen y Richardson. O el de Webber y Parastatidis para que me entienda el argumento.
g)
En este caso específico SOA se aprovecha de las restricciones de REST: sin estado, cacheable e interfaz uniforme (se supone que en los SOAP Web Services esto de interfaz uniforme también es cierto, pero no tan simple). Por último si retomamos el modelo de madurez de Richardson, los Restful Web Services deberían ser únicamente aquellos que se ubiquen dentro del nivel 3 de madurez, es decir deberían implementar hipermedia.
SOA no solo aprovecha las restricciones de REST; considero a REST como una materialización de SOA. SOA como estilo es, podría considerarse, más abstracto que REST. REST le da amarras a SOA, le da norte, guía y formalización. De esta manera la notación que usted usa se quedaría corta para explicar esta relación. Asi lo haga con UML2.0 no le alcanza.
Si uno se rige por su discurso, es posible que una aplicación siga SOA sin ser un sistema distribuido. En mi opinión no hay SOA o REST que pueda manifestarse en un sistema distinto al distribuido.
Un ejemplo ortogonal a este: micro-servicios. Hace cerca de dos años o más vengo trabajando en este tipo de aplicación. Una veces me convenzo de que este "estilo" hace parte más de cómo desplegamos una SOA a que sea un nuevo estilo arquitectónico. Sin embargo, esta materialización de SOA viene con sus propias restricciones. En este caso micro-servicios materializa a SOA.
h)
Los HTTP Services son un intento por hacer Restful Web Services pero que se quedan en eso: en particular sólo llegan hasta el Nivel 2 del modelo de madurez de Richardson. No deberían ser una categoría, pero los menciono porque son los que la mayoría hemos implementado (yo nunca he implementado RESTful web services, siempre llego hasta el Nivel 2).
Los HTTP services son eso, HTTP services. No tienen nada, nada que ver con REST. Ah bueno, que comparten http en caso de que REST se manifieste sobre ese protocolo.
Eso de la "mayoría" es la mayor de las tristezas: desarrolladores con pereza de entender affordances, usar media types expresivos como json-ld, c+j, hal-json, uber, etc. ¿Y qué me dice del versionamiento por URL? Pereza y superficialidad técnica por doquier.
i)
Finalmente están los protocolos de comunicación.
¿Cuál es su argumento para decir que SOAP es un protocolo de comunicación? Esta pregunta puede ser interesante.
Conclusión:
Muchas buenas intenciones se quedan en eso. Este review es una de esas "buenas intenciones". Espero que podamos discutir, argumentadamente, este tema que hace años no tocaba.
Kudos por escribir y compartir.