citygame32

Estructura de un mensaje SOAP

SOAP (originalmente las siglas de Simple Object Access Protocol) es un que define de qué forma dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos . Este protocolo deriva de un protocolo creado por en mil novecientos noventa y ocho, llamado . SOAP fue creado por , y otros. Está actualmente bajo el auspicio de la . Es uno de los protocolos usados en los .

Características

SOAP es un paradigma de correo de una dirección sin estado, que puede ser usado para formar protocolos más completos y complejos conforme las necesidades de las aplicaciones que lo incorporan. Puede formar y edificar la capa base de una " de web service", ofertando un framework de mensajería 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 que 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 3 características principales:

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

Como ejemplo de cómo el modelo SOAP pueda ser empleado, consideraremos un mensaje SOAP que podría ser mandado a un web service para realizar la busca de algún costo en una base de datos, indicando para ello los factores necesitados en la consulta. El servicio podría regresar un documento en formato XML con el resultado, un ejemplo, precios, localización o bien peculiaridades. 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 múltiples capas de especificación: (Message Exchange Patterns) para el formato del mensaje, links subyacentes 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, así como el envelope / header / body, de otros modelos (seguramente de ).

La preocupación por los sistemas distribuidos y de de qué forma diferentes máquinas podían comunicarse entre sí brotó en la década de los noventa. Hasta ese momento, era suficiente con que las aplicaciones de un mismo ordenador pudiesen 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 2 modelos presentaban una dificultad muy importante: no eran sencillamente interoperables puesto que las 2 máquinas que llevaran a cabo la comunicación debían aguantar COM o bien CORBA, en consecuencia únicamente se podía emplear con 2 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 mediante la red, tampoco eran interoperables puesto que RMI está disponible únicamente para Java, y por ende, 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 mil novecientos noventa y siete. Su objetivo era terminar con los inconvenientes de interoperabilidad de las soluciones anteriores y permitir que las aplicaciones se conectasen mediante RPCs (Remote Procedure Calls), utilizando los estándares de comunicación y .

SOAP fue desarrollado 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 hoy en día es mantenida por el XML Protocol Working Group del .

La versión SOAP once se presentó en el año dos mil e IBM participó en su creación. Esta participación resultó positivísima ya que se produjeron cambios significativos y vitales para su siguiente uso: se diseñó de una manera más modular y escalable, suprimiendo 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", mas esta inicial se abandonó con la versión 1.2 de la regla. La versión doce se convirtió en una recomendación del el veinticuatro de junio de dos mil tres. El acrónimo se confunde en ocasiones con , siglas de arquitectura orientada a servicios, pero las iniciales no están relacionados.

Después que SOAP se introdujo por primera vez, se transformó 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, especialmente UDDI, han probado ser de mucho menos interés, pero una consideración de ellos da una comprensión más completa del aguardado rol de SOAP equiparado a como los web services están hoy en día desarrollados.

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 próximas 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 puesto que permite mandar información relativa a cómo ha de ser procesado el mensaje. Es una herramienta a fin de que los mensajes puedan ser mandados de la manera más recomendable para las aplicaciones. El factor "Header" se compone por su parte de "Header Blocks" que delimitan las unidades de información necesarias 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 errores que se hayan producido a lo largo del 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 querer esta estructura con ejemplos concretos.

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. Incluso de esta manera, 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 acepta un mensaje.
• SOAP message path: conjunto de nodos por los cuales debe pasar un mensaje SOAP, incluyendo el nodo inicial, cero o más nodos intermediarios y el SOAP Receiver terminante.
• Initial SOAP sender: el "sender" que origina el mensaje y que es el punto de comienzo del camino que seguirá el mensaje.
• SOAP intermediary: el intercesor actúa como SOAP receiver y como SOAP sender, ya 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 responsable de procesarlo. Podemos 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 roles, cada uno de ellos de los cuales se halla definido mediante una URI conocida como el nombre de rol. Los papeles asumidos por un nodo son invariantes a lo largo del envío de un mensaje, teniendo presente la especificación el procesado individual de mensajes. Tal como se ha comentado, una aplicación puede crear protocolos de comunicación más complejos como capas superiores sobre SOAP, pudiendo delimitar sus propios roles para poder cumplir con sus necesidades.

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

SOAP sobre correo electrónico

Los desarrolladores de aplicaciones actualmente, pueden emplear la infraestructura de mail de Internet para trasmitir mensajes SOAP ya sea como mensajes de correo de texto o como adjuntos. Los ejemplos que se muestran ahora muestran un modo de trasmitir mensajes SOAP, y deben ser tomados como el modo perfecto estándar de hacerlo. Las especificaciones SOAP Versión 1.2 no detallan tal vínculo. Sin embargo, hay una Nota W3C no-normativa [SOAP Correo electrónico Binding] que describe un vínculo de SOAP con el correo electrónico. Su propósito principal es empezar 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 remitente y un agente de usuario destinatario. Está implícito que el nodo destinatario tiene capacidad para entender SOAP, por lo que se manda el mensaje de correo electrónico para su procesamiento. (Se asume que asimismo el nodo remitente puede manejar fallos SOAP que pudiese percibir en la contestación o bien correlacionar cualesquiera mensajes SOAP recibidos en contestación a este).

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

Aunque el correo electrónico 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 E-mail 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 manera de mensajes de e mail enviados a la dirección de e mail especificada en el encabezado del mensaje de correo. Las aplicaciones, así como los usuarios finales del correo, pueden usar estos mecanismos para otorgar el estado de una transmisión de mail, pero estos, si existieran, serían notificaciones al nivel SMTP. El desarrollador de aplicaciones debe entender totalmente las capacidades y limitaciones de estas notificaciones de entrega o el peligro de aceptar que haya existido una entrega del mensaje de forma exitosa cuando podría no haberse producido.

Los mensajes de estado de entrega SMTP son separados del procesamiento del mensaje en la capa SOAP. Las contestaciones SOAP resultantes a los datos SOAP van a ser devueltas por medio de un mensaje de mail nuevo que podría tener o bien no un link con el mensaje de la solicitud original al nivel SMTP. El empleo del encabezado In-reply-to: [En-respuesta-a] según puede conseguir una relación al nivel SMTP, mas no implica necesariamente una relación al nivel SOAP.

Ejemplos de mensajes SOAP

Como ejemplo se muestra la manera en que un cliente solicitarí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 elegido como protocolo de transporte por sus ventajas, para lidiar con cortafuegos, por ejemplo. Otros protocolos como GIOP/IIOP o bien DCOM (usados en CORBA, RMI y DCOM) suelen ser repelidos por estos cortafuegos.

Ventajas y desventajas

• Debido al uso de XML deja invocar procedimientos recónditos de muchos lenguajes, por tanto, presenta una enorme interoperabilidad.
• Al utilizar una comunicación vía es de forma fácil escalable, aparte de ser prácticamente siempre permitido por los cortafuegos.
• Puede ser implementado utilizando cualquier lenguaje y ejecutado en cualquier plataforma.
• Es posible usarlo a través de usuario anónimo y a través de autentificación.
• Es posible transmitirlo mediante cualquier protocolo de transporte capaz de transmitir texto, típicamente o .

Desventajas

• Debido al empleo de XML para el paso de mensajes, SOAP es considerablemente más lento que otros middleware como puesto que los datos binarios se codifican como texto. Para contrarrestar este punto enclenque en el caso de XML con código binario incrustado se desarrolló un procedimiento optimado de transmisión de mensajes.
• Depende del (Web Services Description Language).
• Al contrario que Java, PHP o Python algunos lenguajes no ofrecen un apoyo adecuado para su uso así sea a nivel de integración o de soporte .

Casos de uso

La forma más habitual de utilizar el protocolo SOAP es mediante el patrón petición-respuesta con remitente SOAP y receptor final SOAP, el que es usado cuando los mensajes SOAP están predefinidos y únicamente se quiere enviar una solicitud y consultar su valor de retorno.

No obstante, muchas veces este patrón no es suficiente, y es preciso establecer un intercambio múltiple de mensajes entre los nodos. La W3C define dos géneros 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 terminar comportándose como un patrón de mensajes de ida y vuelta.

• Llamadas a Procedimientos Remotos: permite 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 realizar invocaciones y respuestas RPC a través de mensajes SOAP.

En ocasiones, es necesario el empleo de intermediarios en las comunicaciones SOAP, la especificación SOAP doce define dos tipos:

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

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

Implementación de un servicio web SOAP

Todos los lenguajes de uso mayoritario en el desarrollo de sistemas web incorporan o bien incluyen algún género 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, encontramos otras que incorporan diferentes escenarios de uso y establecen interfaces más fáciles simplificando 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, de forma especial si se genera un archivo WSDL que comunique a los clientes del servicio las peculiaridades del servicio.

• JAVA: en su librería estándar se hallan implementaciones concretas 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 simplificando las interfaces y también incorporando los casos de empleo más frecuentes. Se puede destacar que los IDEs más usados ofrecen soporte para la creación de servicios web SOAP que, entre otras cosas, generan automáticamente el archivo WSDL y permiten diseñar de manera visual el API y las llamadas que contendrá. Cuando el servidor a usar, se pueden considerar las opciones habituales en Java: Tomcat, Glassfish, etc. Incluso de creacion de paginas web , la elección del servidor puede suponer ciertas ventajas, por ejemplo, Glassfish produce una fácil interfaz web para probar las diferentes llamadas del servicio. Además, la mayor parte de herramientas dejan la .

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

• Python: no ofrece un soporte en sus librerías estándar, no obstante, existe un gran número de paquetes 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, prevalece 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 desde el archivo de definición del servicio. En el caso de .NET, el IDE señalado 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.