Este temario no se imprime
El temario de LaPlazaFija se estudia en la web, sección a sección, con tu progreso al lado. Si quieres practicar en papel, usa el cuadernillo de Simulacros oficiales: está hecho para imprimirse, con el formato del examen real.
E13
SOA y Web Services
DES
Arquitectura orientada a servicios: qué es un servicio web, la pila SOAP con WSDL y UDDI, el estilo REST y el salto de SOA a los microservicios.
En este tema · 10 secciones
- Objetivos
- Sección 1 · Arquitectura orientada a servicios (SOA)
- Sección 2 · Servicios web: concepto
- Sección 3 · La pila SOAP
- Sección 4 · El estilo REST
- Sección 5 · De SOA a microservicios
- Errores frecuentes
- Resumen exprés
- Esquema de repaso
- Mapa mental del tema
Objetivos
Al terminar este tema sabrás: (1) explicar la arquitectura orientada a servicios (SOA) y sus principios; (2) los fundamentos de los servicios web; (3) la pila SOAP (WSDL, UDDI); (4) el estilo REST y su comparación con SOAP; y (5) su evolución hacia microservicios y API gateways. Se apoya en el tema 5 (HTTP y REST) y en el tema 12 (XML y JSON).
⚠ Cae en examen. E13 es de bajo peso y muy conceptual: qué es SOA, SOAP vs REST, qué es WSDL/UDDI, verbos REST, microservicios vs monolito. Distinguir SOAP de REST es la pregunta estrella.
Sección 1 · Arquitectura orientada a servicios (SOA)
SOA (Service-Oriented Architecture) es un estilo de arquitectura que estructura las aplicaciones como un conjunto de servicios débilmente acoplados, reutilizables e interoperables, que se comunican mediante estándares.
Principios de un buen servicio SOA:
-
Bajo acoplamiento (loose coupling): los servicios son independientes entre sí.
-
Contrato estándar: interfaz bien definida e independiente de la implementación.
-
Reutilización y composición: un servicio se usa desde varias aplicaciones y se combinan para procesos mayores (orquestación).
-
Abstracción / encapsulación: oculta la lógica interna.
-
Sin estado (deseable) y descubribles.
-
ESB (Enterprise Service Bus): bus de integración que conecta y orquesta los servicios (enrutamiento, transformación, mensajería) en SOA clásico. SOA no exige un ESB (puede haber SOA sin él), y el bajo acoplamiento no significa independencia total: los servicios siguen dependiendo de contratos y de otros servicios. El ESB es un ejemplo de middleware (software que conecta dos aplicaciones para que compartan recursos de proceso de datos).
En la siguiente figura se ilustra esta arquitectura de integración centralizada a través de un ESB:
⚠ Cae en examen. SOA = aplicaciones como servicios débilmente acoplados, reutilizables e interoperables por estándares. Bajo acoplamiento + contrato. El ESB integra los servicios.
Sigue leyendo cuando abramos
Apúntate a la lista de espera y te avisamos en cuanto abramos: podrás leer los temas de muestra completos, guardar tu progreso y entrenar con tests del formato real. Te quedan 8 secciones de este tema por delante.