Simple Object Access Protocol

Estructura de un mensaje SOAP

SOAP (originalmente las siglas de Simple Object Access Protocol) es un que define de qué manera 2 objetos en diferentes procesos pueden comunicarse a través de intercambio de datos . Este protocolo deriva de un protocolo creado por en 1998, llamado . SOAP fue creado por , y otros. Está hoy en día bajo el auspicio de la . Es uno de los protocolos utilizados en los .

Back to top

1) Características

SOAP es un paradigma de mensajería de una dirección sin estado, que puede ser usado para formar protocolos más completos y complejos según las necesidades de las aplicaciones que lo implementan. Puede formar y edificar la capa base de una " de web service", ofertando un framework de correo básica en el que los web services se pueden edificar. Este protocolo está basado en XML y se conforma de tres partes:

• Sobre (envelope): el cual define qué hay en el mensaje y de qué manera procesarlo.
• Conjunto de reglas de codificación para expresar instancias de tipos de datos.
• La Convención para representar llamadas a procedimientos y respuestas.

El protocolo SOAP tiene tres características principales:

• Extensibilidad (seguridad y WS-routing son extensiones aplicadas en el desarrollo).
• Neutralidad (bajo protocolo de transporte puede ser usado sobre cualquier protocolo de aplicación como , o ).
• Independencia (deja cualquier modelo de programación).

Como ejemplo de cómo el modelo SOAP pueda ser utilizado, consideraremos un mensaje SOAP que podría ser mandado a un web service para realizar la búsqueda de algún coste en una base de datos, indicando para esto los parámetros necesitados en la consulta. El servicio podría retornar un documento en formato XML con el resultado, un ejemplo, precios, ubicación o bien características. Teniendo los datos de respuesta en un formato estandarizado procesable (en inglés "parsable"), éste puede ser integrado directamente en un lugar Web o aplicación externa.

La arquitectura SOAP está formada por varias capas de especificación: (Message Exchange Patterns) para el formato del mensaje, links latentes del protocolo de transporte, el modelo de procesamiento de mensajes, y la capa de extensibilidad del protocolo. SOAP es el sucesor de , a pesar de que toma el transporte y la neutralidad de la interacción, como el envelope / header / body, de otros modelos (seguramente de ).

La preocupación por los sistemas distribuidos y de de qué manera diferentes máquinas podían comunicarse entre sí brotó 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 mil novecientos noventa, surgieron los modelos y . El primero, Component Object Model fue creado por Microsoft, y el segundo, CORBA, por el Object Management Group. Sin embargo, estos dos modelos presentaban una complejidad muy importante: no eran sencillamente interoperables ya que las 2 máquinas que llevaran a cabo la comunicación debían soportar COM o CORBA, por lo tanto únicamente se podía emplear con dos máquinas COM o bien dos máquinas CORBA. Más adelante, Microsoft creó DCOM y Sun, (Remote Method Invocation). Aunque estos métodos dejaban establecer una conexión entre ordenadores a través de la red, tampoco eran interoperables puesto que RMI está libre solamente para Java, y en consecuencia, es dependiente del lenguaje de programación. Por todo ello, Microsoft empezó a interesarse por la computación distribuida basada en en el año 1997. Su objetivo era acabar con los inconvenientes de interoperabilidad de las soluciones anteriores y dejar que las aplicaciones se conectaran mediante RPCs (Remote Procedure Calls), utilizando los estándares de comunicación y .

SOAP fue desarrollado como un protocolo de acceso a objetos en mil novecientos noventa y ocho por Dave Winer, Don Box, Bob Atkinson y Mohsen Al-Ghosein por Microsoft, donde Atkinson y Al-Ghosein trabajaban en aquel momento. La en la actualidad es mantenida por el XML Protocol Working Group del .

La versión SOAP 1.1 se presentó en el año dos mil 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, suprimiendo los inconvenientes derivados de una tecnología dueña, en un caso así de Microsoft. Además de esto, 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", mas esta sigla se abandonó con la versión doce de la norma. La versión 1.2 se transformó en una recomendación del el veinticuatro de junio de 2003. El acrónimo se confunde a veces con , 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 latente de un conjunto más complejo de los web services, basada en la (Web Services Description Language) y (Universal Description Discovery and Integration). Estos servicios, en especial UDDI, han probado ser de mucho menos interés, pero una apreciación de ellos da una comprensión más completa del aguardado rol de SOAP comparado a como los web services están hoy en día desarrollados.

Back to top

2) Estructura del mensaje

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:

• Envelope (obligatoria): raíz que de la estructura, es la parte que identifica al mensaje SOAP como tal.
• Header: esta parte es un mecanismo de extensión ya que permite enviar información relativa a cómo ha de ser procesado el mensaje. Es una herramienta para que los mensajes puedan ser mandados de la forma más conveniente para las aplicaciones. El elemento "Header" se compone por su parte de "Header Blocks" que delimitan las unidades de información precisas para el header.
• Body (obligatoria): contiene la información relativa a la llamada y la contestación.
• Fault: bloque que contiene información relativa a fallos que se hayan producido durante el procesado del mensaje y el envío desde el "SOAP Sender" hasta el "Ultimate SOAP Receiver".

En los próximos apartados de este documento se va a poder apreciar esta estructura con ejemplos concretos.

Back to top

3) Modelo de procesado

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 géneros de nodos en función del rol que aceptan en el envío del mensaje:

• SOAP Sender: nodo que transmite un mensaje SOAP.
• SOAP Receiver: nodo que admite un mensaje.
• SOAP message path: conjunto de nodos por los que debe pasar un mensaje SOAP, incluyendo el nodo inicial, cero o más nodos mediadores y el SOAP Receiver definitivo.
• Initial SOAP sender: el "sender" que origina el mensaje y que es el punto de inicio del camino que seguirá el mensaje.
• SOAP intermediary: el mediador actúa como SOAP receiver y como SOAP sender, en tanto que primero recibe el mensaje para después reenviarlo al siguiente nodo en el camino.
• Ultimate SOAP receiver: destino final del mensaje SOAP, es el encargado de procesarlo. Cabe destacar que el mensaje podría no llegar al receptor definitivo debido a que problemas en los intercesores hagan que se pierda.

Un nodo SOAP puede actuar con uno o bien múltiples papeles, cada uno de los que se encuentra definido mediante una URI famosa 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. Como se ha comentado, una aplicación puede crear protocolos de comunicación más complejos como capas superiores sobre SOAP, pudiendo acotar sus propios papeles para poder cumplir con sus necesidades.

La especificación de SOAP define unas normas sobre de qué forma deben ser procesados, definiendo una serie de pasos que deben cumplir las implementaciones del protocolo. Estos pasos se pueden localizar en la sección .

Back to top

4) SOAP sobre correo electrónico

Los desarrolladores de aplicaciones hoy en día, pueden usar la infraestructura de mail de Internet para trasmitir 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 han de ser tomados como el modo perfecto 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 e-mail. Su propósito principal es comenzar a probar 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 entre un agente de usuario expedidor y un agente de usuario destinatario. Está tácito que el nodo destinatario tiene capacidad para comprender SOAP, por lo que se manda el mensaje de e-mail para su procesamiento. (Se acepta que asimismo el nodo remitente puede manejar errores SOAP que pudiera percibir en la contestación o relacionar cualesquiera mensajes SOAP recibidos en respuesta a éste).

El encabezado del Ejemplo tiene la manera estándar de para mensajes de .

Aunque el e-mail es un intercambio de mensajes en un sentido, y no se da ninguna garantía de entrega, infraestructuras como la de la especificación Simple Correo electrónico Transport Protocol () 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 e mail mandados a la dirección de e mail concretada en el encabezado del mensaje de correo. Las aplicaciones, como los usuarios finales del correo, pueden usar estos mecanismos para otorgar 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 totalmente las capacidades y limitaciones de estas notificaciones de entrega o el peligro de asumir que haya existido una entrega del mensaje exitosamente 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 por medio de un mensaje de e-mail nuevo que podría tener o bien no un link con el mensaje de la petición original al nivel SMTP. El uso del encabezado In-reply-to: [En-contestación-a] según puede conseguir una correlación al nivel SMTP, pero no implica necesariamente una correlación al nivel SOAP.

Back to top

5) Ejemplos de mensajes SOAP

Como ejemplo se muestra la manera en que un usuario pediría información de un producto a un proveedor de servicios Web:

Y esta sería la respuesta del proveedor:

A pesar de no ser la única opción posible, HTTP fue escogido como protocolo de transporte por sus ventajas, para lidiar con cortafuegos, por poner un ejemplo. Otros protocolos como GIOP/IIOP o DCOM (utilizados en CORBA, RMI y DCOM) acostumbran a ser repelidos por estos cortafuegos.

Back to top

6) Ventajas y desventajas

• Debido al uso de XML permite invocar procedimientos remotos de muchos lenguajes, por ende, presenta una gran interoperabilidad.
• Al usar una comunicación vía es de forma fácil escalable, aparte de ser prácticamente siempre tolerado por los cortafuegos.
• Puede ser incorporado usando cualquier lenguaje y ejecutado en cualquier plataforma.
• Es posible utilizarlo mediante usuario anónimo y a través de autentificación.
• Es posible transmitirlo a través de cualquier protocolo de transporte capaz de trasmitir texto, típicamente o bien .

6.1) Desventajas

• Debido al uso de XML para el paso de mensajes, SOAP es sensiblemente más lento que otros middleware como en tanto que los datos binarios se codifican como texto. Para contrarrestar este punto débil en el caso de XML con código binario engastado se desarrolló un método optimado de transmisión de mensajes.
• Depende del (Web Services Description Language).
• Al contrario que Java, PHP o Python determinados lenguajes no ofrecen un apoyo conveniente para su uso ya sea a nivel de integración o de soporte .

Back to top

7) Casos de uso

La forma más frecuente de emplear el protocolo SOAP es a través de el patrón petición-respuesta con remitente SOAP y destinatario final SOAP, el cual es usado cuando los mensajes SOAP están predefinidos y únicamente se desea mandar una petición y preguntar su valor de retorno.

No obstante, muy frecuentemente este patrón no es suficiente, y es necesario establecer un intercambio múltiple de mensajes entre los nodos. La W3C define 2 tipos de intercambios de mensajes SOAP para formar una conversación:

• Intercambio de mensajes Conversacionales: deja redefinir la información de la petición. Estos intercambios pueden acabar comportándose como un patrón de mensajes de ida y vuelta.

• Llamadas a Procedimientos Remotos: deja encapsular la funcionalidad de procedimientos recónditos usando las ventajas de XML de extensibilidad y funcionalidad, por este motivo se ha definido en la especificación una representación uniforme para efectuar invocaciones y contestaciones RPC a través de mensajes SOAP.

En ocasiones, es necesario el empleo de intercesores en las comunicaciones SOAP, la especificación SOAP 1.2 define 2 tipos:

• Intermediario redirector: se trata de un nodo SOAP, el que redirige el mensaje SOAP a otro nodo SOAP conforme lo establecido en un bloque de encabezado que ha recibido el nodo destino o conforme el patrón de mensajes en uso.

• Intermediario activo: efectúa un procesamiento auxiliar del mensaje SOAP ya antes de redirigirlo, sin utilizar criterios descritos en el encabezado del mensaje o bien del patrón de mensajes en empleo.

Back to top

8) Implementación de un servicio web SOAP

Todos los lenguajes de empleo mayoritario en el desarrollo de sistemas web incorporan o bien incluyen algún tipo de soporte para la implementación tanto de web services SOAP como de los clientes del servicio que los consumen. Aparte de librerías que implementan el protocolo a nivel básico, hallamos otras que incorporan diferentes escenarios de uso y establecen interfaces más fáciles facilitando la programación.

Estas librerías, usadas en conjunto con frameworks de desarrollo de sistemas web agilizan el proceso de desarrollo tanto del web service como de sus clientes, especialmente si se genera un fichero WSDL que comunique a los clientes las características del servicio.

• JAVA: dentro de su librería estándar se encuentran implementaciones específicas a las que se da soporte oficial. También podemos encontrar librerías de terceros que, tal y como se ha comentado, ayudan al desarrollador facilitando las interfaces y también implementando los casos de empleo más habituales. Cabe destacar que los IDEs más usados ofrecen soporte para la creación de servicios web SOAP que, entre otras muchas cosas, generan automáticamente el fichero WSDL y dejan diseñar de manera visual el API y las llamadas que contendrá. En cuanto el servidor a utilizar, se pueden considerar las opciones típicas en Java: Tomcat, Glassfish, etc. Incluso de esta forma, la elección del servidor puede suponer ciertas ventajas, por ejemplo, Glassfish genera una sencilla interfaz web para probar las distintas llamadas del servicio. Además de esto, la mayor parte de herramientas permiten la .

• PHP: ofrece soporte y unas librerías de apoyo habilitando la en el servidor. Se ha desarrollado un , que combinadas con el uso de frameworks MVC, simplifican las interfaces e implementan los escenarios de empleo más frecuentes. También son habituales las implementaciones de clientes para servicios web públicos específicos.

• Python: no ofrece un soporte en sus librerías estándar, no obstante, hay un elevado número de bultos de terceros que permiten la implementación de servicios web SOAP y sus clientes del servicio. En el ámbito del desarrollo de servicios web en Python, predomina la utilización del que se puede conjuntar con cualquiera de las implementaciones de SOAP.

• .NET: en el Framework se ofrecen herramientas similares a las de Java para el diseño visual del servicio y la creación automática de WSDL . También da soporte para la creación de los clientes del servicio a partir del archivo de definición del servicio. En el caso de .NET, el IDE destacado es Visual Studio. En lo que se refiere a librerías hallamos que el ecosistema .NET ofrece múltiples opciones en múltiples lenguajes, aunque la apuesta actual de Microsoft para el desarrollo web es su . Se debe tomar en consideración, que Microsoft creó el formato que es un modelo para la creación de sistemas orientados a servicios, similar y complementario al WSDL.

Back to top