¿Qué es SOA (arquitectura orientada a servicios)?

Question

Llámame un troll si quieres, pero hablo en serio: ¿cómo es exactamente la nueva tendencia de SOA diferente de la arquitectura de servicio al cliente que estaba construyendo hace 15 años? Sigo escuchando SOA, pero no veo cómo es diferente de lo que siempre hemos hecho.

Hace 10 años, mi empresa tenía varios clientes (en varios idiomas) que hablaban con el mismo servicio. No era XML (era un protocolo binario llamado Microsoft DCOM) y no había descubrimiento automático a través de WSDL, pero eso está bien ya que leer los documentos era igual de fácil. Nuestro sistema incluso fue "abierto" en el sentido en que lo documentamos lo suficiente como para permitirle a terceros hablar con nuestros servicios. No fuimos pioneros, todas las demás empresas que conocí hace 10 años hacían lo mismo.

La ÚNICA diferencia que veo entre entonces y ahora es que ahora hay un solo servicio disponible en Internet, mientras que hace 10 años, cada cliente alojaría su propia instancia del servicio. Pero ese no es un problema de arquitectura: donde el servicio vive físicamente es transparente para cualquiera que use el servicio.

Entonces, ¿qué es exactamente SOA que es diferente de lo que hemos estado haciendo durante años? ¿Es SOA simplemente un término de marketing que representa una mejor práctica que realmente se hizo común hace mucho tiempo? ¿O me estoy perdiendo algo de SOA que es diferente de lo que hemos estado haciendo todo el tiempo?

Answer 1

Profesor Frank Leymann de la Universidad de Stuttgart toma SOA como un concepto clave para su Service oriented Computing (SOC) research work as he speaks about SOA. Se ve que se le pregunta acerca de la definición de SOA y que la conversación resultante podría ser una buena lectura.

Tenga en cuenta que nuestro mapa de ruta es sobre "informática orientada a servicios (SoC)", es decir, el paradigma de cómputo detrás de la orientación al servicio. Service Oriented Architecture (SOA) es una realización arquitectónica de este paradigma de cómputo. Puede comparar esto con "computación cliente/servidor" como paradigma y "navegador/servidor web" o "cliente DB/procedimiento almacenado" como dos (de varias otras) realizaciones arquitectónicas de este paradigma.

...

SOA no es completamente nuevo. Algunos aspectos individuales de SOA se utilizan en la práctica durante mucho tiempo. Por ejemplo, eche un vistazo al "acoplamiento flexible": las empresas están utilizando tecnología de mensajería confiable desde hace décadas para integrar aplicaciones, es decir, para acoplarlas sin apretarlas. No me malinterprete, hay nuevos conceptos en SOA, p. conceptos resultantes de la combinación de conceptos reunidos en SOA, es decir, que resultan de la emergencia.

Las especificaciones del servicio web hacen que las tecnologías correspondientes estén disponibles a través de la plataforma. Es decir. las especificaciones correspondientes no inventan conceptos fundamentalmente nuevos, sino que definen cómo estos conceptos y las implementaciones correspondientes funcionan en entornos heterogéneos. La interoperabilidad resultante es pionera, por lo que SOA es real.

En resumen, SOA es una mezcla de cosas maduras y nuevas cosas emergentes.

También hay un SoC paper reference fecha de abril de 2006.

---

Una búsqueda en Google identifica Prof. Frank Leymann y hisworks.

Answer 2

Olvídate de XML. Olvídate de WSDL. SOA no es una tecnología que puede comprar, aunque a menudo se comercializa de esa manera.

El verdadero objetivo de SOA es todo sobre IT organización. El objetivo de SOA es evitar tener un enorme grupo de "aplicaciones" que tengan grupos de datos aislados y que no se comuniquen entre sí (y, por lo tanto, a menudo dupliquen datos), o solo de forma ineficiente y con errores a través de capas de adaptadores. o sistemas EAI.

Para las grandes empresas, este es un problema grave: tienen literalmente cientos de aplicaciones separadas que no están lo suficientemente integradas. Hay datos duplicados e inconsistentes en todos lados y el resultado es que los clientes se cabrean y se pierde dinero real porque el departamento de facturación sigue enviando facturas por un pedido cancelado y el representante del servicio de atención al cliente no puede encontrar el pedido porque se canceló en el seguimiento del pedido sistema, pero no el sistema de facturación.

Se supone que SOA soluciona esto diseñando cada aplicación desde cero para publicar sus servicios de manera estandarizada y cruzada de manera que otras aplicaciones puedan acceder a los datos y no tengan que duplicarlos.

Desde una perspectiva comercial, esto es muy conveniente. La exageración de la palabra de moda y la sopa de acrónimos son solo los intentos de las empresas de TI para sacar provecho de esa conveniencia. Desafortunadamente, esto ha llevado a muchas personas, incluidos los CEOs, a creer que SOA es un producto que puedes comprar y que hará mágicamente que tu TI sea más eficiente, sin darte cuenta de que esto solo sucederá si también reorganizas toda tu TI (y bastante posiblemente sus unidades de negocios también) para que sea compatible con SOA.

Answer 3

Creo que SOA es tanto un término de marketing como una integración de soluciones existentes con la idea de que en lugar de vender todo el software o la máquina, vendamos los servicios.

Answer 4

Neal Ford tiene muchas opiniones fuertes con respecto a SOA. Puede encontrar su punto de vista interesante.

Tactics vs. Strategy (SOA & The Tarpit of Irrelevancy)

Standards Based vs. Standardized (SOA & the Tarpit of Irrelevancy)

Tools & Anti-Behavior (SOA & the Tarpit of Irrelevancy)

Rubick's Cubicle (SOA & the Tarpit of Irrelevancy)

The Triumph of Hope over Reason (SOA & The Tarpit of Irrelevancy)

Guerrilla SOA (SOA & The Tarpit of Irrelevancy)

Answer 5

Permítame usar el famoso chico de azotes de Integration Hell: Telco.

En la década de los 90, las compañías de teléfonos celulares eran pletóricas en mi vecindario, casi tan abundantes como los distribuidores de larga distancia posibilitados por la desregulación de las comunicaciones a mediados de los 90. Bueno, el tiempo continúa, y Bell Atlantic se convierte en la potencia que es Verizon, y se traga compañía tras compañía (y al menos un Baby Bell). Cada una de estas empresas tiene tecnologías en su lugar, en torres, en equipos de conmutación, en sistemas de facturación que son COMPLETAMENTE incompatibles entre sí.

Entonces, la compañía se va y dice, está bien, tenemos estos modelos de cómo hacemos negocios, pongamos una cara amable y consistente en TODA nuestra tecnología en forma de WSDL/SOAP/XSD - todos los idiomas y sistemas ¡hoy tenemos una interfaz con esto!Lenta pero seguramente, la compañía está haciendo que todos sus sistemas sean capaces de informar sobre las capacidades, ser interrogados con fines de carga y facturación, y expuestos para que los futuros visionarios exploten de maneras que aún no se han tenido en cuenta.

Cualquiera puede construir un cliente SOA. Cualquiera con wget y un editor de texto. Y cualquiera puede analizar los resultados (XML).

Eso es lo que es fundamentalmente diferente de las arquitecturas pasadas de cliente/servidor. El otro día le estaba hablando a alguien sobre la interfaz de los sistemas basados ​​en Cobol y Smalltalk con las arquitecturas SOA. Ese es un problema fácil de resolver. Dime que puedes decir lo mismo de tus sistemas DCOM.

Answer 6

SOA es nada más que una forma de diseño, en la que los módulos se comunican entre sí a través de "servicios". Es solo eso, y ahora la siguiente pregunta es: ¿qué es exactamente un "servicio" y cuál es su diferencia con un "método" regular?

Un servicio es una operación que realiza una sola operación comercial atómica. Esta atomicidad lo hace altamente reutilizable de muchos módulos. Entonces, una operación comercial compleja es solo la búsqueda de la invocación de muchos de estos servicios en un orden específico.

SOA no tiene nada que ver con la tecnología específica, es solo una forma específica de diseño.

Answer 7

Para mí, una arquitectura orientada a servicios se produce cuando una empresa desea integrar una selección de aplicaciones dispares que se refieren a un dominio común en un conjunto de servicios interoperables que operan contra un solo origen de datos.

En el caso de una nueva compañía de inicio con una idea para un elemento de software/suite de software, no puedo ver cómo una empresa puede comenzar con una arquitectura orientada a servicios desde el principio. Al principio, cada solución (que bien puede evolucionar hasta convertirse en un servicio que pueda volverse interoperable) debería tratar de resolver su espacio problemático de forma aislada.

Quizás esté en el mapa de ruta de una capacidad o suite empresarial para que cada solución se convierta en un servicio interoperable a medida que las soluciones se completan y entran en servicio. Para esto, tal vez los equipos de desarrollo llevarán a cabo un enfoque modular/orientado a componentes para construir la solución (servicio eventual), para facilitar la inclusión de la solución como un servicio en una Arquitectura Orientada a Servicios.

En caso de que las islas de software existentes se conviertan en servicios interoperables en una arquitectura orientada a servicios, el enfoque permite que los elementos de software, que pueden distribuirse y escribirse en diferentes idiomas, se comuniquen a través de una API expuesta y/o protocolo común (por ejemplo, un sabor de servicio web) y formato de datos genérico (por ejemplo, XML).

SOA es un enfoque o idea. No es un marco o una herramienta. Cuando WDSLs y EJBs son eliminados, esto a menudo se olvida ... como es que la idea de SOA no es nueva en absoluto.

Answer 8

La mayoría de las respuestas aquí parecen indicar que SOA (Service Oriented architecture) se trata de crear aplicaciones de forma estandarizada para que otras aplicaciones puedan interactuar con ellas de forma independiente de la plataforma.

No estoy seguro de si el significado ha cambiado desde entonces, pero he tenido la oportunidad de trabajar con una empresa que ofrece SOA suite y seguir mis ideas al respecto.

Por supuesto, cuando diseña una aplicación no puede garantizar que sea compatible con plataformas cruzadas. Tome por ejemplo stock Trading systems.Usan Fix protocol para transferir mensajes. ¿Espera que ahora devuelva datos en formato XML para que pueda ser llamado SOA? ¡Definitivamente no! SOA es un enfoque arquitectónico que puede ayudarlo decouple your application/services y dejar que interactúen entre sí. Backbone of SOA es un ESB (Enterprise Service Bus) que se utiliza para transferir datos de un servicio a otro. La arquitectura SOA debe encargarse de las conversiones de formatos. Por ejemplo -

FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2) 

Estos módulos de conversión se denominan comúnmente como adapters y son generalmente parte de la suite SOA. Por un poco más de información se refieren a otra respuesta -

Difference between SOA and ESB

Claro SOA es una palabra es exagerada con fines de marketing. Técnicamente hablando, es tan simple como deserializar y serializar datos para que los servicios se puedan desacoplar y sean independientes de la plataforma, pero la idea subyacente es concreta.

Consulte también Wiki page para lo mismo.

Answer 9

Una arquitectura orientada a servicios (SOA) es un patrón arquitectónico en el que los softwares están diseñados como bloques de construcción. es decir, desarrollo modular, que hace que la flexibilidad se pueda ensamblar de la manera que queramos. Si desea comenzar un nuevo proyecto en lugar de comenzar de cero, podemos reutilizar los servicios y si desea un nuevo servicio, podemos integrarlo fácilmente con el servicio existente para realizar un nuevo proyecto. Así que podemos ahorrar mucho tiempo y dinero. Los principios básicos de la arquitectura orientada al servicio son independientes de los proveedores, los productos y las tecnologías.

Analogía: construcción de juguetes utilizando bloques de construcción de Lego.

Answer 10

En realidad, SOA es un conjunto de servicios bien definidos. Básicamente, SOA usa un servicio débilmente acoplado para obtener el resultado deseado fácilmente. Los detalles de implementación de un servicio están ocultos para el cliente/consumidor, por lo que cualquier cambio en la implementación no afectará el servicio hasta que el contrato entre ellos cambie. Los proveedores de servicios son componentes que ejecutan cierta lógica comercial basada en entradas y salidas predeterminadas, y exponen esta funcionalidad a través de una implementación SOA. Esto permite que los sistemas basados ​​en SOA respondan de manera más rápida y rentable para el negocio. La principal diferencia entre el componente y SOA es que SOA proporciona un mensaje de estándares abiertos que no es específico de ningún lenguaje de programación o plataforma. Como resultado, puede lograr un alto grado de acoplamiento flexible e interoperabilidad entre plataformas y tecnologías. En un mundo tradicional cliente-servidor, el proveedor será un servidor y el consumidor será un cliente. Puede leer más sobre SOA aquí: Service Oriented architecture (SOA)