In­ter­ac­tuar en redes como Internet solo es posible si se siguen unas reglas es­ta­ble­ci­das. Para que los di­fe­re­n­tes or­de­na­do­res y otros di­s­po­si­ti­vos con co­ne­c­ti­vi­dad no caigan en el caos, se atienen a un protocolo de red. SOAP es, junto con REST, uno de los pro­to­co­los más im­po­r­ta­n­tes de Internet.

¿Qué es SOAP?

La co­mu­ni­ca­ción en Internet se basa pri­n­ci­pa­l­me­n­te en pro­to­co­los como HTTP, HTTPS, FTP o, a otro nivel, TCP. Pero SOAP es esencial para los servicios web, in­te­r­fa­ces a través de las cuales un di­s­po­si­ti­vo puede hacer uso del servicio de un servidor. Los bu­s­ca­do­res, las tiendas en línea y otros muchos servicios en Internet funcionan a través de dichos servicios web, y SOAP es uno de los pro­to­co­los que lo hacen posible.

Hecho

Ini­cia­l­me­n­te, la de­no­mi­na­ción SOAP se utilizó como acrónimo de “Simple Object Access Protocol”. Ya que dicha de­no­mi­na­ción no encaja realmente con el protocolo (no es ni simple ni accede a ningún objeto), en la ac­tua­li­dad se utiliza SOAP como nombre propio.

SOAP se viene uti­li­za­n­do desde los años noventa para po­si­bi­li­tar la co­mu­ni­ca­ción entre un cliente, como el navegador de Internet, y los servicios de un servidor. Para que esto sea posible, el cliente debe enviar una solicitud a la API. El framework de SOAP determina la forma que debe adoptar dicha solicitud. Dentro de esta de­fi­ni­ción de la solicitud también pueden incluirse datos es­pe­cí­fi­cos de la apli­ca­ción, lo que es un punto fuerte de SOAP. De esta forma, los servicios web pueden desplegar apli­ca­cio­nes di­fe­re­n­tes. Para que puedan uti­li­zar­se como servicios web sin necesidad de tener la misma sintaxis, SOAP establece unas reglas básicas.

Nota

El de­sa­rro­lla­dor de software Dave Wiener creó SOAP en co­la­bo­ra­ción con un equipo de Microsoft para conseguir un protocolo que fu­n­cio­na­ra bien para Internet. Para ello se le dio mucha im­po­r­ta­n­cia a que SOAP fuera co­m­pa­ti­ble con los es­tá­n­da­res W3C, co­n­vi­r­tié­n­do­se así en una re­co­me­n­da­ción de W3C.

SOAP web services: campos de apli­ca­ción del protocolo

SOAP juega un papel im­po­r­ta­n­te cuando un sistema quiere acceder a otro de manera ordenada y limitada. En lugar de darle al cliente so­li­ci­ta­n­te acceso total al servidor, con un protocolo como SOAP puede limitarse el acceso a las funciones que necesita. La ar­qui­te­c­tu­ra del protocolo, al facilitar un marco al que la apli­ca­ción puede in­co­r­po­rar­se, ofrece así la ventaja de que sistemas muy di­fe­re­n­tes pueden cooperar entre sí.

Una gran di­ve­r­si­dad de servicios web se basa en SOAP. Por ejemplo, Amazon e eBay trabajan (pa­r­cia­l­me­n­te) con el protocolo de red.

La es­tru­c­tu­ra de SOAP: fu­n­cio­na­mie­n­to del protocolo

SOAP se basa en el me­ta­le­n­gua­je XML. Este, que también es una re­co­me­n­da­ción de W3C, es un conjunto de unidades de in­fo­r­ma­ción que son ne­ce­sa­rias para dar como resultado un documento XML bien formado (es decir, de acuerdo con una es­tru­c­tu­ra re­co­me­n­da­da). SOAP asimila su es­tru­c­tu­ra de mensajes y por co­n­si­guie­n­te se co­rre­s­po­n­de pri­n­ci­pa­l­me­n­te con un documento XML.

En la mayoría de los casos, SOAP se integra también en HTTP. El tra­n­s­po­r­te se realiza a través del protocolo y se integra en su es­tru­c­tu­ra. Un mensaje HTTP con una solicitud SOAP tiene la siguiente forma:

POST /example HTTP/1.1
Host: example.org
Content-Type: text/xml; charset=utf-8
…
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
...
    <SOAP-ENV:Header>
        ...
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        ...
    </SOAP-ENV:Body>
</SOAP_ENV:Envelope>

En este ejemplo, la solicitud comienza con un en­ca­be­za­do HTTP. A co­n­ti­nua­ción, sigue el llamado Envelope (sobre) de SOAP, que envuelve el contenido real del mensaje como un sobre. Los elementos pri­n­ci­pa­les de SOAP son el Header (en­ca­be­za­do) y el Body (cuerpo).

  • Header: el en­ca­be­za­do de la solicitud SOAP contiene metadatos como la en­cri­p­ta­ción que se ha utilizado. Su uso es opcional.
  • Body: en el cuerpo del mensaje se en­cue­n­tran los datos en sí.

Los conceptos uti­li­za­dos en el Body no tienen nada que ver con SOAP, sino que dependen co­m­ple­ta­me­n­te de la apli­ca­ción.

El protocolo aparece a menudo en co­m­bi­na­ción con el lenguaje WSDL (Web Services De­s­cri­p­tion Language). Se trata de un lenguaje de de­s­cri­p­ción especial para servicios web que, por otra parte, no depende de pla­ta­fo­r­ma. Con su ayuda, un cliente puede reconocer qué servicios ofrece un servicio web. A partir del archivo WSDL, el cliente deduce qué po­si­bi­li­da­des tiene para realizar una solicitud SOAP. El dúo WSDL y SOAP permite que dos sistemas di­fe­re­n­tes se co­mu­ni­quen sin tener que adaptarse pre­via­me­n­te.

SOAP vs. REST

Tanto SOAP como REST (que, al fin y al cabo, es una ar­qui­te­c­tu­ra y no un protocolo) se utilizan para servicios web, aunque procesan las tareas de manera distinta. Mientras que SOAP es algo más antiguo, REST (también conocido como RESTful Web Services) ha ido ganando terreno y en la ac­tua­li­dad di­s­tri­bu­ye apro­xi­ma­da­me­n­te el 70 por ciento de los servicios web.

No obstante, cada uno ofrece ventajas di­fe­re­n­tes: REST está co­n­si­de­ra­do re­la­ti­va­me­n­te sencillo, no trabaja solo con XML, es más rápido y, en co­m­pa­ra­ción con SOAP, más ligero. La libertad que ca­ra­c­te­ri­za a REST a la hora de elegir si trabajar con XML (a menudo recurre a JSON) ca­ra­c­te­ri­za a SOAP a la hora de elegir el protocolo. Aunque HTTP es a menudo la opción elegida, teó­ri­ca­me­n­te SOAP funciona también en co­m­bi­na­ción con FTP, SMTP u otros pro­to­co­los.

Respecto a la seguridad, SOAP supone una gran ventaja: WS-Security (es­pe­ci­fi­ca­cio­nes para los criterios de seguridad respecto a servicios web) está anclado en el protocolo de red. También el tra­ta­mie­n­to de los errores está mejor regulado en SOAP, porque incorpora di­re­c­ta­me­n­te una función para la re­pe­ti­ción de la solicitud.

En resumen

Tanto SOAP como REST presentan ventajas y de­s­ve­n­ta­jas, de modo que no se puede concluir que una solución sea mejor que la otra. Sin embargo, por su sencillez, la mayoría de los de­sa­rro­lla­do­res recurren a REST. Fi­na­l­me­n­te, la decisión depende del lenguaje de pro­gra­ma­ción que se utilice y del contexto en el que se quiera utilizar el protocolo.

Ir al menú principal