Qué es un servicio web

Un servicio web es una funcionalidad que un sistema publica en la red para que otros programas la usen, con un interfaz definido y sobre protocolos estándar de Internet. La clave está en «otros programas»: al otro lado no hay una persona mirando una pantalla, hay software. Por eso la respuesta no es una página bonita, sino datos estructurados que la máquina que llama pueda interpretar.

Eso convierte a los servicios web en el pegamento de la arquitectura multicapa cuando las piezas ya no están en la misma máquina ni escritas en el mismo lenguaje. Un servidor de aplicaciones en Java puede consumir un servicio publicado en .NET sin saber nada del otro, porque los dos hablan el mismo protocolo y el mismo formato de mensaje.

• Interoperable: cliente y servidor pueden estar escritos en lenguajes y plataformas distintos.
• Con interfaz publicado: quien llama sabe qué operaciones existen y qué datos hay que enviar.
• Sobre protocolos abiertos, típicamente HTTP, lo que le permite atravesar cortafuegos que ya están abiertos.
• Débilmente acoplado: quien llama no depende del código interno de quien responde, solo del contrato.

Un servicio web no es una web: es una puerta de entrada para programas. El interfaz está pensado para ser consumido por código, no leído por una persona.

Antes de los servicios web ya se intentaba lo mismo: repartir las funcionalidades de una aplicación entre máquinas distintas en vez de tenerlo todo en una sola. La idea común de toda esa generación es hacer que llamar a algo que está en otra máquina se parezca lo más posible a llamar a una función local, escondiendo la red por debajo.

Ninguna llegó a imponerse como lengua franca de Internet. CORBA era potente pero pesado de implementar; RMI solo servía si las dos partes eran Java; DCOM, si las dos eran Windows. Además, todas usaban protocolos y puertos propios que los cortafuegos bloqueaban. Los servicios web resolvieron ese punto exacto: mensajes de texto sobre HTTP, que pasa por todas partes.

Lo que hundió a la generación anterior no fue la técnica, fue la interoperabilidad: cada una obligaba a que los dos extremos compartieran lenguaje, plataforma o protocolo propietario.

No hay una sola forma de publicar un servicio. Conviven cuatro enfoques, y el examen suele preguntar por el rasgo que distingue a cada uno, sobre todo por cuántos puntos de acceso (endpoints) expone y quién decide la forma de los datos.

Las dos primeras son las que dominan el temario y las que se comparan siempre entre sí. Las dos últimas son la respuesta a dos problemas concretos de REST: que a veces devuelve más datos de los que el cliente necesita, y que el texto plano cuesta caro cuando hay que hacer millones de llamadas internas.

Regla rápida para el examen: SOAP y GraphQL tienen un único punto de acceso; REST expone uno por recurso. Es la diferencia que más se pregunta de esta lista.

Los servicios web tradicionales se apoyan en tres piezas, cada una con su papel: SOAP dice cómo viaja el mensaje, WSDL dice qué operaciones ofrece el servicio y qué datos espera, y UDDI es el registro donde publicar y buscar servicios. Las dos primeras son especificaciones de la W3C; UDDI es de OASIS.

Sobre esas tres piezas se levantó después una familia de especificaciones adicionales, las llamadas WS-*, para cubrir lo que el núcleo dejaba fuera: seguridad, transacciones, mensajería fiable, direccionamiento. La contrapartida es que cada implementación interpretaba los estándares a su manera y dos servicios «conformes» podían no entenderse.

Ese es el problema que ataca el WS-I Basic Profile, publicado por la Web Services Interoperability Organization. No inventa lenguajes nuevos: coge SOAP, WSDL y UDDI y restringe cómo se pueden usar, cerrando las ambigüedades para que dos implementaciones independientes se entiendan de verdad. Es un perfil de interoperabilidad, no una especificación más.

El WS-I Basic Profile no define SOAP, WSDL ni UDDI: los perfila. Dice qué parte de cada uno se puede usar y cómo, para que la interoperabilidad deje de ser una promesa.

UDDI (Universal Description, Discovery and Integration) es un registro donde las organizaciones publican los servicios que ofrecen para que otras los localicen. La idea original era ambiciosa: una especie de listín telefónico universal de servicios web, en el que una aplicación pudiera buscar por sí sola un proveedor y engancharse a él. Lo publica OASIS, a diferencia de SOAP y WSDL, que salen de la W3C.

Su información se organiza precisamente con la metáfora del listín, y esa clasificación en tres tipos de páginas es lo que se pregunta.

En la práctica UDDI no cuajó: los grandes registros públicos se cerraron y hoy los servicios se localizan por otras vías, desde un simple documento de integración hasta los registros internos de una arquitectura de microservicios. Sigue apareciendo en los exámenes como la tercera pata de la pila clásica. En el mundo Java, la API para hablar con un registro de este tipo es JAXR.

De UDDI hay que retener tres cosas: que es de OASIS, que sus páginas son blancas (quién), amarillas (de qué tipo) y verdes (cómo se llama), y que hoy prácticamente no se usa.

WSDL es un documento XML que describe un servicio: qué operaciones tiene, qué datos entran y salen en cada una, con qué protocolo se le habla y en qué dirección está escuchando. Es el contrato, y es legible tanto por una persona como por una herramienta, que puede generar a partir de él el código del cliente. Normalmente no se escribe a mano: el motor del servicio lo genera a partir del código publicado.

Las tres primeras secciones son abstractas: dicen qué hace el servicio sin comprometerse con ninguna tecnología. Las dos últimas son concretas: dicen cómo y dónde se le llama. Esa separación permite publicar el mismo portType con varias vinculaciones distintas.

<definitions name="TemarioService"
             targetNamespace="https://llegandoalcorte.com/temario">

  <types>
    <!-- esquema XSD con los tipos Alumno, Tema e Intento -->
  </types>

  <message name="notaMediaPeticion">
    <part name="alumno" type="xsd:long"/>
    <part name="tema" type="xsd:string"/>
  </message>

  <portType name="Temario">
    <operation name="notaMediaDelTema">
      <input message="tns:notaMediaPeticion"/>
      <output message="tns:notaMediaRespuesta"/>
    </operation>
  </portType>

  <binding name="TemarioSoapHttp" type="tns:Temario">
    <!-- transporte HTTP y estilo del mensaje SOAP -->
  </binding>

  <service name="TemarioService">
    <port name="TemarioPort" binding="tns:TemarioSoapHttp">
      <address location="https://api.llegandoalcorte.com/servicios/temario"/>
    </port>
  </service>

</definitions>

Un truco para no perderse: se lee de dentro afuera. types construye los datos, message los agrupa, portType declara las operaciones, binding elige el protocolo y service da la dirección.

La versión 2.0 de WSDL, recomendación de la W3C, simplifica el lenguaje y cambia algunos nombres que se preguntan con frecuencia porque son fáciles de confundir con los de la 1.1.

El otro cambio relevante es que la 2.0 añade soporte para describir servicios que no son SOAP: incorpora una vinculación HTTP que permite documentar y definir también un servicio REST. En la práctica esa posibilidad se usó poco, porque para entonces el mundo REST ya tiraba por otros formatos de documentación.