Procesamiento Cooperativo y Arquitectura Cliente-Servidor
Arquitecturas Multinivel, SOA, Buses de Interoperabilidad y Aplicaciones en el Servicio Andaluz de Salud
📋 Resumen Ejecutivo
Este tema aborda las arquitecturas distribuidas fundamentales en los sistemas de información modernos, desde el procesamiento cooperativo hasta las arquitecturas orientadas a servicios (SOA). Se analiza la evolución de las arquitecturas cliente-servidor, los diferentes modelos multinivel, los servidores de aplicaciones y su implementación específica en el ecosistema sanitario del Servicio Andaluz de Salud.
Mapa Conceptual del Tema
🗺️ Arquitecturas Distribuidas y SOA en el SAS
- • Separación de roles
- • Recursos compartidos
- • Escalabilidad
- • Servicios reutilizables
- • Bajo acoplamiento
- • Interoperabilidad
✗ Escalabilidad limitada
✓ Mantenible
✗ Mayor complejidad
- • Servicios
- • Proveedores
- • Consumidores
- • Registro
- • Enrutamiento
- • Transformación
- • Orquestación
- • Políticas
- • Catálogo servicios
- • SLAs y métricas
- • Seguridad
📚 Leyenda
1. Introducción al Procesamiento Distribuido
El procesamiento cooperativo y las arquitecturas cliente-servidor representan un cambio paradigmático en la forma en que se diseñan, desarrollan y despliegan los sistemas de información. A diferencia de los sistemas centralizados tradicionales basados en mainframes, estas arquitecturas permiten distribuir la carga de procesamiento entre múltiples componentes, mejorando la escalabilidad, disponibilidad y rendimiento del sistema.
En el contexto actual (2024-2025), estas arquitecturas han evolucionado significativamente, incorporando conceptos de microservicios, contenedorización y computación en la nube, pero los principios fundamentales del procesamiento cooperativo siguen siendo vigentes y aplicables en entornos empresariales y sanitarios como el SAS.
1.1. Evolución Histórica
La evolución de las arquitecturas de sistemas ha pasado por diferentes etapas:
- Sistemas centralizados (años 60-70): Mainframes que concentraban todo el procesamiento y almacenamiento.
- Sistemas cliente-servidor (años 80-90): Distribución inicial del procesamiento entre estaciones de trabajo y servidores.
- Arquitecturas multinivel (años 90-2000): Separación de lógica de presentación, negocio y datos.
- SOA y microservicios (2000-actualidad): Servicios reutilizables, desacoplados y escalables independientemente.
- Cloud-native y serverless (2010-actualidad): Arquitecturas optimizadas para entornos cloud con escalado automático.
2. Procesamiento Cooperativo: Fundamentos
El procesamiento cooperativo es un modelo de computación distribuida donde múltiples procesadores trabajan de manera coordinada para ejecutar una o más tareas. En este paradigma, el trabajo se divide entre diferentes componentes del sistema, cada uno especializado en una función específica.
2.1. Características del Procesamiento Cooperativo
ℹ️ Principios Fundamentales
El procesamiento cooperativo se basa en la división del trabajo, la especialización de funciones y la comunicación eficiente entre componentes. Cada elemento del sistema contribuye con sus capacidades específicas al logro del objetivo común.
- División de tareas: El trabajo se distribuye entre diferentes nodos o procesos según sus capacidades y especialización.
- Comunicación interproceso: Los componentes intercambian información mediante protocolos establecidos (RPC, mensajería, APIs REST, etc.).
- Sincronización: Mecanismos para coordinar la ejecución de tareas concurrentes y mantener la coherencia de datos.
- Tolerancia a fallos: Capacidad del sistema para continuar operando ante fallos parciales de componentes.
- Escalabilidad horizontal: Posibilidad de añadir más nodos para incrementar la capacidad de procesamiento.
2.2. Modelos de Procesamiento Cooperativo
Existen diferentes modelos según cómo se distribuye el procesamiento:
- Modelo maestro-esclavo: Un nodo maestro coordina y distribuye tareas a nodos esclavos que ejecutan el procesamiento.
- Modelo peer-to-peer (P2P): Todos los nodos tienen capacidades equivalentes y pueden actuar como clientes o servidores.
- Modelo cliente-servidor: Separación clara de roles entre clientes que solicitan servicios y servidores que los proporcionan.
- Modelo publicador-suscriptor: Los componentes publican eventos y otros se suscriben a los eventos de interés.
3. Arquitectura Cliente-Servidor: Características Principales
La arquitectura cliente-servidor es el modelo de procesamiento cooperativo más extendido en la industria. En este modelo, el cliente solicita servicios y el servidor los proporciona, estableciendo una relación claramente definida entre ambos roles.
3.1. Componentes Fundamentales
Cliente
El cliente es el componente que inicia las peticiones al servidor. Sus características principales son:
- Interfaz de usuario (GUI o CLI) para la interacción con el usuario final
- Lógica de presentación y validación básica de datos
- Gestión de sesiones y estado local
- Comunicación con uno o más servidores
Servidor
El servidor espera y responde a las peticiones de los clientes. Sus funciones incluyen:
- Procesamiento de la lógica de negocio
- Gestión del acceso a datos y recursos compartidos
- Control de concurrencia y transacciones
- Autenticación, autorización y auditoría
- Gestión de múltiples conexiones simultáneas
3.2. Características Distintivas
| Característica | Descripción | Beneficio |
|---|---|---|
| Separación de responsabilidades | Cliente y servidor tienen roles claramente diferenciados | Mayor mantenibilidad y especialización |
| Recursos compartidos | Múltiples clientes acceden a recursos centralizados | Optimización de recursos y consistencia de datos |
| Escalabilidad | Posibilidad de escalar clientes y servidores independientemente | Adaptación a demandas variables de carga |
| Heterogeneidad | Clientes y servidores pueden ejecutarse en diferentes plataformas | Flexibilidad tecnológica y aprovechamiento de inversiones |
| Centralización de servicios | Lógica de negocio y datos centralizados en servidores | Facilita actualizaciones, backups y seguridad |
⚠️ Concepto Clave: Acoplamiento
El grado de acoplamiento entre cliente y servidor determina la flexibilidad de la arquitectura. Un bajo acoplamiento permite que los componentes evolucionen independientemente, mientras que un alto acoplamiento crea dependencias que dificultan el mantenimiento y la evolución del sistema.
3.3. Protocolos de Comunicación
La comunicación cliente-servidor se basa en protocolos estándar que definen el formato y secuencia de mensajes:
- HTTP/HTTPS: Protocolo estándar para aplicaciones web y APIs REST
- TCP/IP: Base de la comunicación en redes, orientado a conexión
- UDP: Protocolo sin conexión para comunicaciones donde la latencia es crítica
- WebSocket: Comunicación bidireccional full-duplex para aplicaciones en tiempo real
- gRPC: Framework de RPC moderno basado en HTTP/2 y Protocol Buffers
- AMQP/MQTT: Protocolos de mensajería para arquitecturas asíncronas
4. Arquitectura de Dos Niveles (2-Tier)
La arquitectura de dos niveles es el modelo cliente-servidor más básico, donde existe una separación física entre el cliente (primer nivel) y el servidor de datos (segundo nivel).
4.1. Configuración Típica
En una arquitectura 2-tier, el cliente contiene tanto la interfaz de usuario como la lógica de negocio, mientras que el servidor se encarga exclusivamente de la gestión de datos.
ℹ️ Modelo Cliente Pesado (Fat Client)
En la arquitectura 2-tier clásica, el cliente es «pesado» porque contiene la mayor parte de la lógica de la aplicación. El servidor de base de datos actúa principalmente como un repositorio de datos.
Componentes:
- Nivel 1 – Cliente: Interfaz de usuario + Lógica de negocio + Lógica de presentación
- Nivel 2 – Servidor de datos: SGBD (Sistema Gestor de Base de Datos) + Almacenamiento persistente
4.2. Ventajas de la Arquitectura 2-Tier
- Simplicidad: Diseño y desarrollo más sencillo al tener menos componentes
- Rendimiento: Menos saltos de red, comunicación directa entre cliente y base de datos
- Coste inicial reducido: Menor inversión en infraestructura y licencias
- Adecuada para aplicaciones pequeñas: Ideal para sistemas con pocos usuarios concurrentes
- Facilidad de debugging: Menor complejidad en la depuración de errores
4.3. Inconvenientes de la Arquitectura 2-Tier
⛔ Limitaciones Críticas
- Escalabilidad limitada: Difícil gestionar miles de conexiones directas a la base de datos
- Mantenimiento complejo: Cambios en la lógica de negocio requieren actualizar todos los clientes
- Seguridad comprometida: Los clientes tienen acceso directo a la base de datos
- Acoplamiento fuerte: El cliente depende directamente del esquema de la base de datos
- Reutilización difícil: La lógica de negocio está distribuida en múltiples clientes
4.4. Casos de Uso Actuales
Aunque menos común en sistemas empresariales modernos, la arquitectura 2-tier todavía se utiliza en:
- Aplicaciones departamentales pequeñas con usuarios limitados
- Herramientas de administración y utilidades internas
- Aplicaciones de escritorio que requieren acceso directo a bases de datos locales
- Prototipos y pruebas de concepto rápidas
5. Arquitectura de Tres Niveles (3-Tier)
La arquitectura de tres niveles introduce una capa intermedia entre el cliente y el servidor de datos, separando la lógica de presentación, la lógica de negocio y la lógica de datos. Este modelo se ha convertido en el estándar de facto para aplicaciones empresariales.
5.1. Estructura y Componentes
Nivel 1 – Capa de Presentación (Presentation Tier)
También conocida como capa de interfaz o cliente ligero (thin client):
- Gestiona la interfaz de usuario (web, móvil, escritorio)
- Captura la entrada del usuario y muestra los resultados
- Realiza validaciones básicas de formato
- No contiene lógica de negocio significativa
- Tecnologías: HTML/CSS/JavaScript, React, Angular, Vue.js, aplicaciones móviles nativas
Nivel 2 – Capa de Lógica de Negocio (Business Logic Tier)
También llamada capa de aplicación o middleware:
- Implementa las reglas de negocio y procesos de la organización
- Coordina las operaciones entre la capa de presentación y datos
- Realiza validaciones complejas y cálculos
- Gestiona transacciones y flujos de trabajo
- Tecnologías: Servidores de aplicaciones (Java EE, .NET, Node.js), APIs REST, microservicios
Nivel 3 – Capa de Datos (Data Tier)
Responsable del almacenamiento y gestión de datos:
- Sistema gestor de base de datos (SGBD)
- Gestión de persistencia y recuperación de datos
- Control de integridad referencial y transacciones ACID
- Optimización de consultas y procedimientos almacenados
- Tecnologías: Oracle, PostgreSQL, MySQL, SQL Server, MongoDB, Redis
🎯 Separación de Responsabilidades
La arquitectura 3-tier aplica el principio de «Separación de Concerns» (SoC), donde cada capa tiene una responsabilidad única y bien definida. Esto facilita el desarrollo paralelo, testing independiente y mantenimiento evolutivo del sistema.
5.2. Ventajas de la Arquitectura 3-Tier
| Ventaja | Descripción | Impacto en el Negocio |
|---|---|---|
| Mantenibilidad | Cambios en una capa no afectan a las otras | Reducción de costes de mantenimiento hasta un 40% |
| Escalabilidad | Cada capa puede escalarse independientemente | Adaptación eficiente a picos de demanda |
| Reutilización | La lógica de negocio puede ser consumida por múltiples interfaces | Desarrollo más rápido de nuevas aplicaciones |
| Seguridad | Control centralizado de acceso a datos y reglas de negocio | Reducción de vulnerabilidades y cumplimiento normativo |
| Flexibilidad tecnológica | Posibilidad de cambiar tecnologías en cada capa | Protección de inversiones y adopción de innovaciones |
| Testing independiente | Cada capa puede ser probada aisladamente | Mayor calidad del software y detección temprana de errores |
5.3. Inconvenientes de la Arquitectura 3-Tier
- Complejidad arquitectónica: Mayor número de componentes y puntos de integración
- Latencia de red: Cada salto entre capas introduce retardo adicional
- Coste de infraestructura: Requiere más servidores y recursos de red
- Debugging complejo: Los errores pueden propagarse a través de múltiples capas
- Overhead de comunicación: Serialización/deserialización de datos entre capas
5.4. Patrones de Diseño Comunes
En la arquitectura 3-tier se aplican diversos patrones de diseño para organizar el código:
- MVC (Model-View-Controller): Separación de datos, presentación y control
- DAO (Data Access Object): Abstracción del acceso a datos
- DTO (Data Transfer Object): Objetos para transportar datos entre capas
- Service Layer: Capa de servicios que encapsula la lógica de negocio
- Repository Pattern: Abstracción de la persistencia de datos
- Facade Pattern: Interfaz simplificada para subsistemas complejos
✅ Mejores Prácticas en Arquitectura 3-Tier
- Definir interfaces claras entre capas (contratos de API)
- Implementar logging y monitorización en todas las capas
- Utilizar cachés estratégicamente para reducir latencia
- Aplicar principios SOLID en el diseño de cada capa
- Documentar las APIs y contratos entre capas
- Implementar circuit breakers para tolerancia a fallos
6. Arquitecturas Multinivel (N-Tier)
Las arquitecturas multinivel o N-tier extienden el concepto de 3-tier añadiendo capas adicionales para mejorar la modularidad, seguridad y escalabilidad. En sistemas empresariales complejos, es común encontrar 4, 5 o más niveles.
6.1. Capas Adicionales Comunes
Capa de Servicios (Service Layer)
Se sitúa entre la capa de presentación y la de lógica de negocio:
- Expone APIs REST o SOAP para consumo externo
- Gestiona autenticación y autorización (OAuth, JWT)
- Implementa rate limiting y throttling
- Proporciona versionado de APIs
Capa de Integración (Integration Layer)
Facilita la comunicación con sistemas externos:
- Adaptadores para sistemas legacy
- Conectores a servicios de terceros
- Transformación de formatos de datos
- Bus de Servicio Empresarial (ESB)
Capa de Caché (Caching Layer)
Mejora el rendimiento almacenando datos frecuentemente accedidos:
- Redis, Memcached para caché distribuida
- CDN (Content Delivery Network) para contenido estático
- Cache de aplicación y base de datos
- Estrategias de invalidación de caché
Capa de Mensajería (Messaging Layer)
Permite comunicación asíncrona entre componentes:
- Colas de mensajes (RabbitMQ, Apache Kafka)
- Event sourcing y CQRS
- Procesamiento de eventos en tiempo real
- Desacoplamiento temporal entre servicios
ℹ️ Arquitectura de 4 Capas Típica
Una configuración común en sistemas empresariales modernos incluye: 1) Capa de Presentación (Web/Móvil), 2) Capa de API Gateway, 3) Capa de Servicios de Negocio, 4) Capa de Datos y Persistencia. Esta estructura proporciona un equilibrio entre complejidad y beneficios.
6.2. Ventajas de las Arquitecturas N-Tier
- Modularidad extrema: Cada capa puede ser desarrollada y desplegada independientemente
- Escalabilidad granular: Escalar únicamente las capas que lo necesiten
- Seguridad en profundidad: Múltiples barreras de seguridad (Defense in Depth)
- Separación de equipos: Equipos especializados pueden trabajar en diferentes capas
- Tolerancia a fallos: El fallo de una capa no necesariamente afecta a todo el sistema
- Optimización específica: Cada capa puede optimizarse según sus requisitos particulares
6.3. Desafíos de las Arquitecturas N-Tier
⛔ Complejidad Operacional
A medida que aumenta el número de capas, la complejidad operacional crece exponencialmente. Es fundamental contar con herramientas robustas de monitorización, logging distribuido (ELK Stack, Splunk) y trazabilidad (OpenTelemetry, Jaeger) para gestionar esta complejidad.
- Latencia acumulada: Cada capa adicional añade overhead de comunicación
- Debugging complejo: Rastrear errores a través de múltiples capas es desafiante
- Coordinación de despliegues: Actualizaciones pueden requerir sincronización entre capas
- Gestión de versiones: Compatibilidad entre versiones de diferentes capas
- Costes operacionales: Mayor número de servidores, licencias y personal especializado
6.4. Cuándo Usar Arquitecturas N-Tier
Las arquitecturas multinivel son apropiadas cuando:
- El sistema tiene requisitos de alta disponibilidad (99.9% o superior)
- Se necesita escalabilidad masiva (millones de usuarios)
- Existen múltiples canales de acceso (web, móvil, APIs públicas)
- Los requisitos de seguridad son estrictos (sectores regulados como sanidad, banca)
- El sistema debe integrarse con múltiples sistemas externos
- La organización cuenta con equipos especializados por dominio tecnológico
7. Servidores de Aplicaciones
Los servidores de aplicaciones son plataformas de software que proporcionan un entorno completo para ejecutar aplicaciones empresariales, gestionando aspectos como transacciones, seguridad, concurrencia, pool de conexiones y balanceo de carga.
7.1. Funcionalidades Clave
Gestión de Transacciones
- Soporte para transacciones distribuidas (XA, JTA)
- Garantías ACID en operaciones complejas
- Coordinación de transacciones entre múltiples recursos
- Recuperación automática ante fallos
Pool de Conexiones
- Reutilización eficiente de conexiones a bases de datos
- Configuración de tamaños mínimos y máximos
- Timeouts y validación de conexiones
- Reducción del overhead de establecimiento de conexiones
Seguridad Integrada
- Autenticación (LDAP, OAuth, SAML)
- Autorización basada en roles (RBAC)
- Cifrado SSL/TLS de comunicaciones
- Gestión de sesiones seguras
Clustering y Alta Disponibilidad
- Balanceo de carga entre múltiples instancias
- Replicación de sesiones
- Failover automático
- Health checks y auto-recuperación
7.2. Principales Modelos del Mercado (2024-2025)
| Servidor de Aplicaciones | Proveedor | Características Principales | Casos de Uso Típicos |
|---|---|---|---|
| Apache Tomcat | Apache Software Foundation | Contenedor de servlets ligero, Java EE parcial, open source | Aplicaciones web Java, microservicios Spring Boot |
| WildFly (JBoss) | Red Hat | Java EE completo, modular, clustering avanzado | Aplicaciones empresariales Java EE, sistemas críticos |
| WebLogic | Oracle | Java EE completo, alta disponibilidad, integración Oracle | Grandes empresas, integración con productos Oracle |
| WebSphere | IBM | Java EE completo, robustez empresarial, mainframe integration | Entornos IBM, aplicaciones mission-critical |
| Node.js | OpenJS Foundation | JavaScript, event-driven, alto rendimiento I/O | APIs REST, aplicaciones real-time, microservicios |
| .NET (Kestrel) | Microsoft | Cross-platform, alto rendimiento, integración Azure | Aplicaciones .NET Core, servicios Windows/Azure |
| Nginx + uWSGI/Gunicorn | Nginx Inc. | Alto rendimiento, reverse proxy, Python/Ruby support | Aplicaciones Python (Django, Flask), Ruby on Rails |
✅ Tendencia Actual: Contenedores y Kubernetes
En 2024-2025, la tendencia dominante es ejecutar aplicaciones en contenedores (Docker) orquestados por Kubernetes, en lugar de servidores de aplicaciones tradicionales. Esto proporciona mayor portabilidad, escalabilidad automática y despliegues más ágiles. Frameworks como Spring Boot (con Tomcat embebido) y Node.js se ejecutan directamente en contenedores.
7.3. Criterios de Selección
Al elegir un servidor de aplicaciones, se deben considerar:
- Requisitos funcionales: ¿Necesita Java EE completo o basta con un contenedor de servlets?
- Rendimiento: Throughput, latencia, uso de memoria y CPU
- Escalabilidad: Capacidad de crecimiento horizontal y vertical
- Coste: Licencias (comercial vs. open source), costes operacionales
- Ecosistema: Compatibilidad con frameworks y herramientas existentes
- Soporte: Disponibilidad de soporte técnico y comunidad
- Seguridad: Historial de vulnerabilidades, tiempo de respuesta a parches
- Cloud-readiness: Compatibilidad con entornos cloud y contenedores
8. Arquitecturas Orientadas a Servicios (SOA)
SOA (Service-Oriented Architecture) es un paradigma arquitectónico que estructura una aplicación como una colección de servicios interconectados, débilmente acoplados, reutilizables y autónomos. Cada servicio implementa una funcionalidad de negocio específica y puede ser consumido por múltiples aplicaciones.
8.1. Principios Fundamentales de SOA
📐 Los 8 Principios de SOA
- Contrato de Servicio Estándar: Los servicios se adhieren a un contrato de comunicación definido
- Bajo Acoplamiento: Los servicios minimizan las dependencias entre sí
- Abstracción: Los servicios ocultan su lógica interna del mundo exterior
- Reusabilidad: Los servicios pueden ser reutilizados por múltiples consumidores
- Autonomía: Los servicios tienen control sobre su propia lógica y datos
- Sin Estado: Los servicios no mantienen estado entre invocaciones
- Descubribilidad: Los servicios pueden ser descubiertos y entendidos mediante metadatos
- Composabilidad: Los servicios pueden combinarse para crear servicios más complejos
8.2. Componentes de una Arquitectura SOA
Servicio (Service)
Unidad funcional básica que encapsula una capacidad de negocio específica:
- Interfaz bien definida (WSDL para SOAP, OpenAPI para REST)
- Implementación independiente de la tecnología del consumidor
- Versionado explícito para evolución controlada
- Documentación accesible y comprensible
Proveedor de Servicios (Service Provider)
- Entidad que implementa y publica el servicio
- Responsable del mantenimiento y evolución del servicio
- Define los SLAs (Service Level Agreements)
Consumidor de Servicios (Service Consumer)
- Aplicación o componente que invoca los servicios
- Debe adherirse al contrato del servicio
- Gestiona errores y excepciones del servicio
Registro de Servicios (Service Registry)
- Catálogo centralizado de servicios disponibles
- Facilita el descubrimiento dinámico de servicios
- Almacena metadatos, contratos y políticas
- Ejemplos: UDDI (histórico), Consul, Eureka, Apache ZooKeeper
Bus de Servicios Empresarial (ESB)
Infraestructura de integración que facilita la comunicación entre servicios (se detalla en sección 10).
8.3. Protocolos y Estándares SOA
SOAP (Simple Object Access Protocol)
- Protocolo basado en XML para intercambio de mensajes estructurados
- WS-* stack: WS-Security, WS-ReliableMessaging, WS-AtomicTransaction
- Contratos formales mediante WSDL (Web Services Description Language)
- Mayor overhead pero más robusto para transacciones complejas
REST (Representational State Transfer)
- Estilo arquitectónico basado en HTTP y recursos
- Operaciones CRUD mediante verbos HTTP (GET, POST, PUT, DELETE)
- Más ligero y sencillo que SOAP
- Ampliamente adoptado para APIs públicas y microservicios
- Documentación mediante OpenAPI/Swagger
Otros Protocolos
- GraphQL: Lenguaje de consulta para APIs, permite al cliente especificar exactamente qué datos necesita
- gRPC: Framework RPC moderno de Google, basado en HTTP/2 y Protocol Buffers, alto rendimiento
- AMQP: Protocolo de mensajería para comunicación asíncrona entre servicios
8.4. Ventajas de SOA
- Reutilización: Los servicios pueden ser consumidos por múltiples aplicaciones, reduciendo duplicación de código
- Interoperabilidad: Servicios implementados en diferentes tecnologías pueden comunicarse
- Agilidad de negocio: Nuevas aplicaciones pueden componerse rápidamente a partir de servicios existentes
- Mantenimiento simplificado: Cambios en un servicio no afectan a otros siempre que se mantenga el contrato
- Escalabilidad independiente: Cada servicio puede escalarse según su demanda específica
- Mejora continua: Los servicios pueden evolucionar sin afectar a todo el ecosistema
8.5. Desafíos de SOA
⛔ Complejidad de Gobernanza
SOA introduce complejidad en la gestión y gobernanza de servicios. Sin un marco de gobierno sólido, puede derivar en proliferación descontrolada de servicios, duplicación de funcionalidades y problemas de versionado.
- Overhead inicial: Diseño, implementación y despliegue de la infraestructura SOA requiere inversión significativa
- Rendimiento: La comunicación entre servicios introduce latencia adicional
- Complejidad de testing: Probar servicios interconectados requiere entornos de prueba complejos
- Gestión de transacciones: Las transacciones distribuidas son más complejas que las locales
- Monitorización: Requiere herramientas especializadas para rastrear flujos entre servicios
- Seguridad: Más puntos de entrada aumentan la superficie de ataque
8.6. SOA vs Microservicios
| Aspecto | SOA Tradicional | Microservicios |
|---|---|---|
| Alcance del servicio | Servicios más grandes, orientados a procesos de negocio | Servicios muy pequeños, orientados a capacidades específicas |
| Comunicación | ESB centralizado, principalmente SOAP | Comunicación punto a punto, principalmente REST/gRPC |
| Datos | Tendencia a bases de datos compartidas | Base de datos por microservicio (database per service) |
| Gobernanza | Centralizada, políticas corporativas estrictas | Descentralizada, equipos autónomos |
| Despliegue | Menos frecuente, coordinado | Continuo, independiente por servicio |
| Objetivo principal | Reutilización y integración empresarial | Agilidad, escalabilidad y despliegue independiente |
ℹ️ Evolución hacia Microservicios
Los microservicios pueden considerarse una evolución de SOA, aplicando sus principios fundamentales pero con un enfoque más granular, descentralizado y cloud-native. Ambos paradigmas pueden coexistir en una organización, usando SOA para integración empresarial y microservicios para aplicaciones nuevas.
9. Gobierno SOA
El gobierno SOA es el conjunto de políticas, procesos, roles y responsabilidades que aseguran que los servicios se diseñan, desarrollan, despliegan y mantienen de forma consistente, cumpliendo con los objetivos estratégicos de la organización.
9.1. Objetivos del Gobierno SOA
- Alineación estratégica: Asegurar que los servicios apoyan los objetivos de negocio
- Estandarización: Definir y aplicar estándares técnicos y de diseño
- Calidad y consistencia: Garantizar que los servicios cumplen criterios de calidad
- Reutilización efectiva: Promover y facilitar la reutilización de servicios
- Gestión del ciclo de vida: Controlar todas las fases desde concepción hasta retirada
- Gestión de riesgos: Identificar y mitigar riesgos técnicos y de negocio
- Cumplimiento normativo: Asegurar adherencia a regulaciones (RGPD, LOPD, ENS)
9.2. Dimensiones del Gobierno SOA
Gobierno Organizativo
- Comité de Arquitectura: Aprueba diseños de servicios y cambios arquitectónicos
- Service Owner: Responsable del ciclo de vida de un servicio específico
- Arquitecto de Integración: Define patrones y estándares de integración
- Centro de Excelencia SOA: Proporciona formación, buenas prácticas y soporte
Gobierno Técnico
- Políticas de diseño: Naming conventions, patrones de error handling, versionado
- Políticas de seguridad: Autenticación, autorización, cifrado, auditoría
- Políticas de rendimiento: SLAs, timeouts, rate limiting
- Políticas de datos: Formatos, esquemas, transformaciones, calidad de datos
Gobierno de Procesos
- Proceso de solicitud: Cómo se propone un nuevo servicio
- Proceso de revisión: Evaluación técnica y de negocio antes de aprobación
- Proceso de publicación: Registro en catálogo y comunicación a consumidores
- Proceso de cambio: Gestión de versiones y cambios no retrocompatibles
- Proceso de retirada: Depreciación y descomisionado de servicios obsoletos
9.3. Métricas y KPIs de Gobierno SOA
| Categoría | Métrica/KPI | Objetivo Típico |
|---|---|---|
| Reutilización | Número promedio de consumidores por servicio | > 3 consumidores |
| Calidad | Tasa de defectos en servicios | < 1% de llamadas con error |
| Rendimiento | Tiempo de respuesta promedio | < 200ms para el 95% de llamadas |
| Disponibilidad | Uptime de servicios críticos | > 99.9% |
| Cumplimiento | % servicios que cumplen políticas | 100% para políticas críticas |
| Cobertura | % procesos de negocio soportados por servicios | > 80% |
| Eficiencia | Tiempo de desarrollo de nuevas integraciones | Reducción del 50% vs desarrollo sin SOA |
9.4. Herramientas para Gobierno SOA
- Registros de servicios: UDDI, Consul, Apache ZooKeeper
- Portales de API: API Management (Apigee, MuleSoft, Azure API Management, AWS API Gateway)
- Monitorización: Prometheus, Grafana, New Relic, Datadog
- Documentación: Swagger/OpenAPI, RAML, API Blueprint
- Testing: Postman, SoapUI, JMeter para pruebas de carga
- Gestión de configuración: Git, Ansible, Terraform
✅ Claves para un Gobierno SOA Exitoso
- Empezar con políticas simples y evolucionar gradualmente
- Automatizar todo lo posible (testing, despliegue, validación de políticas)
- Involucrar al negocio en la definición de servicios
- Medir y comunicar el valor generado por SOA
- Establecer canales de feedback con consumidores de servicios
- Invertir en formación continua de equipos
- Revisar y actualizar políticas periódicamente
10. Buses de Interoperabilidad (ESB – Enterprise Service Bus)
Un Bus de Servicios Empresarial (ESB) es una infraestructura de middleware que facilita la comunicación, transformación y orquestación entre servicios heterogéneos. Actúa como una columna vertebral de integración que conecta aplicaciones dispares, permitiendo que intercambien información de manera eficiente y fiable.
10.1. Funcionalidades del ESB
Enrutamiento de Mensajes (Message Routing)
Dirige mensajes desde el origen hasta el destino correcto basándose en:
- Enrutamiento basado en contenido (content-based routing)
- Enrutamiento basado en reglas de negocio
- Enrutamiento dinámico según condiciones en tiempo de ejecución
- Load balancing entre múltiples instancias de un servicio
Transformación de Datos
Convierte mensajes de un formato a otro:
- XML ↔ JSON ↔ CSV ↔ EDI
- Transformaciones XSLT para XML
- Mapeo de campos entre esquemas diferentes
- Enriquecimiento de mensajes con datos adicionales
Orquestación de Servicios
Coordina la invocación de múltiples servicios para implementar procesos complejos:
- Definición de flujos de trabajo (workflows)
- Manejo de transacciones distribuidas
- Compensación de transacciones en caso de error
- Paralelización de llamadas a servicios
Adaptadores y Conectores
Facilitan la integración con sistemas legacy y protocolos diversos:
- Conectores para SAP, Salesforce, sistemas mainframe
- Adaptadores para protocolos (FTP, SFTP, HTTP, JMS, AMQP)
- Conectores para bases de datos (JDBC, ODBC)
- Integración con sistemas de archivos
Gestión de Seguridad
- Autenticación de consumidores de servicios
- Autorización y control de acceso
- Cifrado de mensajes (WS-Security, SSL/TLS)
- Firma digital y no repudio
- Auditoría de todas las transacciones
Monitorización y Logging
- Registro de todas las transacciones que pasan por el bus
- Métricas de rendimiento en tiempo real
- Alertas configurables ante anomalías
- Dashboards para visualización del tráfico
10.2. Principales Productos ESB del Mercado
| Producto ESB | Proveedor | Características Destacadas | Uso Típico |
|---|---|---|---|
| MuleSoft Anypoint Platform | Salesforce | Amplio catálogo de conectores, diseño visual, API management integrado | Integraciones enterprise, ecosistema Salesforce |
| IBM App Connect | IBM | Integración con ecosistema IBM, IA para mapeo, robustez enterprise | Grandes empresas con stack IBM |
| Oracle SOA Suite | Oracle | Integración nativa con productos Oracle, BPEL, gestión de procesos | Entornos Oracle, sectores regulados |
| Apache Camel | Apache Software Foundation | Open source, más de 300 conectores, integración con Spring Boot | Empresas que buscan flexibilidad y bajo coste |
| WSO2 Enterprise Integrator | WSO2 | Open source, cloud-native, microservicios, streaming integration | Organizaciones que buscan alternativa open source |
| Red Hat Fuse | Red Hat | Basado en Apache Camel, soporte enterprise, contenedorización | Ambientes Red Hat/OpenShift, microservicios |
| Azure Service Bus | Microsoft | Cloud-native, integración Azure, escalado automático, serverless | Aplicaciones en Azure, arquitecturas híbridas |
10.3. Patrones de Integración en ESB
Los ESB implementan patrones de integración empresarial (Enterprise Integration Patterns – EIP) documentados por Gregor Hohpe y Bobby Woolf:
- Message Channel: Canal de comunicación entre emisor y receptor
- Message Router: Determina el destinatario basándose en el contenido del mensaje
- Message Translator: Transforma el mensaje de un formato a otro
- Message Splitter: Divide un mensaje compuesto en mensajes individuales
- Message Aggregator: Combina múltiples mensajes relacionados en uno solo
- Content Enricher: Añade información al mensaje consultando fuentes externas
- Dead Letter Channel: Maneja mensajes que no pueden ser procesados
- Guaranteed Delivery: Asegura que el mensaje llegue a su destino
10.4. ESB vs Arquitecturas sin Bus
ℹ️ Debate: ESB vs Microservicios sin ESB
Existe un debate en la industria sobre la necesidad de ESB en arquitecturas modernas. Los críticos argumentan que introduce un punto único de fallo y cuellos de botella. Los defensores sostienen que proporciona gestión centralizada, estandarización y visibilidad. La tendencia actual favorece arquitecturas híbridas: ESB para integraciones empresariales complejas y comunicación directa para microservicios.
Ventajas del ESB:
- Gestión centralizada de integraciones
- Reutilización de adaptadores y transformaciones
- Visibilidad completa del tráfico de mensajes
- Aplicación consistente de políticas de seguridad
- Simplificación de la complejidad de integraciones punto a punto
Alternativas modernas al ESB:
- API Gateway: Para gestión de APIs externas (Kong, Apigee, AWS API Gateway)
- Message Brokers: Para mensajería asíncrona (RabbitMQ, Apache Kafka)
- Service Mesh: Para comunicación entre microservicios (Istio, Linkerd)
- Event Streaming Platforms: Para arquitecturas event-driven (Apache Kafka, Apache Pulsar)
11. Aplicación de estas Tecnologías en el Servicio Andaluz de Salud
El Servicio Andaluz de Salud (SAS) gestiona uno de los sistemas sanitarios más grandes de Europa, atendiendo a más de 8.5 millones de usuarios en Andalucía. La aplicación de arquitecturas cliente-servidor, SOA y buses de interoperabilidad es fundamental para garantizar la eficiencia, seguridad y calidad de la atención sanitaria.
11.1. Contexto del Ecosistema Digital del SAS
El SAS opera un complejo ecosistema de sistemas de información sanitaria:
- Diraya: Historia de Salud Electrónica (HSE) unificada de Andalucía
- Receta XXI: Sistema de prescripción electrónica
- InterSAS: Plataforma de interoperabilidad entre sistemas sanitarios
- CIMA: Centro de Información Médico-Asistencial
- Sistemas RIS/PACS: Gestión de imágenes médicas
- Sistemas LIS: Gestión de laboratorios
- Aplicaciones móviles: Salud Responde, ClicSalud+
- Portales de pacientes: Acceso a informes, citas, vacunaciones
11.2. Arquitectura Multinivel en Aplicaciones del SAS
✅ Caso de Estudio: Diraya HSE
La Historia de Salud Electrónica Diraya implementa una arquitectura 3-tier que permite a profesionales sanitarios de toda Andalucía acceder de forma segura y eficiente a la información clínica de los pacientes:
- Capa de Presentación: Aplicaciones web responsive y aplicaciones móviles para profesionales
- Capa de Negocio: Servidores de aplicación con lógica de historias clínicas, validaciones y reglas de acceso
- Capa de Datos: Bases de datos Oracle con alta disponibilidad, respaldos continuos y cifrado
Beneficios de la Arquitectura Multinivel en el SAS:
- Acceso ubicuo: Profesionales pueden acceder desde cualquier centro sanitario andaluz
- Escalabilidad: Soporta picos de demanda (campañas de vacunación, epidemias)
- Seguridad: Control granular de acceso según perfil profesional y necesidad asistencial
- Continuidad asistencial: Información completa disponible en cualquier punto de atención
- Mantenimiento simplificado: Actualizaciones centralizadas sin afectar a centros sanitarios
11.3. SOA y Servicios de Interoperabilidad en el SAS
El SAS ha adoptado SOA como estrategia para integrar sus múltiples sistemas y facilitar la interoperabilidad tanto interna como con otras comunidades autónomas y el Sistema Nacional de Salud.
Plataforma InterSAS
InterSAS es el bus de interoperabilidad del SAS, basado en estándares HL7 y servicios web:
- Estándar HL7 FHIR: Fast Healthcare Interoperability Resources para intercambio de información clínica estructurada
- HL7 v2.x y v3: Para integración con sistemas legacy
- DICOM: Para imágenes médicas
- CDA (Clinical Document Architecture): Para documentos clínicos estructurados
- IHE (Integrating the Healthcare Enterprise): Perfiles de integración específicos de salud
Servicios Clave Expuestos por InterSAS:
- Servicio de Identificación de Pacientes: Búsqueda y validación de pacientes en el sistema
- Servicio de Historia Clínica: Acceso a episodios, diagnósticos, tratamientos
- Servicio de Prescripción: Consulta y gestión de recetas electrónicas
- Servicio de Agenda: Gestión de citas médicas
- Servicio de Documentos Clínicos: Almacenamiento y recuperación de informes
- Servicio de Vacunación: Registro y consulta del calendario vacunal
- Servicio de Resultados de Pruebas: Laboratorio, radiología, anatomía patológica
11.4. Integración con el Sistema Nacional de Salud
El SAS participa activamente en la interoperabilidad a nivel nacional:
- Tarjeta Sanitaria Individual (TSI): Identificación única de pacientes en toda España
- Historia Clínica Digital del SNS: Intercambio de información clínica entre comunidades autónomas
- Receta electrónica interoperable: Dispensación de medicamentos en cualquier comunidad
- Registro de Atención de Urgencias: Información sobre atenciones urgentes
- Registro de Vacunación: Calendario vacunal nacional
⚠️ Desafío: Heterogeneidad de Sistemas
Uno de los principales desafíos del SAS es integrar sistemas desarrollados en diferentes épocas y con tecnologías diversas (mainframes, sistemas propietarios, aplicaciones web modernas). La adopción de SOA y ESB permite abstraer estas diferencias tecnológicas y presentar interfaces unificadas.
11.5. Gobierno SOA en el SAS
El SAS ha establecido un marco de gobierno para sus servicios de interoperabilidad:
Comité de Arquitectura Tecnológica
- Define estándares tecnológicos para servicios
- Aprueba nuevos servicios antes de su publicación
- Revisa periódicamente los servicios existentes
Políticas de Seguridad y Privacidad
- Autenticación fuerte: Certificados digitales profesionales, tarjetas criptográficas
- Autorización basada en roles: Perfiles profesionales con accesos diferenciados
- Auditoría exhaustiva: Registro de todos los accesos a datos clínicos (RGPD, LOPD)
- Cifrado end-to-end: Protección de datos sensibles en tránsito y reposo
- Consentimiento informado: Gestión de permisos del paciente sobre sus datos
Catálogo de Servicios
El SAS mantiene un catálogo actualizado de todos los servicios disponibles:
- Descripción funcional del servicio
- Contratos técnicos (WSDL, OpenAPI)
- SLAs definidos (disponibilidad, tiempo de respuesta)
- Procedimiento de solicitud de acceso
- Documentación de uso y casos de ejemplo
11.6. Tecnologías Específicas Utilizadas en el SAS
| Componente | Tecnología/Producto | Función en el SAS |
|---|---|---|
| ESB | Oracle SOA Suite, WSO2 | Bus de interoperabilidad para integración de sistemas |
| Base de Datos | Oracle Database, PostgreSQL | Almacenamiento de historias clínicas y datos administrativos |
| Servidores de Aplicación | WebLogic, JBoss/WildFly, Apache Tomcat | Hosting de aplicaciones Java empresariales |
| Portales Web | Liferay, tecnologías web modernas (React, Angular) | Portales de pacientes y profesionales |
| Estándares de Interoperabilidad | HL7 FHIR, HL7 v2/v3, DICOM, CDA | Intercambio de información clínica estructurada |
| Seguridad | PKI corporativa, Active Directory, SAML, OAuth | Autenticación, autorización y auditoría |
| Monitorización | Nagios, Zabbix, ELK Stack | Supervisión de infraestructura y aplicaciones |
11.7. Beneficios Alcanzados con Estas Arquitecturas
📊 Resultados Cuantificables
- Cobertura universal: 8.5 millones de historias clínicas electrónicas activas
- Disponibilidad: >99.9% en sistemas críticos como Diraya y Receta XXI
- Eficiencia: Reducción del 30% en pruebas duplicadas gracias a acceso unificado a resultados
- Satisfacción: >85% de profesionales valoran positivamente el acceso unificado a información
- Sostenibilidad: Ahorro estimado de 100 millones de € anuales por eficiencia en gestión
- Continuidad asistencial: 100% de los centros sanitarios públicos integrados
11.8. Retos Futuros
El SAS enfrenta varios desafíos en la evolución de sus arquitecturas tecnológicas:
- Migración a Cloud: Transición progresiva a cloud híbrido manteniendo seguridad y cumplimiento normativo
- Adopción de IA: Integración de algoritmos de machine learning para diagnóstico asistido y medicina personalizada
- Telemedicina: Escalado de capacidades de atención virtual acelerado por la pandemia COVID-19
- Internet de las Cosas Médicas (IoMT): Integración de dispositivos wearables y sensores biomédicos
- Blockchain: Exploración para gestión de consentimientos y trazabilidad de medicamentos
- 5G: Aprovechamiento de baja latencia para cirugía remota y diagnóstico en tiempo real
- Ciberseguridad: Refuerzo continuo ante amenazas crecientes al sector sanitario
⛔ Consideraciones de Cumplimiento Normativo
El SAS debe garantizar el cumplimiento de múltiples marcos normativos:
- RGPD: Reglamento General de Protección de Datos de la UE
- LOPD-GDD: Ley Orgánica de Protección de Datos española
- ENS: Esquema Nacional de Seguridad (categoría ALTA para sistemas sanitarios)
- Ley 41/2002: Autonomía del paciente y derechos sobre información clínica
- Directiva NIS2: Seguridad de redes y sistemas de información
12. Preguntas de Test
Pregunta 1: ¿Cuál de las siguientes NO es una característica distintiva de la arquitectura cliente-servidor?
Respuesta correcta: C
Explicación: En cliente-servidor siempre hay alguna lógica en el cliente, al menos la de presentación. La arquitectura se basa en la separación de responsabilidades, pero no elimina completamente el procesamiento en el cliente.
Pregunta 2: En una arquitectura de tres niveles (3-tier), ¿qué capa es responsable de implementar las reglas de negocio?
Respuesta correcta: B
Explicación: La capa de lógica de negocio o middleware es responsable de implementar las reglas de negocio, actuando como intermediario entre la capa de presentación y la capa de datos.
Pregunta 3: ¿Cuál es la principal ventaja de la arquitectura 2-tier sobre la 3-tier?
Respuesta correcta: C
Explicación: La principal ventaja de 2-tier es su simplicidad en el diseño y desarrollo, aunque carece de la escalabilidad y flexibilidad de arquitecturas multinivel más complejas.
Pregunta 4: ¿Cuál de los siguientes NO es uno de los principios fundamentales de SOA?
Respuesta correcta: C
Explicación: SOA no requiere centralización de datos; cada servicio puede tener su propia base de datos. SOA promueve el bajo acoplamiento, no la centralización forzosa de datos.
Pregunta 5: En el contexto de SOA, ¿qué función principal cumple un ESB (Enterprise Service Bus)?
Respuesta correcta: B
Explicación: El ESB facilita la comunicación, transformación y orquestación entre servicios heterogéneos, actuando como infraestructura central de comunicación en arquitecturas SOA.
Pregunta 6: ¿Qué estándar de interoperabilidad sanitaria utiliza principalmente el SAS para el intercambio de información clínica estructurada en sus sistemas modernos?
Respuesta correcta: B
Explicación: HL7 FHIR es el estándar moderno para interoperabilidad sanitaria, facilitando el intercambio de información entre sistemas de salud mediante recursos estructurados y APIs RESTful.
Pregunta 7: En arquitecturas multinivel (N-tier), ¿cuál es una función típica de la capa de caché?
Respuesta correcta: B
Explicación: La capa de caché almacena datos frecuentemente accedidos para mejorar el rendimiento del sistema, reduciendo la carga en la base de datos y mejorando los tiempos de respuesta.
Pregunta 8: ¿Cuál de las siguientes afirmaciones sobre el Gobierno SOA es correcta?
Respuesta correcta: B
Explicación: El gobierno SOA incluye políticas, procesos, roles y responsabilidades para gestionar el ciclo de vida completo de los servicios, siendo tanto una cuestión técnica como organizativa.
Pregunta 9: ¿Cuál es la principal diferencia entre SOAP y REST como tecnologías de API?
Respuesta correcta: A
Explicación: SOAP es un protocolo formal con reglas estrictas mantenido por W3C, mientras que REST es un conjunto de principios arquitectónicos más flexible. REST normalmente usa JSON, mientras que SOAP usa XML.
Pregunta 10: ¿Cuál de los siguientes NO es un componente típico de un ESB?
Respuesta correcta: C
Explicación: Un ESB no incluye un sistema operativo dedicado. Sus componentes principales son el bus de comunicación, motores de transformación y orquestación, registro de servicios, adaptadores y colas de mensajes.
Pregunta 11: En el contexto de HL7 FHIR, ¿qué formato de datos es preferido por su ligereza y facilidad de uso?
Respuesta correcta: C
Explicación: JSON es el formato preferido en FHIR por ser ligero, comprensible tanto por humanos como por máquinas, y compatible con prácticamente cualquier lenguaje de programación.
Pregunta 12: ¿Cuál es la diferencia principal entre Apache Tomcat y JBoss/WildFly?
Respuesta correcta: A
Explicación: Tomcat es un contenedor de servlets y JSPs (servidor web), mientras que JBoss/WildFly es un servidor de aplicaciones completo que implementa todas las especificaciones Java EE.
Pregunta 13: En arquitecturas multinivel, ¿cuál es una ventaja principal de la separación en capas?
Respuesta correcta: B
Explicación: La modularidad estanca permite modificar cualquier capa sin tener incidencia en el resto, aportando versatilidad y adaptabilidad al sistema.
Pregunta 14: ¿Qué significa que un servicio sea «stateless» (sin estado) en SOA?
Respuesta correcta: B
Explicación: Un servicio stateless no mantiene información de sesión entre llamadas consecutivas, lo que mejora la escalabilidad y facilita el balanceo de carga.
Pregunta 15: ¿Cuál es una diferencia clave entre microservicios y SOA?
Respuesta correcta: A
Explicación: Los microservicios son pequeños, autónomos y especializados en una funcionalidad específica, mientras que SOA trabaja con servicios más grandes que representan funcionalidades empresariales completas.
Pregunta 16: En el contexto sanitario, ¿cuál es un recurso típico de HL7 FHIR?
Respuesta correcta: B
Explicación: Patient es uno de los recursos fundamentales de FHIR, junto con Encounter (Encuentro) y Observation (Observación), diseñados específicamente para el intercambio de información sanitaria.
Pregunta 17: ¿Qué protocolo utiliza típicamente REST para la transmisión de datos?
Respuesta correcta: C
Explicación: REST utiliza típicamente HTTP/HTTPS para la transmisión de datos, aprovechando sus métodos estándar (GET, POST, PUT, DELETE) para operaciones CRUD.
Pregunta 18: ¿Cuál es una desventaja típica de las arquitecturas multinivel (N-tier)?
Respuesta correcta: B
Explicación: Las arquitecturas multinivel presentan mayor complejidad en diseño e implementación, requieren más esfuerzo inicial y tienen una curva de aprendizaje pronunciada, aunque ofrecen ventajas a largo plazo.
Pregunta 19: En un ESB, ¿qué función cumple el «Motor de Enrutamiento»?
Respuesta correcta: B
Explicación: El motor de enrutamiento determina las rutas que toman los mensajes dentro del ESB basándose en el contenido de los mensajes o en políticas predefinidas.
Pregunta 20: ¿Qué estándar describe el alcance y la función de los servicios web SOAP?
Respuesta correcta: B
Explicación: WSDL (Web Services Description Language) describe el alcance y la función de los servicios web SOAP, especificando las operaciones disponibles y los formatos de mensajes.
Pregunta 21: ¿Cuál de las siguientes es una característica de Oracle WebLogic como servidor de aplicaciones?
Respuesta correcta: B
Explicación: WebLogic es un servidor de aplicaciones Java EE completo que puede gestionar pools de conexiones a BD, crear clusters virtuales, y funciona en múltiples plataformas (Unix, Linux, Windows).
Pregunta 22: En arquitecturas SOA, ¿qué ventaja proporciona el bajo acoplamiento entre servicios?
Respuesta correcta: B
Explicación: El bajo acoplamiento facilita la modificación y evolución independiente de cada servicio, permitiendo cambios sin afectar a otros servicios del ecosistema.
Pregunta 23: ¿Qué protocolo de seguridad es específico para servicios web SOAP?
Respuesta correcta: B
Explicación: WS-Security (Web Services Security) es un estándar específico para SOAP que especifica medidas de seguridad como el uso de tokens únicos, firmas digitales y cifrado de mensajes.
Pregunta 24: En una arquitectura cliente-servidor, ¿qué ventaja principal ofrece la heterogeneidad tecnológica?
Respuesta correcta: B
Explicación: La heterogeneidad tecnológica permite que clientes y servidores utilicen diferentes tecnologías, lenguajes de programación y plataformas, siempre que cumplan con protocolos de comunicación comunes.
Pregunta 25: ¿Cuál es la versión más reciente del estándar HL7 FHIR mencionada en documentación actual?
Respuesta correcta: C
Explicación: La versión R5 (Release 5) de HL7 FHIR fue publicada en 2023 como la última generación del estándar, mejorando la interoperabilidad sanitaria con recursos más completos y APIs más robustas.
13. Referencias Bibliográficas
Libros y Documentación Técnica
- Erl, T. (2016). SOA: Principles of Service Design. Prentice Hall. ISBN: 978-0134759937
- Hohpe, G., & Woolf, B. (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. ISBN: 978-0321200686
- Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems (2nd Edition). O’Reilly Media. ISBN: 978-1492034025
- Fowler, M., & Lewis, J. (2014). Microservices: a definition of this new architectural term. martinfowler.com
- Richardson, C. (2018). Microservices Patterns. Manning Publications. ISBN: 978-1617294549
Estándares y Especificaciones
- HL7 International (2024). HL7 FHIR Release 5.0.0. https://hl7.org/fhir/
- OpenAPI Initiative (2024). OpenAPI Specification v3.1.0. https://www.openapis.org/
- W3C (2007). SOAP Version 1.2 Specification. https://www.w3.org/TR/soap12/
- OASIS (2007). Web Services Business Process Execution Language (WS-BPEL) 2.0
Documentación Institucional del SAS
- Servicio Andaluz de Salud (2024). Plan Estratégico de Sistemas de Información del SAS 2024-2027
- Junta de Andalucía (2023). Esquema Nacional de Interoperabilidad en el SAS
- Consejería de Salud de Andalucía (2024). Directrices de Seguridad y Privacidad en Sistemas de Información Sanitaria
Recursos Web y Comunidades
- Apache Software Foundation – Apache Camel: https://camel.apache.org/
- WSO2 Documentation: https://wso2.com/integration/
- MuleSoft Documentation: https://docs.mulesoft.com/
- Cloud Native Computing Foundation (CNCF): https://www.cncf.io/
- Martin Fowler’s Blog on Architecture: https://martinfowler.com/architecture/
Normativa y Regulación
- Reglamento (UE) 2016/679 – RGPD (Reglamento General de Protección de Datos)
- Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales (LOPD-GDD)
- Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad (ENS)
- Ley 41/2002, de 14 de noviembre, básica reguladora de la autonomía del paciente y de derechos y obligaciones en materia de información y documentación clínica