JABÓN

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "SOAP" – news · newspapers · books · scholar · JSTOR (December 2023) (Learn how and when to remove this message)

SOAP ^[a] es una especificación de protocolo de mensajería para intercambiar información estructurada en la implementación de servicios web en redes informáticas . Utiliza el conjunto de información XML para su formato de mensaje y se basa en protocolos de capa de aplicación , con mayor frecuencia el Protocolo de transferencia de hipertexto (HTTP), aunque algunos sistemas heredados se comunican mediante el Protocolo simple de transferencia de correo (SMTP) para la negociación y transmisión de mensajes.

SOAP proporciona la capa de protocolo de mensajería de una pila de protocolos de servicios web. Es un protocolo basado en XML que consta de tres partes:

• un sobre, que define la estructura del mensaje ^[1] y cómo procesarlo
• un conjunto de reglas de codificación para expresar instancias de tipos de datos definidos por la aplicación
• una convención para representar llamadas y respuestas a procedimientos

SOAP tiene tres características principales:

1. extensibilidad (la seguridad y WS-Addressing se encuentran entre las extensiones en desarrollo)
2. Neutralidad (SOAP puede operar sobre cualquier protocolo como HTTP , SMTP , TCP , UDP )
3. Independencia (SOAP permite cualquier modelo de programación )

Como ejemplo de lo que pueden hacer los procedimientos SOAP, una aplicación puede enviar una solicitud SOAP a un servidor que tenga servicios web habilitados (como una base de datos de precios de bienes raíces) con los parámetros para una búsqueda. El servidor luego devuelve una respuesta SOAP (un documento con formato XML) con los datos resultantes, por ejemplo, precios, ubicación, características. Dado que los datos generados vienen en un formato estandarizado que puede analizar la máquina, la aplicación solicitante puede integrarlos directamente.

La arquitectura SOAP consta de varias capas de especificaciones para:

• formato del mensaje
• Patrones de intercambio de mensajes (MEP)
• enlaces de protocolo de transporte subyacentes
• modelos de procesamiento de mensajes
• extensibilidad del protocolo

SOAP evolucionó como sucesor de XML-RPC , aunque toma prestada su neutralidad de transporte e interacción del Direccionamiento de Servicios Web ^[2] y el sobre/encabezado/cuerpo de otro lugar (probablemente de WDDX ). ^{[ cita requerida ]}

SOAP fue diseñado como un protocolo de acceso a objetos y lanzado como XML-RPC en junio de 1998 como parte de Frontier 5.1 por Dave Winer , Don Box , Bob Atkinson y Mohsen Al-Ghosein para Microsoft , donde trabajaban Atkinson y Al-Ghosein. ^[3] La especificación no estuvo disponible hasta que se envió a IETF el 13 de septiembre de 1999. ^{[4] [5]} Según Don Box, esto se debió a la política dentro de Microsoft. ^[6] Debido a la vacilación de Microsoft, Dave Winer lanzó XML-RPC en 1998. ^[7]

El borrador de Internet presentado no alcanzó el estatus de RFC y, por lo tanto, no se lo considera un "estándar web" como tal. La versión 1.1 de la especificación se publicó como una nota del W3C el 8 de mayo de 2000. ^[8] Dado que la versión 1.1 no alcanzó el estatus de recomendación del W3C , tampoco puede considerarse un "estándar web". Sin embargo, la versión 1.2 de la especificación se convirtió en una recomendación del W3C el 24 de junio de 2003. SOAP originalmente significaba "Simple Object Access Protocol" (Protocolo simple de acceso a objetos), pero la versión 1.2 del estándar eliminó este acrónimo. ^[9]

La especificación SOAP ^[10] fue mantenida por el Grupo de Trabajo del Protocolo XML ^[11] del Consorcio World Wide Web hasta que el grupo fue cerrado el 10 de julio de 2009.

Después de su introducción, SOAP se convirtió en la capa subyacente de un conjunto más complejo de servicios web , basados ​​en WSDL , XSD y UDDI . Estos diferentes servicios, especialmente UDDI, han demostrado ser de mucho menos interés, pero su comprensión permite comprender por completo el papel esperado de SOAP en comparación con la evolución real de los servicios web.

La especificación SOAP puede definirse en términos generales como compuesta por los tres componentes conceptuales siguientes: conceptos de protocolo, conceptos de encapsulación y conceptos de red. ^[12]

JABÓN

Se trata de un conjunto de reglas que formalizan y rigen el formato y las reglas de procesamiento de la información intercambiada entre un emisor SOAP y un receptor SOAP.

Nodos SOAP

Son máquinas físicas/lógicas con unidades de procesamiento que se utilizan para transmitir/reenviar, recibir y procesar mensajes SOAP. Son análogos a los nodos de una red.

Funciones de SOAP

A lo largo de la ruta de un mensaje SOAP, todos los nodos asumen un rol específico. El rol del nodo define la acción que el nodo realiza sobre el mensaje que recibe. Por ejemplo, un rol " none" significa que ningún nodo procesará el encabezado SOAP de ninguna manera y simplemente transmitirá el mensaje a lo largo de su ruta.

Vinculación del protocolo SOAP

Un mensaje SOAP debe funcionar junto con otros protocolos para poder transferirse a través de una red. Por ejemplo, un mensaje SOAP podría utilizar TCP como protocolo de capa inferior para transferir mensajes. Estas vinculaciones se definen en el marco de vinculación del protocolo SOAP. ^[13]

Características de SOAP

SOAP proporciona únicamente un marco de mensajería. Sin embargo, se puede ampliar para agregar funciones como confiabilidad, seguridad, etc. Existen reglas que se deben seguir al agregar funciones al marco SOAP.

Módulo SOAP

Conjunto de especificaciones sobre la semántica del encabezado SOAP para describir las nuevas características que se amplían con SOAP. Un módulo debe implementar cero o más características. SOAP requiere que los módulos cumplan con las reglas prescritas. ^[14]

Mensaje SOAP

Representa la información que se intercambia entre 2 nodos SOAP.

Sobre de jabón

Es el elemento envolvente de un mensaje XML que lo identifica como un mensaje SOAP.

Bloque de encabezado SOAP

Un encabezado SOAP puede contener más de uno de estos bloques, cada uno de los cuales es un bloque computacional discreto dentro del encabezado. En general, la información de la función SOAP se utiliza para identificar nodos en la ruta. Se dice que un bloque de encabezado está destinado a un nodo SOAP si la función SOAP para el bloque de encabezado es el nombre de una función en la que opera el nodo SOAP. (p. ej.: un bloque de encabezado SOAP con el atributo de función como ultimateReceiver está destinado únicamente al nodo de destino que tiene esta función. Un encabezado con un atributo de función como next está destinado a cada intermediario, así como al nodo de destino).

Encabezado SOAP

Una colección de uno o más bloques de encabezado dirigidos a cada receptor SOAP.

Cuerpo de SOAP

Contiene el cuerpo del mensaje destinado al receptor SOAP. La interpretación y el procesamiento del cuerpo SOAP se definen mediante bloques de encabezado.

Error de SOAP

En caso de que un nodo SOAP no pueda procesar un mensaje SOAP, agrega la información de error al elemento de error SOAP. Este elemento está incluido en el cuerpo SOAP como un elemento secundario.

Remitente SOAP

El nodo que transmite un mensaje SOAP.

Receptor SOAP

El nodo que recibe un mensaje SOAP. (Podría ser un intermediario o el nodo de destino).

Ruta del mensaje SOAP

La ruta que consta de todos los nodos que el mensaje SOAP atravesó para llegar al nodo de destino.

Remitente SOAP inicial

Este es el nodo que originó el mensaje SOAP que se va a transmitir. Esta es la raíz de la ruta del mensaje SOAP.

Intermediario SOAP

Todos los nodos que se encuentran entre el origen de SOAP y el destino de SOAP previsto. Procesa los bloques de encabezado SOAP que se le dirigen y actúa para reenviar un mensaje SOAP hacia un receptor SOAP final.

Receptor SOAP definitivo

El receptor de destino del mensaje SOAP. Este nodo es responsable de procesar el cuerpo del mensaje y cualquier bloque de encabezado dirigido a él.

La especificación SOAP define el marco de mensajería, que consta de:

• El modelo de procesamiento SOAP , que define las reglas para procesar un mensaje SOAP ^[15]
• El modelo de extensibilidad SOAP que define los conceptos de características SOAP y módulos SOAP ^[15]
• El marco de enlace del protocolo subyacente SOAP que describe las reglas para definir un enlace a un protocolo subyacente que se puede utilizar para intercambiar mensajes SOAP entre nodos SOAP ^[15]
• La construcción del mensaje SOAP que define la estructura de un mensaje SOAP ^[15]

Un mensaje SOAP es un documento XML normal que contiene los siguientes elementos:

Tanto SMTP como HTTP son protocolos válidos de capa de aplicación que se utilizan como transporte para SOAP, pero HTTP ha ganado una mayor aceptación ya que funciona bien con la infraestructura de Internet actual; específicamente, HTTP funciona bien con los firewalls de red . SOAP también se puede utilizar sobre HTTPS (que es el mismo protocolo que HTTP en el nivel de aplicación, pero utiliza un protocolo de transporte cifrado por debajo) con autenticación simple o mutua; este es el método WS-I recomendado para proporcionar seguridad de servicio web como se indica en el Perfil básico WS-I 1.1.

Esta es una gran ventaja sobre otros protocolos distribuidos como GIOP/IIOP o DCOM , que normalmente son filtrados por firewalls. SOAP sobre AMQP es otra posibilidad que admiten algunas implementaciones. SOAP también tiene una ventaja sobre DCOM : no se ve afectado por los derechos de seguridad configurados en las máquinas que requieren conocimiento tanto de los nodos de transmisión como de recepción. Esto permite que SOAP se acople de forma flexible de una manera que no es posible con DCOM . También existe el estándar SOAP sobre UDP OASIS .

El conjunto de información XML se eligió como formato de mensaje estándar debido a su uso generalizado por las principales corporaciones y los esfuerzos de desarrollo de código abierto . Normalmente, el conjunto de información XML se serializa como XML . Una amplia variedad de herramientas disponibles de forma gratuita facilita significativamente la transición a una implementación basada en SOAP. La sintaxis algo larga de XML puede ser tanto una ventaja como una desventaja. Si bien facilita la detección de errores y evita problemas de interoperabilidad como el orden de bytes ( endianness ), puede reducir la velocidad de procesamiento y puede ser engorroso. Por ejemplo, CORBA , GIOP , ICE y DCOM utilizan formatos de mensajes binarios mucho más cortos. Por otro lado, hay dispositivos de hardware disponibles para acelerar el procesamiento de mensajes XML . ^{[16] [17]} El XML binario también se está explorando como un medio para optimizar los requisitos de rendimiento de XML. Los mensajes XML por su naturaleza autodocumentada suelen tener más "sobrecarga" (por ejemplo, encabezados, etiquetas anidadas, delimitadores) que los datos reales en contraste con los protocolos anteriores donde la sobrecarga era generalmente un porcentaje relativamente pequeño del mensaje general.

En la mensajería financiera, se ha descubierto que SOAP produce mensajes entre 2 y 4 veces más grandes que los protocolos anteriores FIX (Intercambio de información financiera) y CDR (Representación de datos comunes). ^[18]

No es necesario serializar el conjunto de información XML en XML. Por ejemplo, existen representaciones de conjuntos de información XML en CSV y JSON . Tampoco es necesario especificar un marco de transformación genérico. El concepto de enlaces SOAP permite enlaces específicos para una aplicación específica. El inconveniente es que tanto los remitentes como los receptores deben admitir este enlace recién definido.

El mensaje a continuación solicita el precio de las acciones de AT&T (símbolo bursátil "T").

POST  /InStock  HTTP / 1.1 Host :  www.example.org Tipo de contenido :  application/soap+xml; conjunto de caracteres=utf-8 Longitud del contenido :  299 Acción SOAPA :  "http://www.w3.org/2003/05/soap-envelope"<?xml version="1.0"?> <soap:Envelope xmlns:soap= "http://www.w3.org/2003/05/soap-envelope" xmlns:m= "http://www.example.org" > <soap:Header> </soap:Header> <soap:Body> <m:GetStockPrice> <m:StockName> T </m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope>         

This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources in this section. Unsourced material may be challenged and removed. (August 2020) (Learn how and when to remove this message)

• La característica de neutralidad de SOAP lo hace explícitamente adecuado para su uso con cualquier protocolo de transporte. Las implementaciones suelen utilizar HTTP como protocolo de transporte, pero se pueden utilizar otros protocolos de transporte populares. Por ejemplo, SOAP también se puede utilizar sobre SMTP, JMS ^{[19] [20]} y colas de mensajes .
• SOAP, cuando se combina con intercambios de publicaciones/respuestas HTTP, se conecta fácilmente a través de firewalls y servidores proxy existentes y, en consecuencia, no requiere modificar las infraestructuras de computación y comunicación generalizadas que existen para procesar intercambios de publicaciones/respuestas HTTP.
• SOAP tiene a su disposición todas las facilidades de XML, incluida la fácil internacionalización y extensibilidad con espacios de nombres XML.

• Al utilizar la implementación estándar y el enlace SOAP/HTTP predeterminado, el conjunto de información XML se serializa como XML. Para mejorar el rendimiento en el caso especial de XML con objetos binarios integrados, se introdujo el mecanismo de optimización de transmisión de mensajes .
• Cuando se confía en HTTP como protocolo de transporte y no se utiliza el direccionamiento de servicios web ni un bus de servicios empresariales , los roles de las partes que interactúan son fijos. Solo una de las partes (el cliente) puede utilizar los servicios de la otra.
• SOAP es menos "simple" de lo que sugiere su nombre. La verbosidad del protocolo, la lenta velocidad de análisis de XML y la falta de un modelo de interacción estandarizado llevaron al predominio de los servicios que utilizan el protocolo HTTP de forma más directa. Véase, por ejemplo, REST .
• Al ser independiente del protocolo, SOAP no puede aprovechar las características y optimizaciones específicas del protocolo, como la interfaz uniforme de REST o el almacenamiento en caché ; en su lugar, tiene que volver a implementarlas (como con WS-Addressing ).

• Benoît Marchal, "Soapbox: ¿Por qué utilizo SOAP?", IBM
• Uche Ogbuji, "Tutorial: mensajería XML con SOAP", consultor principal, Fourthought, Inc.

• Página SOAP del W3C
• Especificación SOAP versión 1.2
• Crear un mensaje SOAP en Java