¿Se ha convertido el término "Arquitectura Orientada a Servicios" en una jerga sin sentido? [cerrado]

Hoy me preguntaron si tenía experiencia con la "Arquitectura orientada a servicios" y, aunque creo que sí. El concepto, para mí, parece tan confuso que ya no sé cómo podría responder honestamente esa pregunta.

Recurrí a googlear el término en un esfuerzo por obtener una definición concisa del concepto y cómo difiere de otras arquitecturas. Después de leer varios artículos sobre él, el único hilo común que parece ser capaz de encontrar es un sistema con múltiples componentes que se comunican entre sí a través de algún tipo de interfaz, con una ligera preferencia por XML / SOAP.

Parece que casi cualquier aplicación podría definirse como SOA, especialmente una aplicación web. ¿Ha caído este término en la trampa de "Web 2.0" y se ha convertido en un término que significa lo que quieras que signifique?

¿Estoy fuera de la base aquí? Cuando ustedes escuchan el término, ¿significa algo específico para ustedes? Si es así, me encantaría una definición concisa que demuestre claramente qué es y qué específicamente NO es SOA.

Creo que el significado original de SOA se basó en servicios con interfaces bien definidas que se pueden consumir mediante programación . La atención se centró en las interfaces de servicio en lugar de terminales UI, comunicaciones o bases de datos. La parte clave eran los servicios que consumían otros servicios. El Servicio A puede llamar al Servicio B, obtener el resultado y llamar al Servicio C o D. Puede tener un conjunto de servicios especializados y diseñar una solución al combinarlos de una manera que resuelva el problema del cliente.

SOA a menudo se confunde con SaaS (software como servicio), que se refiere al modelo de precios en el que el usuario paga por el uso del servicio al que se suscribió, en lugar de comprar una licencia para una copia del producto de software. Para responder el tercer párrafo de su pregunta, una aplicación web probablemente no sea SOA, pero puede ser SaaS.

El término definitivamente ha perdido algo de su significado. En la organización donde trabajo, el término SOA a menudo se usa indistintamente con SaaS y se refiere a un equipo de profesionales de TI ( tecnología de la información en lugar de desarrollo de productos de software ) que configuran servidores y enrutadores e instalan productos de software para ejecutarlos. Algunos de ellos tienen títulos como "Arquitecto SOA", pero ninguno de ellos tiene nada que ver con la arquitectura, el diseño, la implementación o la prueba del software.

He hecho lo mismo buscando en Google SOA para ver qué es realmente, y sí, se abusa bastante. Cuando pienso en SOA pienso en lo siguiente:

1. Un programa sin cabeza reconocible ...
2. Eso hace uso de la conectividad sin estado (ala HTTP) ...
3. Comunicación en formatos independientes de la plataforma.

SOA puede contrastarse con la arquitectura Cliente-Servidor (una arquitectura de servicio con estado) y bibliotecas, que son módulos conectados a programas a través de un enlazador.

Entonces, cuando la gente habla de eso, generalmente lo tomo con un grano de sal. También tiendo a llamarlo simplemente "servicios web". Con los servicios web la arquitectura está implícita.

Las definiciones estrictas de SOA están más allá de la línea de costo / beneficio como teóricas en muchos casos.

A menos que su producto sean los servicios en sí, a menudo necesita un punto de vista diferente.

Una definición utilizable de SOA significa que su arquitectura general es amigable con el servicio. Un sistema construido completamente a partir de servicios atómicos generalmente no es el plan correcto, y algunos servicios se organizarán funcionalmente mientras que otros serán responsabilidad única. Es posible que tenga cuadros negros, que tenga procesos fuera de línea, pero si hay una colección de servicios reconocible a través de la cual puedo realizar una cantidad significativa de trabajo, esa es mi definición mínima.

Además del debate sobre lo que realmente significa, el concepto (lo que sea que signifique) ha sufrido en muchos círculos al aplicarse a lugares en los que simplemente no encaja.

Por ejemplo, si estoy construyendo algo que está destinado a ser un proceso de caja negra y se escala a través del paralelismo, no de la segmentación y la distribución, puedo tener un servicio para exponer / hablar con la caja negra, pero algunas personas siguen tratando de poner los servicios dentro del caja.

Como una definición técnica estricta, siempre ha sido indefinida, pero la idea no carece de mérito donde encaja.

He tenido la suerte de trabajar en un par de sistemas corporativos donde la administración se ha vendido en SOA. Como desarrollador, miro los sistemas y veo un montón de software detrás de un servicio web que hace cosas. Podría haber sido escrito en una variedad de lenguajes y arquitecturas, ninguno de los cuales sería relevante o relevante para los clientes que llaman a los servicios y ninguno de los cuales tiene el acrónimo "SOA" en ninguna parte de su documentación.

Pero la gerencia quiere "SOA" !!! Así que han comprado servidores realmente caros de una cierta gran empresa que tiene adhesivos "SOA" aplicados sobre los adhesivos anteriores de "Servicio web" que se han aplicado sobre los adhesivos anteriores "JEE" que se han aplicado sobre ... te haces una idea. Y como resultado, nosotros, como desarrolladores, nos sentamos arrastrando y soltando íconos pequeños alrededor de una pantalla para crear "COMPONENTES" "SOA" que funcionan la mitad de bien que si lo hubiéramos hecho con algo simple como frijoles EBJ3, componentes de resorte, etc. .

Entonces, mi consejo es que si le preguntan sobre SOA, diga "Sí, he hecho SOA, he escrito muchos sistemas que hacen uso de una Arquitectura Orientada a Servicios para hacer cosas. ¿Sobre qué tecnología SOA está preguntando?". Y si comienzan a hablar con ojos brillantes y miradas melancólicas sobre COMPONENTES SOA, ARRASTRAR Y COLOCAR, y cómo facilita el desarrollo. ¡Retroceda lentamente y evite el contacto visual!

Creo que puede tener sentido un poco: una cosa es cuando se llaman módulos "esclavos" cuando es necesario, y otra es cuando se tienen procesos de servicio / demonio ejecutándose de forma independiente y respondiendo a sus solicitudes, posiblemente hablando entre ellos, viviendo sus propia vida en otras palabras. Con este enfoque, puede tener un sistema enorme, escalable y físicamente distribuido. He visto algunos en el área de la telefonía móvil, por ejemplo. Pero esto es sólo una conjetura.

(Ahora veamos qué dice Wikipedia sobre SOA ... Whoa).