Tutorial sobre servicios web SOAP: ¿Qué es el protocolo SOAP?

¿Qué es SOAP?

SOAP es un protocolo basado en XML para acceder a servicios web a través de HTTP. Cuenta con algunas especificaciones que pueden utilizarse en diversas aplicaciones.

SOAP se conoce como Protocolo Simple de Acceso a Objetos, pero posteriormente se abrevió a SOAP v1.2. SOAP es un protocolo o, dicho de otro modo, una definición de cómo los servicios web se comunican entre sí o con las aplicaciones cliente que los invocan.

SOAP se desarrolló como un lenguaje intermedio para que las aplicaciones creadas en varios lenguajes de programación pudieran comunicarse fácilmente entre sí y evitar el esfuerzo de desarrollo extremo.

Introducción al jabón

En el mundo actual, existe una gran cantidad de aplicaciones que se desarrollan en diferentes lenguajes de programación. Por ejemplo, podría haber una aplicación web diseñada en Java, otro en .Net y otro en PHP.

El intercambio de datos entre aplicaciones es crucial en el mundo interconectado de hoy. Sin embargo, el intercambio de datos entre estas aplicaciones heterogéneas sería complejo, al igual que lo será la complejidad del código para lograr este intercambio de datos.

Uno de los métodos utilizados para combatir esta complejidad es utilizar XML (Extensible Markup Language) como lenguaje intermedio para intercambiar datos entre aplicaciones.

Todos los lenguajes de programación pueden comprender el lenguaje de marcado XML. Por lo tanto, se utilizó XML como medio subyacente para el intercambio de datos.

Pero no existen especificaciones estándar sobre el uso de XML en todos los lenguajes de programación para el intercambio de datos. Ahí es donde entra en juego el software SOAP.

SOAP fue diseñado para funcionar con XML sobre HTTP y tiene algún tipo de especificación que se puede utilizar en todas las aplicaciones. Analizaremos más detalles sobre el protocolo SOAP en los capítulos siguientes.

Ventajas de SOAP

SOAP es el protocolo utilizado para el intercambio de datos entre aplicaciones. A continuación se detallan algunas de las razones por las que se utiliza SOAP.

• Cuando se desarrollaping Para los servicios web basados ​​en SOAP, se necesita un lenguaje que permita la comunicación entre los servicios web y las aplicaciones cliente. SOAP es el medio ideal, desarrollado para este propósito. Este protocolo también está recomendado por el consorcio W3C, el organismo rector de todos los estándares web.
• SOAP es un protocolo ligero que se utiliza para el intercambio de datos entre aplicaciones. Tenga en cuenta la palabra clave 'lightDado que la programación SOAP se basa en el lenguaje XML, que a su vez es un lenguaje ligero de intercambio de datos, SOAP como protocolo también entra en la misma categoría.
• SOAP está diseñado para ser independiente de la plataforma y también para ser independiente del sistema operativo. Por lo tanto, el protocolo SOAP puede funcionar con cualquier aplicación basada en lenguaje de programación en ambos Windows y Linux plataformas.
• Funciona con el protocolo HTTP. SOAP utiliza el protocolo HTTP, que es el protocolo predeterminado para todas las aplicaciones web. Por lo tanto, no se requiere ninguna personalización para que los servicios web basados ​​en el protocolo SOAP funcionen en la World Wide Web.

Bloques de construcción de jabón

La especificación SOAP define algo conocido como "mensaje SOAP“, que es lo que se envía al servicio web y a la aplicación cliente.

El siguiente diagrama de la arquitectura SOAP muestra los distintos componentes básicos de un mensaje SOAP.

El mensaje SOAP no es más que un simple documento XML que tiene los siguientes componentes.

• An Sobre Elemento que identifica el documento XML como un mensaje SOAP: esta es la parte contenedora del mensaje SOAP y se utiliza para encapsular todos los detalles del mismo. Este es el elemento raíz del mensaje SOAP.
• A Encabezado Elemento que contiene información de encabezado: El elemento de encabezado puede contener información como credenciales de autenticación que puede utilizar la aplicación que realiza la llamada. También puede contener la definición de tipos complejos que podrían utilizarse en el mensaje SOAP. Por defecto, el mensaje SOAP puede contener parámetros que pueden ser de tipos simples, como cadenas y números, pero también pueden ser de un tipo de objeto complejo.

A continuación se muestra un ejemplo sencillo de servicio SOAP de un tipo complejo. Supongamos que quisiéramos enviar un tipo de datos estructurados que tuviera una combinación de un "Nombre del tutorial" y un "Tutorial". Descriptión”, entonces definiríamos el tipo complejo como se muestra a continuación. El tipo complejo se define mediante la etiqueta del elemento Todos los elementos necesarios de la estructura, junto con sus respectivos tipos de datos, se definen en la colección de tipos complejos.

<xsd:complexType>
   <xsd:sequence>
      <xsd:element name="Tutorial Name" type="string"/>
      <xsd:element name="Tutorial Description" type="string"/>
   </xsd:sequence>
</xsd:complexType>

A Carrocería Elemento que contiene información de llamada y respuesta: este elemento es el que contiene los datos reales que deben enviarse entre el servicio web y la aplicación que realiza la llamada. A continuación se muestra un ejemplo de servicio web SOAP del cuerpo SOAP que realmente funciona con el tipo complejo definido en la sección de encabezado. Aquí está la respuesta del Nombre del tutorial y Tutorial Description que se envía a la aplicación de llamada que llama a este servicio web.

<soap:Body>
   <GetTutorialInfo>
      <TutorialName>Web Services</TutorialName>
      <TutorialDescription>All about web services</TutorialDescription>
   </GetTutorialInfo>
</soap:Body>

Estructura del mensaje SOAP

Una cosa a tener en cuenta es que los mensajes SOAP normalmente los genera automáticamente el servicio web cuando se llama.

Cada vez que una aplicación cliente llama a un método en el servicio web, el servicio web generará automáticamente un mensaje SOAP que tendrá los detalles necesarios de los datos que se enviarán desde el servicio web a la aplicación cliente.

Como se explicó en el tema anterior de este tutorial de SOAP, un mensaje SOAP simple tiene los siguientes elementos:

• El elemento envolvente
• El elemento de encabezado y
• El elemento del cuerpo
• El elemento de falla (opcional)

Veamos a continuación un ejemplo de un mensaje SOAP sencillo y analicemos qué hace realmente cada elemento.

1. Como se ve en el mensaje SOAP anterior, la primera parte del mensaje SOAP es el elemento de sobre que se utiliza para encapsular todo el mensaje SOAP.
2. El siguiente elemento es el cuerpo SOAP, que contiene los detalles del mensaje real.
3. Nuestro mensaje contiene un servicio web que tiene el nombre de “Guru99WebService”.
4. El evento "Guru99Webservice” acepta un parámetro de tipo 'int' y tiene el nombre de TutorialID.

Ahora, el mensaje SOAP anterior se pasará entre el servicio web y la aplicación cliente.

Como puede verse, la información anterior resulta muy útil para la aplicación cliente. El mensaje SOAP le indica a la aplicación cliente el nombre del servicio web, los parámetros que espera y el tipo de cada parámetro que recibe el servicio web.

Elemento de sobre SOAP

La primera parte del bloque de construcción es el sobre SOAP.

El sobre SOAP se utiliza para encapsular todos los detalles necesarios de los mensajes SOAP, que se intercambian entre el servicio web y la aplicación cliente.

El elemento de sobre SOAP se utiliza para indicar el principio y el final de un mensaje SOAP. Esto permite que la aplicación cliente que llama al servicio web sepa cuándo finaliza el mensaje SOAP.

Los siguientes puntos se pueden observar en el elemento de sobre SOAP.

• Cada mensaje SOAP debe tener un elemento raíz Envelope. Es absolutamente obligatorio que un mensaje SOAP tenga un elemento envelope.
• Cada elemento de sobre debe tener al menos un elemento de cuerpo de jabón.
• Si un elemento Sobre contiene un elemento de encabezado, no debe contener más de uno y debe aparecer como el primer elemento secundario del Sobre, antes del elemento cuerpo.
• El sobre cambia cuando cambian las versiones de SOAP.
• Un procesador SOAP compatible con v1.1 genera un error al recibir un mensaje que contiene el espacio de nombres del sobre v1.2.
• Un procesador SOAP compatible con v1.2 genera un error de no coincidencia de versión si recibe un mensaje que no incluye el espacio de nombres del sobre v1.2.

A continuación se muestra un ejemplo de la API SOAP de la versión 1.2 del elemento de sobre SOAP.

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
   <soap:Body>
      <Guru99WebService xmlns="http://tempuri.org/">
         <TutorialID>int</TutorialID>
      </Guru99WebService>
   </soap:Body>
</SOAP-ENV:Envelope>

El mensaje de error

Cuando se realiza una solicitud a un servicio web SOAP, la respuesta puede ser de dos tipos: exitosa o de error. Si la solicitud es exitosa, el servidor siempre devuelve un mensaje SOAP. En cambio, si se producen errores SOAP, estos se devuelven como errores HTTP 500.

El mensaje de error SOAP consta de los siguientes elementos.

1. <faultCode> – Este es el código que designa el código del error. El código de error puede ser cualquiera de los siguientes valores:
   1. SOAP-ENV: VersionMismatch: esto ocurre cuando se encuentra un espacio de nombres no válido para el elemento SOAP Sobre.
   2. SOAP-ENV:MustUnderstand: no se entendió un elemento secundario inmediato del elemento Header, con el atributo mustUnderstand establecido en "1".
   3. SOAP-ENV:Cliente: el mensaje tenía un formato incorrecto o contenía información incorrecta.
   4. SOAP-ENV:Servidor: hubo un problema con el servidor, por lo que el mensaje no pudo continuar.
2. – Este es el mensaje de texto que brinda una descripción detallada del error.
3. (Opcional) – Esta es una cadena de texto que indica quién causó la falla.
4. (Opcional) – Este es el elemento para los mensajes de error específicos de la aplicación. Por lo tanto, la aplicación podría tener un mensaje de error específico para diferentes escenarios de lógica empresarial.

Ejemplo de mensaje de error

A continuación se muestra un ejemplo de mensaje de error. Este error se produce cuando el cliente intenta utilizar el método TutorialID de la clase GetTutorial. El mensaje de error que se muestra a continuación se genera si el método no existe en la clase definida.

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
      <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
      <faultstring xsi:type="xsd:string">
         Failed to locate method (GetTutorialID) in class (GetTutorial)
      </faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Salida:

Cuando ejecute el código anterior, mostrará un error como "No se pudo localizar el método (GetTutorialID) en la clase (GetTutorial)".

Modelo de comunicación SOAP

Toda la comunicación mediante SOAP se realiza a través del protocolo HTTP. Antes de SOAP, muchos servicios web utilizó el estilo estándar RPC (llamada a procedimiento remoto) para la comunicación. Este era el tipo de comunicación más simple, pero tenía muchas limitaciones.

Ahora, en este tutorial de la API SOAP, consideremos el siguiente diagrama para ver cómo funciona esta comunicación. En este ejemplo, supongamos que el servidor aloja un servicio web que proporciona dos métodos:

• Obtener empleado – Esto obtendría todos los detalles de los empleados.
• Establecer empleado – Esto establecería el valor de los detalles como el departamento del empleado, el salario, etc., en consecuencia.

En la comunicación normal de estilo RPC, el cliente simplemente llamaría a los métodos en su solicitud y enviaría los parámetros requeridos al servidor, y el servidor luego enviaría la respuesta deseada.

El modelo de comunicación anterior presenta las siguientes limitaciones graves:

1. No es independiente del idioma – El servidor que aloja los métodos estaría escrito en un lenguaje de programación específico, y normalmente las llamadas al servidor se realizarían únicamente en ese lenguaje de programación.
2. No es el protocolo estándar – Cuando se realiza una llamada al procedimiento remoto, la llamada no se realiza mediante el protocolo estándar. Esto era un problema ya que la mayoría de las comunicaciones a través de la web debían realizarse a través del protocolo HTTP.
3. Los cortafuegos – Dado que las llamadas RPC no pasan por el protocolo normal, es necesario abrir puertos separados en el servidor para permitir que el cliente se comunique con el servidor. Normalmente, todos los cortafuegos bloquearían este tipo de tráfico y, por lo general, se requería mucha configuración para garantizar que este tipo de comunicación entre el cliente y el servidor funcionara.

Para superar todas las limitaciones mencionadas anteriormente, SOAP utilizaría el siguiente modelo de comunicación.

1. El cliente formateaba la información relativa a la llamada al procedimiento y cualquier argumento en un mensaje SOAP y lo enviaba al servidor como parte de una solicitud HTTP. Este proceso de encapsular los datos en un mensaje SOAP se conocía como Clasificación.
2. El servidor desenvolvería el mensaje enviado por el cliente, vería lo que el cliente solicitó y luego enviaría la respuesta apropiada de vuelta al cliente como un mensaje SOAP. La práctica de desenvolverping una solicitud enviada por el cliente se conoce como Desembarque.

Ejemplo práctico de SOAP

Ahora en esto SoapUI En este tutorial, veamos un ejemplo práctico de SOAP. Probablemente, una de las mejores maneras de ver cómo se generan los mensajes SOAP es observar un servicio web en funcionamiento.

En este tema se analizará el uso de Microsoft.Net framework para construir un servicio web ASMX. Este tipo de servicio web admite tanto la versión 1.1 como la versión 1.2 de SOAP.

Los servicios web ASMX generan automáticamente el Lenguaje de definición de servicios web (WSDL) documento. La aplicación cliente que realiza la llamada requiere este documento WSDL para que sepa qué es capaz de hacer el servicio web.

En nuestro ejemplo, vamos a crear un servicio web simple, que se utilizará para devolver una cadena a la aplicación que llama al servicio web. Este servicio web estará alojado en un asp.net Aplicación web. Luego invocaremos el servicio web y veremos el resultado que devuelve el servicio web.

Visual Studio también nos mostrará el mensaje SOAP que se transmite entre el servicio web y la aplicación que lo llama. El primer requisito previo para configurar nuestra aplicación de servicio web se puede cumplir siguiendo los pasos que se indican a continuación. Asegúrese de tener Visual Studio 2013 instalado en su sistema para este ejemplo.

Paso 1) El primer paso es crear una aplicación web ASP.Net vacía. Desde Visual Studio 2013, haga clic en la opción de menú Archivo->Nuevo proyecto.

Una vez que haga clic en la opción Nuevo proyecto, Visual Studio le mostrará otro cuadro de diálogo para elegir el tipo de proyecto y proporcionar los detalles necesarios del proyecto. Esto se explica en el siguiente paso.

Paso 2) En este paso,

1. Asegúrese de elegir primero el C# Plantilla web de aplicación web ASP.NET. El proyecto debe ser de este tipo para crear un proyecto de servicios SOAP. Al seleccionar esta opción, Visual Studio realizará los pasos necesarios para agregar los archivos requeridos por cualquier aplicación web.
2. Asigna un nombre a tu proyecto; en nuestro caso, se llama webservice.asmx. Luego, asegúrate de especificar la ubicación donde se almacenarán los archivos del proyecto.

Una vez finalizado el proceso, verá el archivo del proyecto creado en el explorador de soluciones de Visual Studio 2013.

Paso 3) En este paso, vamos a agregar un archivo de servicio web a nuestro proyecto.

1. Primero, haga clic con el botón derecho en el archivo del proyecto, como se muestra a continuación.

2. Una vez que haga clic con el botón derecho en el archivo del proyecto, tendrá la opción de seleccionar "Agregar -> Servicio web (ASMX)" para añadir un archivo de servicio web. Simplemente indique "Servicio de tutorial" como nombre del archivo de servicio web.

Paso 4) Agregue el siguiente código a su archivo asmx del Servicio Tutorial.

Code Explicación:

1. Esta línea de código proporciona un nombre para su archivo de servicio web. Este es un paso importante porque permite que la aplicación cliente llame al servicio web mediante el nombre del servicio web.
2. Normalmente se utiliza un archivo de clase para encapsular la funcionalidad de un servicio web. Entonces, el archivo de clase tendrá la definición de todos los métodos web que proporcionarán alguna funcionalidad a la aplicación cliente.
3. Aquí [WebMethod] se conoce como un atributo que describe una función. El paso subsiguiente crea una función llamada “Guru99WebService”, pero con la inclusión de este paso de agregar un atributo [WebMethod], se asegura que este método pueda ser invocado por una aplicación cliente. Si este atributo no está presente, entonces el método nunca podrá ser llamado por una aplicación cliente.
4. Aquí estamos definiendo una función llamada 'Guru'99WebService', que se utilizará para devolver una cadena a la aplicación cliente que la invoque. Esta función es un servicio web al que puede llamar cualquier aplicación cliente.
5. Estamos utilizando la instrucción return para devolver la cadena “This is a Guru99 Servicio web” a la aplicación cliente.

Si el código se ejecuta correctamente, se mostrará la siguiente salida cuando ejecute el código en el navegador.

Salida:

• La salida muestra claramente que el nombre de nuestro servicio web es “Guru99 Servicio Web”, que es el resultado de darle un nombre a nuestro servicio web.
• También podemos observar que podemos invocar el servicio web. Si hacemos clic en el botón Invocar, obtendremos la siguiente respuesta en el navegador web.

El resultado anterior:

• Muestra claramente que al invocar el método web, la cadena “This is a GuruSe devuelve "Servicio web 99".
• Visual Studio también le permite ver la solicitud y la respuesta del mensaje SOAP que se genera cuando se llama al servicio web mencionado anteriormente.

La solicitud SOAP que se genera cuando se llama al servicio web se muestra a continuación.

Code Explicación:

1. La primera parte del mensaje SOAP es el elemento de envoltura, que se trató en capítulos anteriores. Este es el elemento de encapsulación que está presente en todos los mensajes SOAP.
2. El cuerpo SOAP es el siguiente elemento y contiene los detalles reales del mensaje SOAP.
3. La tercera parte es el elemento que especifica que queremos llamar al servicio que se llama 'Guru99ServicioWeb'.

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soap:Body>
      <Guru99WebServiceResponse xmlns="http://tempuri.org/">
         <Guru99WebServiceResult>string</Guru99WebServiceResult>
      </Guru99WebServiceResponse>
   </soap:Body>
</soap:Envelope>

Code Explicación:

1. La primera parte del mensaje SOAP es el elemento de envoltura, que se trató en capítulos anteriores. Este es el elemento de encapsulación que está presente en todos los mensajes SOAP.
2. El cuerpo SOAP es el siguiente elemento y contiene los detalles reales del mensaje SOAP.
3. Lo interesante que verás ahora es el atributo 'string'. Este atributo le indica a la aplicación cliente que el servicio web al que se llama devuelve un objeto de tipo cadena. Esto es muy útil, ya que de lo contrario la aplicación cliente no sabría qué devuelve el servicio web.

Preguntas Frecuentes