Service-Oriented Architecture
Orientación a servicios, no un producto
Service-Oriented Architecture, o SOA, organiza capacidades mediante servicios, descripciones y condiciones explícitas de interacción. OASIS la define como un paradigma para utilizar capacidades distribuidas que pueden pertenecer a dominios de ownership diferentes. Su Reference Model es conceptual y no prescribe una tecnología. SOA Reference Model 1.0, sección 2.
El Atlas lo documenta como architecture-profile para comparar decisiones de integración, contratos, comunicación y gobierno. No convierte ese modelo de referencia amplio en una topología única. Una arquitectura concreta debe precisar qué servicios existen, quién los controla y cómo colaboran.
SOA no equivale a ESB, SOAP ni Web Services. Esas tecnologías o mecanismos pueden intervenir en implementaciones. No definen por sí mismos service orientation ni garantizan contratos útiles, interoperabilidad o autonomía.
Necesidades, capacidades y contratos
Un servicio permite acceder a una capacidad sin conocer toda su implementación. La descripción debe hacer comprensibles funciones, condiciones y efectos relevantes. OASIS destaca visibility, interaction y real-world effect: poder encontrar una capacidad pertinente, utilizarla y entender qué resultado produce.
Un contrato incluye más que la forma de un mensaje. Necesita semántica, restricciones y expectativas: qué significa aceptar una solicitud, cuándo se considera completada y qué información puede consultar el consumidor. Tener el mismo formato de serialización no garantiza interoperabilidad de significado.
Discoverability puede apoyarse en catálogos, documentación o acuerdos previos. No exige un registro dinámico ni que todos los consumidores descubran servicios durante ejecución. El mecanismo debe responder a necesidades reales de los participantes.
Autonomía e integración empresarial
Service orientation permite relacionar capacidades bajo autoridades diferentes. Es relevante cuando sistemas heterogéneos, equipos o entidades necesitan colaborar sin compartir toda su implementación ni ciclo de vida.
Loose coupling es un objetivo que requiere contratos y límites deliberados; no se obtiene por envolver una base de datos con un endpoint. La autonomía depende de decisiones que cada proveedor puede tomar sin imponer cambios incompatibles a otros.
Una capacidad puede pertenecer a un sistema existente y ofrecerse mediante una integración. El servicio expuesto y el sistema que realiza el trabajo no necesariamente comparten el mismo alcance. El análisis debe conservar esa distinción en lugar de suponer un proceso nuevo por cada capacidad.
Lectura mediante decision axes
| Eje | Qué precisa una implementación de SOA |
|---|---|
| Decomposition | Capacidades ofrecidas como servicios; granularidad contextual. |
| Dependency Structure | Consumidores dependen de contratos, políticas y compromisos explícitos. |
| Communication | Interacciones remotas mediante protocolos apropiados al contexto. |
| Coordination | Composición de capacidades, con responsabilidades de proceso deliberadas. |
| Data Ownership | Autoridades sobre información; no prescribe una base compartida o separada. |
| Isolation | Límites de servicio y recursos efectivos; middleware común puede ampliar fallos. |
| Tenancy | Condiciones de acceso y separación entre participantes o clientes. |
| Deployment | Ciclos propios de proveedores; independencia concreta por analizar. |
| Execution Model | Servicios, adaptadores y procesos; no impone un runtime. |
| Scaling | Capacidad de servicios e integración; recursos compartidos pueden limitarla. |
Esta lectura no asigna puntuaciones universales. La orientación a servicios atraviesa distintas organizaciones de deployment y no debe forzarse sobre un único eje de distribución.
Composición y coordinación
Una capacidad de negocio puede componerse con otras. La coordinación puede concentrarse en un participante que dirige pasos o distribuirse mediante acuerdos de interacción. Orchestration y choreography expresan énfasis distintos; ninguna forma es requisito universal de SOA.
Supongamos un proceso que reúne validación de identidad, autorización de gasto y confirmación de reserva. La composición necesita definir quién conoce el progreso, qué sucede ante un rechazo y cómo se trata un resultado pendiente. No basta con dibujar conexiones entre tres servicios.
saga-pattern permite estudiar recuperación en determinados procesos distribuidos. Las garantías concretas dependen de los participantes y de sus efectos. Reutilizar un servicio no implica que pueda revertirse cualquier operación realizada por él.
Datos, semántica y consistencia
El estado compartido de una interacción puede representar hechos y compromisos comprensibles para sus participantes; no significa necesariamente una tabla común. Debe quedar claro quién tiene autoridad para cambiar la información y qué datos internos siguen privados.
Una integración puede atravesar sistemas con diferentes modelos de transacción y disponibilidad. El consumidor necesita comprender cuándo un resultado es provisional, confirmado o desconocido. delivery-guarantees ayuda a separar entrega de mensajes y efectos de negocio.
Un modelo de datos común puede reducir traducciones y también forzar coordinación de cambios. Un contrato específico puede preservar autonomía y exigir adaptadores. La elección debe considerar evolución, no solo facilidad de la primera integración.
Governance y operación
Gobernar servicios implica decidir autoridad, políticas, responsabilidades y cómo verificar su cumplimiento. La arquitectura de referencia OASIS describe acuerdos entre ownership domains, gestión de cambios y resolución de conflictos. No exige una sola autoridad central para todos los participantes. Reference Architecture Foundation, sección 5.1.
En algunas implementaciones empresariales históricas hubo estándares centralizados, middleware compartido y fuerte coordinación de composición. Son tendencias de práctica, no la definición completa de SOA. Un ESB puede facilitar traducción o routing y convertirse en dependencia común si acumula responsabilidades.
Los costos incluyen mantener contratos, versiones, acuerdos operativos y trazabilidad entre sistemas. Las pruebas necesitan contemplar semántica y compatibilidad, no solo que el mensaje llegue. La observabilidad debe relacionar un fallo técnico con el proceso y la autoridad responsable de resolverlo.
SOA frente a Microservices
microservices comparte ideas de capacidades de negocio, contratos, autonomía y comunicación distribuida. Lewis y Fowler reconocen afinidad con ciertas propuestas de SOA y explican que el término se usó de maneras muy diferentes. Microservices and SOA.
Microservices suele enfatizar independent deployability, ownership descentralizado y evolución de servicios delimitados. Muchas implementaciones empresariales de SOA pusieron más atención en integrar sistemas heterogéneos, composición y acuerdos transversales. Son diferencias frecuentes de énfasis, no leyes que excluyan otras variantes.
No conviene afirmar «Microservices es SOA bien hecha» ni que no existe relación entre ambos. La comparación necesita identificar qué propuesta de SOA se considera y qué compromisos concretos adopta el sistema.
Ejemplo de decisión situada
Supongamos una organización que necesita combinar capacidades de un sistema contable, un proveedor externo y una aplicación de atención. Reemplazar todos por servicios nuevos no es el objetivo. Se busca interacción comprensible con responsabilidades y efectos definidos.
Un acuerdo sobre facturación debe precisar aceptación, confirmación y corrección, además del protocolo. Una traducción central puede reducir duplicación y convertirse en un punto de coordinación. Traducciones distribuidas pueden preservar autonomía y multiplicar mantenimiento.
La elección se examina por contratos, cambios esperados, riesgo operativo y autoridad sobre datos. La cantidad de servicios no indica madurez ni asegura que una integración sea barata.
Composición y elección
Un servicio puede organizar su implementación mediante Layered o Hexagonal. Una aplicación monolítica puede ofrecer capacidades a un ecosistema SOA. Event-Driven Architecture puede intervenir en sus interacciones sin reemplazar el análisis de políticas y efectos.
SOA es razonable cuando la integración entre capacidades y ownership domains requiere acuerdos explícitos. Es insuficiente como explicación si solo enumera productos. architectural-drivers, architectural-significance y architecture-profiles permiten comparar necesidades, autonomía, coordinación y costos con otras aproximaciones.