SOAP (originalmente las siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. Este protocolo deriva de un protocolo creado por Dave Winer en 1998, llamado XML-RPC. SOAP fue creado por Microsoft, IBM y otros. Está actualmente bajo el auspicio de la W3C. Es uno de los protocolos utilizados en los servicios Web.
SOAP es un paradigma de mensajería de una dirección sin estado, que puede ser utilizado para formar protocolos más completos según las necesidades de las aplicaciones que lo implementan. Puede formar y construir la capa base de una "pila de protocolos de web service", ofreciendo un framework de mensajería básica en el cual los web services se pueden construir. Este protocolo está basado en XML y se conforma de tres partes:
El protocolo SOAP tiene tres características principales:
Como ejemplo de cómo el modelo SOAP pueda ser utilizado, consideraremos un mensaje SOAP que podría ser enviado a un web service para realizar la búsqueda de algún precio en una base de datos, indicando para ello los parámetros necesitados en la consulta. El servicio podría retornar un documento en formato XML con el resultado, un ejemplo, precios, localización o características. Teniendo los datos de respuesta en un formato estandarizado procesable (en inglés "parsable"), éste puede ser integrado directamente en un sitio Web o aplicación externa.
La arquitectura SOAP está formada por varias capas de especificación: MEP (Message Exchange Patterns) para el formato del mensaje, enlaces subyacentes del protocolo de transporte, el modelo de procesamiento de mensajes, y la capa de extensibilidad del protocolo. SOAP es el sucesor de XML-RPC, a pesar de que toma el transporte y la neutralidad de la interacción, así como el envelope / header / body, de otros modelos (probablemente de WDDX).
La preocupación por los sistemas distribuidos y de cómo diferentes máquinas podían comunicarse entre sí surgió en la década de los 90. Hasta ese momento, era suficiente con que las aplicaciones de un mismo ordenador pudieran establecer una comunicación.
En 1990, surgieron los modelos COM y CORBA. El primero, Component Object Model fue creado por Microsoft, y el segundo, CORBA, por el Object Management Group. No obstante, estos dos modelos presentaban una dificultad muy importante: no eran fácilmente interoperables ya que las dos máquinas que llevaran a cabo la comunicación debían soportar COM o CORBA, por tanto únicamente se podía utilizar con dos máquinas COM o dos máquinas CORBA. Más adelante, Microsoft creó DCOM y Sun, RMI (Remote Method Invocation). Aunque estos métodos permitían establecer una conexión entre ordenadores a través de la red, tampoco eran interoperables ya que RMI está disponible únicamente para Java, y por tanto, es dependiente del lenguaje de programación. Por todo ello, Microsoft empezó a interesarse por la computación distribuida basada en XML en el año 1997. Su objetivo era terminar con los problemas de interoperabilidad de las soluciones anteriores y permitir que las aplicaciones se conectaran mediante RPCs (Remote Procedure Calls), utilizando los estándares de comunicación XML y HTTP.
SOAP fue diseñado como un protocolo de acceso a objetos en 1998 por Dave Winer, Don Box, Bob Atkinson y Mohsen Al-Ghosein por Microsoft, donde Atkinson y Al-Ghosein trabajaban en aquel entonces. La especificación SOAP actualmente es mantenida por el XML Protocol Working Group del World Wide Web Consortium.
La versión SOAP 1.1 se presentó en el año 2000 e IBM participó en su creación. Esta participación resultó muy positiva ya que se produjeron cambios significativos y cruciales para su posterior uso: se diseñó de una forma más modular y escalable, eliminando los problemas derivados de una tecnología propietaria, en este caso de Microsoft. Además, IBM llevó a cabo una implementación de SOAP en Java y SOAP se integró en Web Services J2EE.
SOAP originalmente significaba "Simple Object Access Protocol", pero esta sigla se abandonó con la versión 1.2 de la norma. La versión 1.2 se convirtió en una recomendación del W3C el 24 de junio de 2003. El acrónimo se confunde a veces con SOA, siglas de arquitectura orientada a servicios, pero las siglas no están relacionados.
Después que SOAP se introdujo por primera vez, se convirtió en la capa subyacente de un conjunto más complejo de los web services, basada en la WSDL (Web Services Description Language) y UDDI (Universal Description Discovery and Integration). Estos servicios, especialmente UDDI, han demostrado ser de mucho menos interés, pero una apreciación de ellos da una comprensión más completa del esperado rol de SOAP comparado a como los web services están actualmente desarrollados.
Un mensaje SOAP es un documento XML ordinario con una estructura definida en la especificación del protocolo. Dicha estructura la conforman las siguientes partes:
En los próximos apartados de este documento se podrá apreciar esta estructura con ejemplos concretos.
El modelo de procesado de SOAP está definido como un sistema distribuido, en el que intervienen diferentes nodos. En un escenario básico, los nodos SOAP se comunican uno asumiendo el rol de SOAP Sender y otro el de SOAP Receiver. Aun así, la especificación define diferentes tipos de nodos en función del rol que asumen en el envío del mensaje:
Un nodo SOAP puede actuar con uno o varios roles, cada uno de los cuales se encuentra definido mediante una URI conocida como el nombre de rol. Los roles asumidos por un nodo son invariantes durante el envío de un mensaje, teniendo en cuenta la especificación el procesado individual de mensajes. Tal y como se ha comentado, una aplicación puede crear protocolos de comunicación más complejos como capas superiores sobre SOAP, pudiendo definir sus propios roles para poder cumplir con sus necesidades.
La especificación de SOAP define unas normas sobre cómo deben ser procesados, definiendo una serie de pasos que deben cumplir las implementaciones del protocolo. Estos pasos se pueden encontrar en la sección 2.6 de la especificación de W3C.
Los desarrolladores de aplicaciones hoy en día, pueden utilizar la infraestructura de correo electrónico de Internet para transmitir mensajes SOAP ya sea como mensajes de correo electrónico de texto o como adjuntos. Los ejemplos que se muestran a continuación muestran un modo de transmitir mensajes SOAP, y deben ser tomados como el modo estándar de hacerlo. Las especificaciones SOAP Versión 1.2 no especifican tal vínculo. Sin embargo, existe una Nota W3C no-normativa [SOAP Email Binding] que describe un vínculo de SOAP con el correo electrónico. Su propósito principal es comenzar a demostrar la aplicación de la Infraestructura general de Vínculos con el Protocolo SOAP.
El ejemplo muestra el mensaje de petición de reserva de viaje del Ejemplo 1 transportado como un mensaje de correo electrónico entre un agente de usuario remitente y un agente de usuario destinatario. Está implícito que el nodo destinatario tiene capacidad para entender SOAP, por lo que se envía el mensaje de correo electrónico para su procesamiento. (Se asume que también el nodo remitente puede manejar errores SOAP que pudiera recibir en la respuesta o correlacionar cualesquiera mensajes SOAP recibidos en respuesta a éste).
De: a.oyvind@miempresa.example.com A: reservas@empresaviajes.example.org Asunto: Viaje a LA Fecha: Thu, 29 Nov 2001 13:20:00 EST Message-Id: <EE492E16A090090276D208424960C0C@miempresa.example.com> Content-Type: application/soap+xml
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reserva xmlns:m="[[http://www.example.org]]"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:referencia>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:referencia>
<m:fechaYHora>2001-11-29T13:20:00.000-05:00</m:fechaYHora>
</m:reserva>
<n:pasajero xmlns:n="http://miempresa.example.com/empleados"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:nombre>Åke Jógvan Øyvind</n:nombre>
</n:pasajero >
</env:Header>
<env:Body>
<p:itinerario xmlns:p="http://empresaviajes.example.org/reserva/viaje">
<p:ida>
<p:salida>Nueva York</p:salida>
<p:llegada>Los Angeles</p:llegada>
<p:fechaSalida>2001-12-14</p:fechaSalida>
<p:horaSalida>última hora de la tarde</p:horaSalida>
<p:preferenciaAsiento>pasillo</p:preferenciaAsiento>
</p:ida>
<p:vuelta>
<p:salida>Los Angeles</p:salida>
<p:llegada>Nueva York</p:llegada>
<p:fechaSalida>2001-12-20</p:fechaSalida>
<p:horaSalida>media-mañana</p:horaSalida>
<p:preferenciaAsiento />
</p:vuelta>
</p:itinerario>
<q:alojamiento xmlns:q="http://empresaviajes.example.org/reserva/hoteles">
<q:preferencia>ninguna</q:preferencia>
</q:alojamiento>
</env:Body>
</env:Envelope>Mensaje SOAP del Ejemplo 1 transportado como un mensaje SMTP
El encabezado del Ejemplo tiene la forma estándar de [RFC 2822] para mensajes de correo electrónico.
Aunque el correo electrónico es un intercambio de mensajes en un solo sentido, y no se da ninguna garantía de entrega, infraestructuras como la de la especificación Simple Mail Transport Protocol (SMTP) ofrecen un mecanismo de notificación de entrega que, en el caso de SMTP, se denominan Delivery Status Notification (DSN) [Notificación de Estado de Entrega] y Message Disposition Notification (MDN) [Notificación de Disposición de Mensaje]. Estas notificaciones toman la forma de mensajes de correo electrónico enviados a la dirección de correo electrónico especificada en el encabezamiento del mensaje de correo. Las aplicaciones, así como los usuarios finales del correo, pueden utilizar estos mecanismos para proporcionar el estado de una transmisión de correo electrónico, pero estos, si existiesen, serían notificaciones al nivel SMTP. El desarrollador de aplicaciones debe comprender completamente las capacidades y limitaciones de estas notificaciones de entrega o el riesgo de asumir que haya existido una entrega del mensaje con éxito cuando podría no haberse producido.
Los mensajes de estado de entrega SMTP son separados del procesamiento del mensaje en la capa SOAP. Las respuestas SOAP resultantes a los datos SOAP serán devueltas a través de un mensaje de correo electrónico nuevo que podría tener o no un enlace con el mensaje de la petición original al nivel SMTP. El uso del encabezado In-reply-to: [En-respuesta-a] según [RFC 2822] puede conseguir una correlación al nivel SMTP, pero no implica necesariamente una correlación al nivel SOAP.
Como ejemplo se muestra la forma en que un cliente solicitaría información de un producto a un proveedor de servicios Web:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails xmlns="http://warehouse.example.com/ws">
<productId>827635</productId>
</getProductDetails>
</soap:Body>
</soap:Envelope>
Y esta sería la respuesta del proveedor:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
<getProductDetailsResult>
<productName>Toptimate 3-Piece Set</productName>
<productId>827635</productId>
<description>3-Piece luggage set. Black Polyester.</description>
<price>96.50</price>
<inStock>true</inStock>
</getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>
A pesar de no ser la única opción posible, HTTP fue elegido como protocolo de transporte por sus ventajas, para lidiar con cortafuegos, por ejemplo. Otros protocolos como GIOP/IIOP o DCOM (utilizados en CORBA, RMI y DCOM) suelen ser repelidos por estos cortafuegos.
La forma más habitual de utilizar el protocolo SOAP es mediante el patrón petición-respuesta con remitente SOAP y destinatario final SOAP, el cual es utilizado cuando los mensajes SOAP están predefinidos y únicamente se desea enviar una petición y consultar su valor de retorno.
No obstante, muchas veces este patrón no es suficiente, y es necesario establecer un intercambio múltiple de mensajes entre los nodos. La W3C define dos tipos de intercambios de mensajes SOAP para formar una conversación:
En ocasiones, es necesario el uso de intermediarios en las comunicaciones SOAP, la especificación SOAP 1.2 define dos tipos:
Todos los lenguajes de uso mayoritario en el desarrollo de sistemas web implementan o incluyen algún tipo de soporte para la implementación tanto de servicios web SOAP como de los clientes que los consumen. Además de bibliotecas que implementan el protocolo a nivel básico, encontramos otras que implementan diferentes escenarios de uso y establecen interfaces más sencillas simplificando la programación.
Estas bibliotecas, utilizadas en conjunto con frameworks de desarrollo de sistemas web agilizan el proceso de desarrollo tanto del servicio web como de sus clientes, en especial si se genera un fichero WSDL que comunique a los clientes las características del servicio.