Servicio web de jabón. Protocolo simple de acceso a objetos (SOAP): descripción general. ¿Cuáles son las ventajas de todas estas campanas y silbatos?
- Tutorial
¡Hola a todos!
Dio la casualidad de que recientemente comencé a desarrollar servicios web. Pero hoy el tema no es sobre mí, sino sobre cómo podemos escribir nuestro propio servicio web XML basado en el protocolo SOAP 1.2.
Espero que después de leer el tema puedas:
- escribir su propia implementación de servidor de una aplicación web;
- escribir su propia implementación cliente de una aplicación web;
- escriba su propia descripción del servicio web (WSDL);
- enviar las matrices del cliente del mismo tipo de datos al servidor.
1 planteamiento del problema
1.1 Límites
Al principio propongo abordar el resultado que lograremos al final del tema. Como se anunció anteriormente, escribiremos un servicio para enviar mensajes SMS y, más precisamente, recibiremos mensajes de diferentes fuentes mediante protocolo SOAP. Después de eso, consideraremos en qué forma llegan al servidor. Desafortunadamente, el proceso de poner en cola los mensajes para su posterior envío al proveedor está más allá del alcance de esta publicación por muchas razones.
1.2 ¿Qué datos cambiaremos?
¡Genial, hemos decidido los límites! El siguiente paso que hay que dar es decidir qué datos intercambiaremos entre el servidor y el cliente. Sobre este tema, le sugiero no dividirse por mucho tiempo y responder de inmediato las preguntas principales usted mismo:- ¿Qué datos mínimos se deben enviar al servidor para poder enviar un mensaje SMS a un suscriptor?
- ¿Qué datos mínimos se deben enviar desde el servidor para satisfacer las necesidades del cliente?
- número de teléfono móvil y
- texto del mensaje SMS.
- fecha de envío del mensaje SMS.
- Tipo de mensaje.
¡Y sin embargo, olvidé algo! Si reflexionamos un poco más, cabe destacar que el cliente puede enviar al servidor un mensaje SMS o varios a la vez. En otras palabras, un paquete de datos puede contener desde uno hasta infinitos mensajes.
Como resultado, obtenemos que para enviar un mensaje SMS necesitamos los siguientes datos:
- número de teléfono móvil,
- texto de mensaje SMS,
- momento de envío del mensaje SMS al suscriptor,
- tipo de mensaje.
Hemos respondido la primera pregunta, ahora necesitamos responder la segunda pregunta. Y tal vez me permitiré perder el tiempo un poco. Por tanto, desde el servidor enviaremos únicamente datos booleanos, cuyo significado tiene el siguiente significado:
- VERDADERO: el paquete llegó exitosamente al servidor, pasó la autenticación y se puso en cola para enviarlo al proveedor de SMS.
- FALSO – en todos los demás casos
¡Con esto concluye la descripción del planteamiento del problema! Y finalmente, vayamos a la parte divertida: ¡descubramos qué clase de bestia extraña es este SOAP!
2 ¿Qué es el jabón?
En general, inicialmente no planeé escribir nada sobre qué es SOAP y quería limitarme a enlaces al sitio web w3.org con las especificaciones necesarias, así como enlaces a Wikipedia. Pero al final decidí escribir una breve nota sobre este protocolo.Y comenzaré mi historia con el hecho de que este protocolo de intercambio de datos pertenece a un subconjunto de protocolos basados en el llamado paradigma RPC (Llamada a procedimiento remoto), cuya antípoda es REST (Transferencia de estado representacional). Puede leer más sobre esto en Wikipedia; los enlaces a los artículos se encuentran al final del tema. De estos artículos debemos entender lo siguiente: “El enfoque RPC le permite utilizar una pequeña cantidad de recursos de red con una gran cantidad de métodos y un protocolo complejo. Con el enfoque REST, la cantidad de métodos y la complejidad del protocolo están estrictamente limitadas, lo que significa que la cantidad de recursos individuales puede ser grande”. Es decir, en relación con nosotros, esto significa que en el caso del enfoque RPC en el sitio siempre habrá una entrada (enlace) al servicio y qué procedimiento llamar para procesar los datos entrantes que transferimos junto con los datos, mientras con el enfoque REST en nuestro El sitio tiene muchas entradas (enlaces), cada una de las cuales acepta y procesa solo ciertos datos. Si alguien que lea sabe cómo explicar la diferencia entre estos enfoques de manera aún más simple, ¡asegúrese de escribir en los comentarios!
Lo siguiente que debemos saber sobre SOAP es que este protocolo utiliza el mismo XML como transporte, lo cual por un lado es muy bueno, porque inmediatamente nuestro arsenal recibe todo el poder de una pila de tecnologías basadas en idioma dado marcado, a saber, XML-Schema, un lenguaje para describir la estructura de un documento XML (¡gracias Wikipedia!), que permite la validación automática de los datos recibidos por el servidor de los clientes.
¡Y ahora sabemos que SOAP es un protocolo utilizado para implementar llamadas a procedimientos remotos y utiliza XML como transporte! Si lee el artículo en Wikipedia, también podrá aprender desde allí que se puede utilizar además de cualquier protocolo. nivel de aplicación, y no solo emparejado con HTTP (desafortunadamente, en este tema solo consideraremos SOAP sobre HTTP). ¿Y sabes qué es lo que más me gusta de todo esto? Si no hay conjeturas, entonces te daré una pista: ¡JABÓN!... ¿Todavía no hay conjeturas?... ¿Estás seguro de que leíste el artículo en Wikipedia?... En general, no te torturaré más. Por lo tanto, iré directamente a la respuesta: "SOAP (del protocolo de acceso a objetos simple en inglés - simple protocolo acceso a objetos; hasta la especificación 1.2)". ¡Lo más destacable de esta línea está en cursiva! No sé qué conclusiones sacó de todo esto, pero veo lo siguiente: dado que este protocolo no puede llamarse "simple" de ninguna manera (y aparentemente incluso w3 está de acuerdo con esto), desde la versión 1.2 dejó de descifrarse de alguna manera ! Y pasó a ser conocido como SOAP, simplemente SOAP, punto.
Bueno, está bien, discúlpenme, me desvié un poco. Como escribí anteriormente, XML se utiliza como transporte y los paquetes que viajan entre el cliente y el servidor se denominan sobres SOAP. Si consideras la estructura general del sobre, te resultará muy familiar, porque... Se asemeja a la estructura de una página HTML. Tiene una sección principal - Envolver, que incluye secciones Encabezamiento Y Cuerpo, o Falla. EN Cuerpo se transmiten datos y es una sección obligatoria del sobre, mientras que Encabezamiento es opcional. EN Encabezamiento Se podrá transmitir autorización o cualquier otro dato que no esté directamente relacionado con los datos de entrada de los procedimientos del servicio web. Acerca de Falla no hay nada especial que decir, excepto que llega al cliente desde el servidor en caso de algún error. 
Aquí termina mi historia de revisión sobre el protocolo SOAP (veremos los sobres en sí y su estructura con más detalle cuando nuestro cliente y servidor finalmente aprendan a ejecutarlos entre sí) y comienza una nueva: sobre el compañero SOAP llamado WSDL (Servicios web Idioma de descripción). Sí, sí, esto es precisamente lo que nos asusta a la mayoría de nosotros incluso de intentar implementar nuestra API en este protocolo. Como resultado, normalmente reinventamos nuestra rueda con JSON como transporte. Entonces, ¿qué es WSDL? WSDL es un lenguaje para describir servicios web y acceder a ellos, basado en el lenguaje XML (c) Wikipedia. Si esta definición no le aclara todo el significado sagrado de esta tecnología, ¡intentaré describirlo con mis propias palabras!
WSDL está diseñado para permitir a nuestros clientes comunicarse normalmente con el servidor. Para ello, el archivo con extensión “*.wsdl” describe la siguiente información:
- ¿Qué espacios de nombres se utilizaron?
- ¿Qué esquemas de datos se utilizaron?
- ¿Qué tipos de mensajes espera el servicio web de los clientes?
- Qué datos pertenecen a qué procedimientos de servicios web,
- ¿Qué trámites contiene el servicio web?
- ¿Cómo debe el cliente llamar a los procedimientos del servicio web?
- ¿A qué dirección se deben enviar las llamadas de los clientes?
3 Introducción al esquema XML
Ahora sabemos mucho sobre qué es SOAP, qué contiene y tenemos una descripción general de la pila de tecnología que lo rodea. Dado que, en primer lugar, SOAP es una forma de interacción entre un cliente y un servidor, y el lenguaje de marcado XML se utiliza como transporte para ello, luego en esta sección Analizaremos un poco cómo se produce la validación automática de datos utilizando esquemas XML.El objetivo principal del diagrama es describir la estructura de los datos que vamos a procesar. Todos los datos en esquemas XML se dividen en simple(escalar) y complejo(estructuras) tipos. Los tipos simples incluyen los siguientes tipos:
- línea,
- número,
- valor booleano,
- fecha.
¡Sugiero no ir muy lejos y escribir un esquema XML para nuestro mensaje SMS! A continuación se muestra la descripción xml del mensaje SMS:
Nuestro diagrama de tipo complejo se verá así:
Esta entrada dice lo siguiente: Tenemos una variable " mensaje" tipo " Mensaje"y hay un tipo complejo llamado" Mensaje", que consta de un conjunto secuencial de elementos " teléfono" tipo cadena, « texto" tipo cadena, « fecha" tipo fechahora, « tipo" tipo decimal. Estos tipos son simples y ya están definidos en la descripción del esquema. ¡Felicidades! ¡Acabamos de escribir nuestro primer esquema XML!
Creo que el significado de los elementos " elemento" Y " tipo complejo"Todo te ha quedado más o menos claro, así que no nos centraremos más en ello y pasemos directamente al elemento compositor" secuencia" Cuando usamos el elemento compositor " secuencia“Les informamos que los elementos incluidos en el mismo deben ubicarse siempre en la secuencia especificada en el esquema, y todos ellos son de obligado cumplimiento. ¡Pero no te desesperes! Hay dos elementos más del compositor en los esquemas XML: " elección" Y " todo" Compositor " elección" anuncia que debe haber uno de los elementos enumerados en él, y el compositor " todo» – cualquier combinación de los elementos enumerados.
Como recordarás, en el primer apartado del tema coincidimos en que en un paquete se pueden transmitir de uno a infinito mensajes SMS. Por lo tanto, propongo comprender cómo se declaran dichos datos en el esquema XML. Estructura general El paquete podría verse así:
El diagrama para un tipo tan complejo se verá así:
El primer bloque contiene la conocida declaración del tipo complejo “ Mensaje" Si te diste cuenta, entonces en cada tipo simple incluido en " Mensaje", se han agregado nuevos atributos aclaratorios " minOcurre" Y " maxOcurre" Como puedes adivinar por el nombre, el primero ( minOcurre) indica que esta secuencia debe contener al menos un elemento de tipo " teléfono», « texto», « fecha" Y " tipo", mientras que el siguiente ( maxOcurre) el atributo nos declara que hay como máximo uno de esos elementos en nuestra secuencia. Como resultado, cuando escribimos nuestros propios esquemas para cualquier dato, ¡tenemos la opción más amplia sobre cómo configurarlos!
El segundo bloque del diagrama declara el elemento " lista de mensajes" tipo " Lista de mensajes" Está claro que " Lista de mensajes"es un tipo complejo que contiene al menos un elemento" mensaje", ¡pero el número máximo de dichos elementos no está limitado!
4 Escribe tu WSDL
¿Recuerdas que WSDL es nuestro servicio web? ¡Espero que lo recuerdes! Mientras lo escribimos, nuestro pequeño servicio web se ejecutará en él. Por lo tanto, sugiero no perder el tiempo.En general, para que todo nos funcione correctamente, necesitamos transferir el archivo WSDL con el tipo MIME correcto al cliente. Para hacer esto, necesita configurar su servidor web en consecuencia, es decir, establecer el tipo MIME para archivos con la extensión “*.wsdl” en la siguiente línea:
Aplicación/wsdl+xml
Pero en la práctica, normalmente envié el encabezado HTTP a través de PHP " texto/xml»:
Encabezado("Tipo de contenido: texto/xml; charset=utf-8");
¡Y todo funcionó muy bien!
Quiero advertirles de inmediato que nuestro sencillo servicio web tendrá una descripción bastante impresionante, así que no se alarmen, porque... mayoría El texto es obligatorio y, habiéndolo escrito una vez, ¡puedes copiarlo constantemente de un servicio web a otro!
Dado que WSDL es XML, debe escribir sobre esto directamente en la primera línea. El elemento raíz del archivo siempre debe llamarse " definiciones»:
Normalmente, WSDL consta de 4 o 5 bloques principales. El primer bloque es la definición de un servicio web o, en otras palabras, el punto de entrada.
Aquí dice que tenemos un servicio llamado - " Servicio SMS" En principio, usted puede cambiar todos los nombres del archivo WSDL por el que desee, porque no juegan absolutamente ningún papel.
Luego de esto anunciamos que en nuestro servicio web " Servicio SMS"hay un punto de entrada ("puerto") llamado " PuertoServicioSms" Es a este punto de entrada al que se enviarán todas las solicitudes de los clientes al servidor. E indicar en el elemento “ DIRECCIÓN» enlace al archivo del controlador que aceptará solicitudes.
Una vez que hayamos definido el servicio web y especificado el punto de entrada, debemos vincularle los procedimientos admitidos:
Para ello, enumera qué operaciones y de qué forma se llamarán. Aquellos. para puerto " PuertoServicioSms"un enlace se define bajo el nombre" Enlace de servicio SMS", que tiene un tipo de llamada " rpc"y HTTP se utiliza como protocolo de transferencia. Por lo tanto, indicamos aquí que realizaremos una llamada RPC a través de HTTP. Después de esto describimos qué procedimientos ( operación) son compatibles con el servicio web. Apoyaremos sólo un procedimiento – “ enviarSms" ¡A través de este procedimiento nuestros maravillosos mensajes serán enviados al servidor! Una vez declarado el procedimiento, es necesario indicar en qué forma se transmitirán los datos. EN en este caso se especifica que se utilizarán sobres SOAP estándar.
Después de eso, necesitamos vincular el procedimiento a los mensajes:
Para ello especificamos que nuestro enlace es de tipo " Tipo de puerto de servicio SMS" y en el elemento " tipo de puerto"con el nombre del mismo tipo indicamos la vinculación de procedimientos a mensajes. Entonces, mensaje entrante(del cliente al servidor) se llamará " enviarSmsSolicitud", y saliente (del servidor al cliente) " enviarSmsRespuesta" Como todos los nombres en WSDL, los nombres de los mensajes entrantes y salientes son arbitrarios.
Ahora necesitamos describir los mensajes en sí, es decir. entrantes y salientes:
Para ello añadimos los elementos " mensaje"con nombres" enviarSmsSolicitud" Y " enviarSmsRespuesta" respectivamente. En ellos indicamos que la entrada debe ser un sobre cuya estructura corresponda al tipo de datos " Pedido" Después de lo cual se devuelve un sobre del servidor que contiene el tipo de datos - " Respuesta».
Ahora tenemos que hacer un poco: ¡agregar una descripción de estos tipos a nuestro archivo WSDL! ¿Y cómo cree que describe el WSDL los datos entrantes y salientes? Creo que ya entendiste todo hace mucho tiempo y te dijiste que usar esquemas XML. ¡Y tendrás toda la razón!
¡Puedes felicitarnos! ¡Nuestro primer WSDL ha sido escrito! Y estamos un paso más cerca de lograr nuestro objetivo.
A continuación, veremos qué nos proporciona PHP para desarrollar nuestras propias aplicaciones distribuidas.
5 Nuestro primer servidor SOAP
Anteriormente escribí que para crear un servidor SOAP en PHP usaremos la clase integrada SoapServer. Para que todo acciones adicionales sucedió de la misma manera que el mío, necesitarás modificar un poco tu PHP. Para ser aún más preciso, debes asegurarte de tener instalada la extensión “php-soap”. Lo mejor es leer cómo instalarlo en su servidor web en el sitio web oficial de PHP (consulte la lista de referencias).Una vez instalado y configurado todo, necesitaremos crear un archivo en la carpeta raíz de tu hosting” serviciosms.php» con el siguiente contenido:
setClass("SoapSmsGateWay"); //Inicia el servidor $server->handle();
Espero que no sea necesario explicar qué hay encima de la línea con la función “ini_set”. Porque allí se determina qué encabezados HTTP enviaremos desde el servidor al cliente y se configura el entorno. En la línea con "ini_set" desactivamos el almacenamiento en caché del archivo WSDL para que nuestros cambios surtan efecto inmediatamente en el cliente.
¡Ahora llegamos al servidor! Como puede ver, ¡todo el servidor SOAP solo ocupa tres líneas! En la primera línea, creamos una nueva instancia del objeto SoapServer y pasamos la dirección de nuestra descripción WSDL del servicio web a su constructor. Ahora sabemos que estará ubicado en la raíz del hosting en un archivo con el nombre autoexplicativo “ smsservice.wsdl.php" En la segunda línea, le indicamos al servidor SOAP qué clase se debe extraer para procesar el sobre recibido del cliente y devolver el sobre con la respuesta. Como habrás adivinado, es en esta clase donde se describirá nuestro único método. enviarSms. ¡En la tercera línea iniciamos el servidor! ¡Eso es todo, nuestro servidor está listo! ¡Con lo cual nos felicito a todos!
Ahora necesitamos crear el archivo WSDL. Para hacer esto, puedes simplemente copiar su contenido de la sección anterior, o tomarte la libertad y “plantillarlo” un poco:
";
?>
En esta etapa, deberíamos estar completamente satisfechos con el servidor resultante, porque Podemos registrar los sobres que llegan y luego analizar con calma los datos entrantes. Para que podamos recibir algo en el servidor, necesitamos un cliente. ¡Así que vamos a ello!
6 clientes SOAP en camino
En primer lugar, necesitamos crear un archivo en el que escribiremos el cliente. Como es habitual, lo crearemos en la raíz del host y lo llamaremos " cliente.php", y dentro escribiremos lo siguiente: lista de mensajes = nueva lista de mensajes(); $req->listademensajes->mensaje = nuevo mensaje(); $req->listademensajes->mensaje->teléfono = "79871234567"; $req->messageList->message->text = "Mensaje de prueba 1"; $req->listademensajes->mensaje->fecha = "2013-07-21T15:00:00.26"; $req->listademensajes->mensaje->tipo = 15; $cliente = nuevo SoapClient("http://($_SERVER["HTTP_HOST"])/smsservice.wsdl.php", array("soap_version" => SOAP_1_2)); var_dump($cliente->sendSms($req));
Describamos nuestros objetos. Cuando escribimos el WSDL, describía tres entidades para el sobre entrante al servidor: Pedido, Lista de mensajes Y Mensaje. En consecuencia clases Pedido, Lista de mensajes Y Mensaje son reflejos de estas entidades en nuestro script PHP.
Una vez que hemos definido los objetos, necesitamos crear un objeto ( $requisito), que enviaremos al servidor. ¡Después vienen las dos líneas más queridas para nosotros! ¡Nuestro cliente SOAP! Lo creas o no, esto es suficiente para que nuestro servidor comience a recibir mensajes del cliente, ¡así como para que nuestro servidor los reciba y procese con éxito! En el primero de ellos creamos una instancia de la clase SoapClient y pasamos la dirección de ubicación del archivo WSDL a su constructor, y en los parámetros indicamos explícitamente que trabajaremos utilizando el protocolo SOAP versión 1.2. En la siguiente línea llamamos al método. enviarSms objeto $cliente e inmediatamente mostrar el resultado en el navegador.
¡Ejecutémoslo y veamos qué obtuvimos finalmente!
El siguiente objeto me fue devuelto desde el servidor:
Objeto (stdClass) público "estado" => booleano verdadero
Y esto es genial, porque... ¡Ahora sabemos con certeza que nuestro servidor está funcionando y no solo funciona, sino que también puede devolver algunos valores al cliente!
¡Ahora veamos el registro que mantenemos prudentemente en el lado del servidor! En su primera parte vemos los datos brutos que llegaron al servidor:
Este es el sobre. ¡Ahora ya sabes cómo luce! Pero es poco probable que estemos interesados en verlo todo el tiempo, así que deserialicemos el objeto del archivo de registro y veamos si todo está bien:
Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "phone" => string "79871234567" (longitud=11) public "text" => string "Mensaje de prueba 1 " (longitud=37) public "fecha" => cadena "2013-07-21T15:00:00.26" (longitud=22) public "tipo" => cadena "15" (longitud=2)
Como puede ver, el objeto se deserializa correctamente, ¡por lo que quiero felicitarnos a todos! ¡A continuación nos espera algo más interesante! Es decir, enviaremos al cliente al servidor no solo un mensaje SMS, ¡sino un paquete completo (para ser más precisos, tres)!
7 Envío de objetos complejos
Pensemos en cómo podemos transferir una gran cantidad de mensajes al servidor en un solo paquete. Probablemente el más de una manera sencilla¡Habrá una organización de matriz dentro del elemento messageList! Hagamos esto:// crea un objeto para enviar al servidor $req = new Request(); $req->listademensajes = nueva Lista de mensajes(); $msg1 = nuevo mensaje(); $msg1->teléfono = "79871234567"; $msg1->text = "Mensaje de prueba 1"; $msg1->fecha = "2013-07-21T15:00:00.26"; $msj1->tipo = 15; $msg2 = nuevo mensaje(); $msg2->teléfono = "79871234567"; $msg2->text = "Mensaje de prueba 2"; $msg2->fecha = "2014-08-22T16:01:10"; $msg2->tipo = 16; $msg3 = nuevo mensaje(); $msg3->teléfono = "79871234567"; $msg3->text = "Mensaje de prueba 3"; $msg3->fecha = "2014-08-22T16:01:10"; $msg3->tipo = 17; $req->listademensajes->mensaje = $msg1; $req->listademensajes->mensaje = $msg2; $req->listademensajes->mensaje = $msg3;
Nuestros registros indican que se recibió el siguiente paquete del cliente:
¿Qué tontería dices? Y en cierto sentido tendrás razón, porque... Tan pronto como supimos que un objeto salió del cliente, llegó a nuestro servidor absolutamente de la misma forma, en forma de sobre. Es cierto que los mensajes SMS no se serializaron en XML de la forma que necesitábamos: tuvieron que encapsularse en elementos. mensaje, no en estructura. Ahora veamos en qué forma dicho objeto llega al método. enviarSms:
Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "Struct" => matriz (tamaño=3) 0 => object(stdClass) public "phone" => cadena "79871234567" (longitud=11) public "text" => string "Mensaje de prueba 1" (longitud=37) public "date" => string "2013-07-21T15:00:00.26" (longitud=22) public " tipo" => cadena "15" (longitud=2) 1 => objeto(stdClass) public "phone" => cadena "79871234567" (longitud=11) public "text" => cadena "Mensaje de prueba 2" (longitud= 37) pública "fecha" => cadena "2014-08-22T16:01:10" (longitud=19) public "tipo" => cadena "16" (longitud=2) 2 => objeto(stdClass) public "teléfono " => cadena "79871234567" (longitud=11) public "texto" => cadena "Mensaje de prueba 3" (longitud=37) public "fecha" => cadena "2014-08-22T16:01:10" (longitud= 19) público "tipo" => cadena "17" (longitud=2)
¿Qué nos aporta este conocimiento? Solo que la ruta que hemos elegido no es correcta y no hemos recibido respuesta a la pregunta: “¿Cómo podemos acceder al servidor? estructura correcta¿datos? Pero sugiero no desesperarse e intentar convertir nuestra matriz al tipo objeto:
$req->listademensajes->mensaje = (objeto)$req->lista de mensajes->mensaje;
En este caso recibiremos otro sobre:
Entró en el método enviarSms el objeto tiene la siguiente estructura:
Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "BOGUS" => matriz (tamaño=3) 0 => object(stdClass) public "phone" => cadena "79871234567" (longitud=11) public "text" => string "Mensaje de prueba 1" (longitud=37) public "date" => string "2013-07-21T15:00:00.26" (longitud=22) public " tipo" => cadena "15" (longitud=2) 1 => objeto(stdClass) public "phone" => cadena "79871234567" (longitud=11) public "text" => cadena "Mensaje de prueba 2" (longitud= 37) pública "fecha" => cadena "2014-08-22T16:01:10" (longitud=19) public "tipo" => cadena "16" (longitud=2) 2 => objeto(stdClass) public "teléfono " => cadena "79871234567" (longitud=11) public "text" => cadena "Mensaje de prueba 3" (longitud=37) public "fecha" => cadena "2014-08-22T16:01:10" (longitud= 19) público "tipo" => cadena "17" (longitud=2)
En lo que a mí respecta, “la suma no cambia al cambiar los lugares de los términos” (c). Qué FALSO, Qué estructura– ¡aún no hemos logrado nuestro objetivo! Y para lograrlo, debemos asegurarnos de que en lugar de estos nombres incomprensibles se muestre nuestro nativo. mensaje. Pero el autor aún no sabe cómo lograrlo. Por tanto, lo único que podemos hacer es deshacernos del contenedor extra. En otras palabras, ahora nos aseguraremos de que, en lugar de mensaje convertirse FALSO! Para hacer esto, cambie el objeto de la siguiente manera:
// crea un objeto para enviar al servidor $req = new Request(); $msg1 = nuevo mensaje(); $msg1->teléfono = "79871234567"; $msg1->text = "Mensaje de prueba 1"; $msg1->fecha = "2013-07-21T15:00:00.26"; $msj1->tipo = 15; $msg2 = nuevo mensaje(); $msg2->teléfono = "79871234567"; $msg2->text = "Mensaje de prueba 2"; $msg2->fecha = "2014-08-22T16:01:10"; $msg2->tipo = 16; $msg3 = nuevo mensaje(); $msg3->teléfono = "79871234567"; $msg3->text = "Mensaje de prueba 3"; $msg3->fecha = "2014-08-22T16:01:10"; $msg3->tipo = 17; $req->listademensajes = $msg1; $req->listademensajes = $msg2; $req->listademensajes = $msg3; $req->listademensajes = (objeto)$req->lista de mensajes;
¿Qué pasa si tenemos suerte y aparece el nombre correcto en el diagrama? Para ello, veamos el sobre que llegó:
¡Sí, no ocurrió un milagro! FALSO– ¡No ganaremos! vino a enviarSms el objeto en este caso se verá así:
Object(stdClass) public "messageList" => object(stdClass) public "BOGUS" => matriz (tamaño=3) 0 => object(stdClass) public "phone" => cadena "79871234567" (longitud=11) public " texto" => cadena "Mensaje de prueba 1" (longitud=37) public "fecha" => cadena "2013-07-21T15:00:00.26" (longitud=22) public "tipo" => cadena "15" (longitud =2) 1 => object(stdClass) public "phone" => string "79871234567" (longitud=11) public "text" => string "Mensaje de prueba 2" (longitud=37) public "date" => string " 2014-08-22T16:01:10" (longitud=19) public "tipo" => cadena "16" (longitud=2) 2 => objeto(stdClass) public "phone" => cadena "79871234567" (longitud= 11) público "texto" => cadena "Mensaje de prueba 3" (longitud = 37) público "fecha" => cadena "2014-08-22T16:01:10" (longitud = 19) público "tipo" => cadena " 17" (largo=2)
Como dicen – ¡“Casi”! En esta nota (un poco triste), propongo resumir lentamente las cosas y sacar algunas conclusiones por nosotros mismos.
8 Conclusión
¡Finalmente llegamos aquí! Averigüemos qué puedes hacer ahora:- puedes escribir el archivo WSDL necesario para tu servicio web;
- puedes escribir fácilmente tu propio cliente que pueda comunicarse con el servidor vía SOAP;
- puedes escribir el tuyo propio servidor propio comunicarse con el mundo exterior a través de SOAP;
- puedes enviar matrices objetos del mismo tipo al servidor desde su cliente (con algunas restricciones).
- la clase nativa SoapClient no serializa correctamente estructuras de datos del mismo tipo en XML;
- al serializar una matriz a XML se crea elemento extra con nombre estructura;
- al serializar un objeto a XML, se crea un elemento adicional llamado FALSO;
- FALSO mal menor cómo estructura debido al hecho de que el sobre es más compacto (no se agregan espacios de nombres adicionales al encabezado XML del sobre);
- Desafortunadamente, la clase SoapServer no valida automáticamente los datos del sobre con nuestro esquema XML (quizás otros servidores tampoco lo hagan).
Parte lírica.
Imagine que ha implementado o está implementando un determinado sistema al que debería ser accesible desde el exterior. Aquellos. hay un determinado servidor con el que necesita comunicarse. Por ejemplo un servidor web.
Este servidor puede realizar muchas acciones, trabajar con la base de datos, realizar algunas solicitudes de terceros a otros servidores, hacer algunos cálculos, etc. vivir y posiblemente desarrollarse según el escenario que conoce (es decir, según el escenario de los desarrolladores). No es interesante para una persona comunicarse con un servidor de este tipo, porque es posible que no pueda o no quiera proporcionar páginas hermosas con imágenes y otros contenidos fáciles de usar. Está escrito y funciona para funcionar y proporcionar datos cuando se le solicite, sin preocuparse de que sea legible por humanos, el cliente se encargará de ello él mismo.
Otros sistemas, al acceder a este servidor, ya pueden disponer de los datos recibidos de este servidor a su propia discreción: procesarlos, acumularlos, emitirlos a sus clientes, etc.
Bueno, una de las opciones para comunicarse con dichos servidores es SOAP. Protocolo de intercambio de mensajes SOAP xml.
Parte práctica.
Un servicio web (así se llama lo que proporciona el servidor y lo que utilizan los clientes) permite comunicarse con el servidor con mensajes claramente estructurados. El caso es que el servicio web no acepta ningún dato. El servicio web responderá con un error ante cualquier mensaje que no cumpla las normas. Por cierto, el error también estará en formulario xml con una estructura clara (lo que no se puede decir del texto del mensaje).
WSDL (lenguaje de descripción de servicios web). Las reglas mediante las cuales se componen los mensajes para el servicio web también se describen mediante xml y también tienen una estructura clara. Aquellos. Si un servicio web ofrece la posibilidad de llamar a un método, debe permitir a los clientes saber qué parámetros se utilizan para este método. Si el servicio web espera una cadena para el Método1 como parámetro y la cadena debe denominarse Param1, entonces estas reglas se especificarán en la descripción del servicio web.
No solo se pueden pasar parámetros tipos simples, pero también objetos, colecciones de objetos. La descripción de un objeto se reduce a una descripción de cada componente del objeto. Si un objeto consta de varios campos, entonces se describe cada campo, su tipo, nombre (qué valores posibles). Los campos también pueden ser de tipo complejo, y así sucesivamente hasta que la descripción de los tipos termine con campos simples: cadena, booleano, número, fecha... Sin embargo, algunos tipos específicos pueden resultar simples, es importante que los clientes puede entender qué valores pueden contener.
Para los clientes basta con conocer la URL del servicio web, siempre estará cerca el wsdl, del cual se pueden hacer una idea de los métodos y sus parámetros que proporciona este servicio web.
¿Cuáles son las ventajas de todas estas campanas y silbatos?
- En la mayoría de los sistemas, los métodos y tipos se describen en modo automático. Aquellos. basta con que el programador del servidor diga que este método Se puede llamar a través de un servicio web y la descripción wsdl se generará automáticamente.
Validación automática.
- validación xml. xml debe estar bien formado. XML no válido: inmediatamente un error para el cliente, déjelo solucionarlo.
- validación de esquema. xml debe tener una estructura determinada. xml no coincide con el esquema; inmediatamente aparece un error para el cliente, déjelo solucionarlo.
- El servidor SOAP lleva a cabo la verificación de datos para que los tipos de datos y las restricciones coincidan con la descripción.
- La autorización y la autenticación se pueden implementar mediante un método independiente. de forma nativa. o utilizando autorización http.
- Los servicios web pueden funcionar tanto a través del protocolo SOAP como a través de http, es decir, a través de solicitudes de obtención. Es decir, si los parámetros son datos simples (sin estructura), simplemente puede llamar al get www.site.com/users.asmx/GetUser?Name=Vasia o publicarlo de forma habitual. Sin embargo, esto no ocurre en todas partes ni siempre.
- ... ver en Wikipedia
La descripción, que tiene una estructura clara, es legible por cualquier cliente de jabón. Aquellos. Sea cual sea el servicio web, el cliente entenderá qué datos recibe el servicio web. A partir de esta descripción, el cliente puede construir su propio estructura interna clases de objetos, los llamados. vinculante" y. Como resultado, el programador que utiliza el servicio web tiene que escribir algo como (pseudocódigo):
NuevoUsuario:=TSoapUser.Create("Vasya","Pupkin","admin"); jabón.AddUser(NuevoUsuario);
También hay muchas desventajas:
- injustificadamente gran tamaño mensajes. Bueno, aquí la naturaleza misma de xml es tal que el formato es redundante, cuantas más etiquetas, más información inútil. Además, el jabón añade su redundancia. Para los sistemas de intranet, el problema del tráfico es menos grave que para Internet, por lo que el jabón es para redes locales tiene más demanda, en particular Sharepoint tiene un servicio de telenovela con el que puedes comunicarte con éxito (y con algunas limitaciones).
- Cambiar automáticamente la descripción de un servicio web puede dañar a todos los clientes. Bueno, es así para cualquier sistema, si no es compatible. compatibilidad con versiones anteriores con los viejos métodos todo se caerá...
- No es un inconveniente, sino un inconveniente. Todas las llamadas a métodos deben ser atómicas. Por ejemplo, cuando trabajamos con una base de datos, podemos iniciar una transacción, ejecutar varias consultas y luego revertir o confirmar. No hay transacciones en jabón. Una petición, una respuesta, la conversación ha terminado.
- Lidiar con la descripción de lo que hay en el lado del servidor (¿está todo descrito correctamente?) y lo que hay en el cliente (¿qué me describieron aquí?) puede ser bastante difícil. Hubo varias ocasiones en las que tuve que entender el lado del cliente y convencer al programador del servidor de que sus datos estaban descritos incorrectamente, pero él no podía entender nada al respecto, porque la generación automática y no debería hacerlo, es una cuestión de software. . Y el error, naturalmente, estaba en el código del método; el programador simplemente no lo vio.
- La práctica demuestra que los desarrolladores de servicios web están terriblemente lejos de las personas que utilizan estos servicios web. En respuesta a cualquier solicitud (válida desde el exterior), puede aparecer un error incomprensible "Error 5. Todo está mal". Todo depende de la conciencia de los desarrolladores :)
- Seguro que todavía no recuerdo algo...
Como ejemplo, existe un servicio web abierto belavia:
- http://86.57.245.235/TimeTable/Service.asmx - punto de entrada, mismo lugar descripción del texto métodos para desarrolladores externos.
- http://86.57.245.235/TimeTable/Service.asmx?WSDL - descripción wsdl métodos y tipos de datos recibidos y devueltos.
- http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList: descripción de un método específico con un ejemplo del tipo de solicitud xml y respuesta xml.
Puede crear y enviar manualmente una solicitud como:
POST /TimeTable/Service.asmx HTTP/1.1 Host: 86.57.245.235 Tipo de contenido: texto/xml; charset=utf-8 Longitud del contenido: longitud SOAPAction: "http://webservices.belavia.by/GetAirportsList"
la respuesta vendrá:
HTTP/1.1 200 OK Fecha: lunes, 30 de septiembre de 2013 00:06:44 GMT Servidor: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Control de caché: privado, máximo -age=0 Tipo de contenido: texto/xml; charset=utf-8 Contenido-Longitud: 2940
PD: Anteriormente, se abrió el servicio web de Aeroflot, pero después de que 1C agregó soporte para SOAP a 8ku, un grupo de probadores beta de 1C lo instalaron con éxito. Ahora algo ha cambiado allí (no sé la dirección, puedes buscarla si estás interesado).
Descargo de responsabilidad de ZZY. Habló en el nivel cotidiano. Puedes patear.
JABÓN- un protocolo de texto que utiliza XML para intercambiar mensajes estructurados en un entorno informático distribuido. Originalmente, SOAP estaba destinado principalmente a implementar llamadas a procedimientos remotos (RPC), y el nombre era un acrónimo: Protocolo simple de acceso a objetos. El protocolo se utiliza ahora para intercambiar mensajes arbitrarios en formato XML, y no sólo para llamar a procedimientos. La especificación oficial de la última versión 1.2 del protocolo no descifra el nombre SOAP de ninguna manera. SOAP es una extensión del protocolo XML-RPC. SOAP se puede utilizar con cualquier protocolo de capa de aplicación: SMTP, FTP, HTTP, etc. Sin embargo, su interacción con cada uno de estos protocolos tiene sus propias características que deben definirse por separado. La mayoría de las veces, SOAP se utiliza sobre HTTP. SOAP es uno de los estándares en los que se basan las tecnologías de servicios web. La comunicación entre los servicios web y sus clientes se realiza a través de mensajes en formato XML. SOAP (Protocolo simple de acceso a objetos) es un protocolo de mensajes para seleccionar servicios web. Podemos decir que el formato SOAP es ideal para la tecnología RPC (Llamada a Procedimiento Remoto), ya que el mensaje SOAP contiene parámetros enviados por el cliente o un valor de retorno enviado por el servicio.
Ventajas de utilizar el formato SOAP:
· Tipos de datos más flexibles.
· Soporte para encabezados y extensiones:
Defectos:
· El uso de SOAP para transmitir mensajes aumenta su volumen y reduce la velocidad de procesamiento. En sistemas donde la velocidad es importante, es más común enviar documentos XML a través de HTTP directamente, donde los parámetros de solicitud se pasan como parámetros HTTP normales.
· Aunque SOAP es un estándar, diferentes programas suelen generar mensajes en un formato incompatible. Por ejemplo, el servidor WebLogic no entenderá una solicitud generada por un cliente AXIS.
Conceptos básicos del protocolo:
La parte que envía el mensaje SOAP se denomina remitente SOAP y la parte que lo recibe se denomina receptor SOAP. La ruta que sigue un mensaje SOAP desde el remitente original hasta el destinatario final se denomina ruta del mensaje. La ruta del mensaje contiene el remitente original, el destinatario final y 0 o más intermediarios SOAP. Los objetos que procesan mensajes según las reglas de protocolos SOAP específicos se denominan nodos SOAP. La unidad elemental de información que participa en el intercambio entre nodos SOAP se denomina mensaje SOAP; es un documento XML con un elemento raíz contenedor SOAP.
Protocolo simple de acceso a objetos (SOAP) es un protocolo basado en XML que define las reglas para transmitir mensajes a través de Internet entre varios sistemas de aplicaciones. Se utiliza principalmente para llamadas a procedimientos remotos. SOAP se diseñó originalmente para funcionar "por encima" de HTTP (para simplificar la integración de SOAP en aplicaciones web), pero ahora también se pueden utilizar otros protocolos de transporte, como SMTP.
Digamos que está creando un servicio de acceso a aplicaciones en Internet; los consumidores interactúan con este servicio proporcionándole información. Sus servidores procesan los datos y devuelven los resultados a los consumidores. ¿Cuál es la mejor manera de mantener la comunicación con el sistema?
Podría crear una aplicación cliente-servidor personalizada y exigir que los consumidores utilicen un programa cliente personalizado para acceder a su servicio. Pero si realmente quiere entrar en el negocio de Internet, tendrá que crear un cliente que se ejecute en todas las plataformas de cliente posibles: Windows, Macintosh, Unix, Linux, etc. En otras palabras, necesitará escribir muchos clientes diferentes. .
¿Cómo te sientes acerca del uso de la Web? Esta solución es, por supuesto, bastante aceptable, pero está estrechamente ligada a la implementación del navegador, y nuevamente tendrá que crear la infraestructura para enviar y recibir información entrante y saliente, así como formatear y empaquetar los datos para dicho intercambio. Puede elegir Java o ActiveX para implementar aplicaciones complejas, pero algunos usuarios rechazarán sus servicios debido a requisitos de ancho de banda claramente inflados y seguridad inadecuada.
Todo lo que se requiere es un protocolo simple que simplifique el empaquetado de los datos de la aplicación y los transfiera a través de la Web utilizando XML adaptado al contenido. Al hacerlo, garantiza que tanto el remitente como el destinatario puedan interpretar fácilmente el contenido de cualquier mensaje. Al mismo tiempo, gracias al uso del protocolo web HTTP como transporte, será posible eliminar la necesidad de reducir el nivel de protección del firewall.
El bien descrito Protocolo simple de acceso a objetos (SOAP) es un protocolo simple que permite a los hosts invocar de forma remota objetos de aplicaciones y devolver resultados. SOAP ofrece un conjunto mínimo de condiciones que permiten que una aplicación pase mensajes: el cliente puede enviar un mensaje para invocar un objeto de programa y el servidor puede devolver los resultados de esa llamada.
SOAP es bastante simple: los mensajes son documentos XML que contienen comandos SOAP. Aunque en teoría SOAP puede vincularse a cualquier protocolo de transporte para aplicaciones, normalmente se utiliza junto con HTTP.
Kennard Scribner, uno de los autores del libro. Comprender SOAP: la solución autorizada(Macmillan USA, 2000), dice que SOAP funciona convirtiendo la información necesaria para llamar a un método (como valores de argumentos e identificadores de transacciones) al formato XML.
Los datos se encapsulan en HTTP o algún otro protocolo de transporte y se transmiten al destinatario, que suele ser el servidor. Este servidor extrae los datos SOAP del paquete, realiza el procesamiento requerido y devuelve los resultados como una respuesta SOAP.
Scribner señaló que SOAP actúa como un protocolo de llamada a procedimiento remoto, muy parecido al protocolo de invocación de método remoto en Java o al protocolo general Inter-ORB en CORBA.
Debido a que HTTP y XML se utilizan prácticamente en todas partes, SOAP parece ser el protocolo de llamada a procedimientos remotos más escalable creado hasta la fecha, afirmó Scribner. SOAP no está diseñado para actuar como una arquitectura de objetos completa.
SOAP no reemplaza el protocolo de invocación de método remoto en Java, el modelo de objetos componentes distribuidos y CORBA; Ofrece reglas que cualquiera de estos modelos puede utilizar. SOAP no es una solución completa. No admite activación o protección de objetos. Según Scribner, los desarrolladores de SOAP "confían en que los usuarios agregarán este código ellos mismos" al construirlo sobre SOAP, en lugar de hacerlo parte del protocolo en sí.
La figura muestra un ejemplo tomado de la especificación SOAP 1.1 en el que un host solicita un servicio de cotización del precio de una acción en particular. La solicitud SOAP está integrada en un HTTP POST y el cuerpo de la solicitud especifica el tipo de solicitud y el parámetro: el símbolo bursátil. La respuesta también proporciona un objeto XML encapsulado en la respuesta HTTP con un único valor de retorno (34,5 en este caso).
Características del jabón
Con SOAP, los desarrolladores pueden crear servicios web con la misma rapidez con la que escriben mensajes SOAP para llamar a programas para aplicaciones existentes y luego agregar esas aplicaciones a páginas web simples. Pero además, los desarrolladores tienen la capacidad de utilizar llamadas SOAP en aplicaciones dedicadas y crear aplicaciones que pueden trasladarse a páginas web de otras personas, evitando así el proceso de desarrollo costoso y que requiere mucho tiempo.
Según Mark Stiver, otro autor del libro Understanding SOAP, este es precisamente el objetivo que persigue Microsoft con su prometedora plataforma .Net. “Aquí es donde brilla SOAP. Ofrece a los desarrolladores una manera realmente excelente de crear aplicaciones sin tener que preocuparse por posibles incompatibilidades”, afirma.
Ejemplo de jabón
El siguiente ejemplo ilustra una solicitud SOAP llamada GetLastTradePrice, que permite a un cliente enviar una solicitud de las últimas cotizaciones de una acción en particular.
POST/Cotización de acciones HTTP/1.1
Anfitrión: stockquoteserver.com
Tipo de contenido: texto/xml; conjunto de caracteres="utf-8"
Longitud del contenido: nnnn
SOAPAcción:"Algunos-URI"
Las primeras cinco líneas (parte del encabezado HTTP) especifican el tipo de mensaje (POST), el host, el tipo de carga útil y la longitud de la carga útil, y el encabezado SOAPAction especifica el propósito de la solicitud SOAP. Ser mensaje de jabón es un documento XML donde el sobre SOAP viene primero, luego elemento XML, que especifica el espacio de nombres y los atributos de SOAP, si los hubiera. Un sobre SOAP puede incluir un encabezado (pero no en este caso) seguido de un cuerpo SOAP. En nuestro ejemplo, el cuerpo contiene la solicitud GetLastTradePrice y el símbolo de la acción para la que se solicitan las últimas cotizaciones. La respuesta a esta consulta podría verse así:
HTTP/1.1 200 correcto
Tipo de contenido: texto/xml; conjunto de caracteres="utf-8"
Longitud del contenido: nnnn
Nuevamente, las primeras tres líneas son parte del encabezado HTTP; El mensaje SOAP en sí consta de un sobre que contiene la respuesta a la solicitud original, denominada GetLastTradePriceResponse, e incluye el valor de retorno, en nuestro caso 34,5.
En realidad hoy hay protocolos estándar Intercambio de datos XML:
- XML-RPC– pasas el paquete e indicas a qué método del servidor quieres llamar.
- DESCANSAR- hay algunos objetos en el servidor. Cada objeto se caracteriza por algún tipo de identificador. Cada elemento tiene su propia URL. Puedes hacer lo siguiente con cualquier elemento: insertar, eliminar, actualizar, seleccionar. Simplemente envía la solicitud deseada al servidor (por ejemplo, inserta tal o cual elemento). El intercambio cliente-servidor se basa en JSON o XML.
SOAP (arquitectura orientada a servicios, un conjunto de servicios débilmente acoplados que interactúan entre sí) se basa en RPC. La principal ventaja de RPC es la pequeña cantidad de recursos de red (puntos de entrada) y los muchos métodos involucrados. A pesar de esta ventaja, RPC es un protocolo obsoleto que tiene una serie de desventajas:
- No se puede verificar la validez del mensaje XML-RPC. El antiguo protocolo se creó antes de que los esquemas (métodos de validación de datos) se estandarizaran en XML. Aquellos. El servidor acepta solicitudes, debe asegurarse de que las solicitudes sean para él y que los datos sean consistentes. En XML-RPC, los tipos de datos se declaran para esto, pero esto es una verificación del tipo de datos y no se verifica la coherencia de los datos (que recibió una estructura con todos los parámetros necesarios).
- No puedes crear mensajes combinados.
- No se puede utilizar el espacio y el tiempo (apareció después de la creación de RPC).
- No puede expandir el mensaje, es decir. agregar información adicional.
Todas estas deficiencias se resolvieron en XML Schema. Este es un estándar de la industria. Descripciones XML documento. Aquellos. es una forma de modelar datos arbitrarios. esquemas XML y puede describir el modelo (relaciones entre elementos y atributos, y su estructura), tipos de datos (caracteriza los tipos de datos) y vocabulario (nombres de elementos y atributos).
Sobre la base de todas las deficiencias de XML-RPC, se creó el protocolo SOAP.
JABÓN(Protocolo de acceso a objetos simples): protocolo de acceso a un objeto (al punto de entrada). Hoy en día es el principal estándar de la industria para crear aplicaciones distribuidas.
Representa extensiones del lenguaje XML-RPC. Aquellos. se basa en el principio: 1 punto de entrada y cualquier método. El protocolo en sí en términos de transporte (cómo transferir datos) ofrece una amplia variedad de opciones: SMTP, FTP, HTTP, MSMQ.
SOAP es el núcleo Implementaciones XML servicios web (servicios web XML). La desventaja de SOAP es que es difícil de aprender.
SOAP se basa en el intercambio de mensajes entre un cliente y un servidor (de forma síncrona y asíncrona). Cada mensaje transporta información sobre los datos (qué datos se transmiten y reciben). SOAP describe toda la estructura del mensaje de antemano con usando XML esquemas: qué debe contener el mensaje, cómo se transmitirá. Esto hace posible, sin conocer el servidor, comprender lo que está sucediendo allí y le permite al servidor verificar si este mensaje es para él.
esquema XML
El propósito de un esquema es describir la estructura de los datos, es decir. lo que tenemos. Todos los datos se dividen en simples y tipos complejos(escalares y estructuras). Un tipo simple (cadena, número, booleano, fecha) nunca contendrá nada dentro. Y una estructura (objeto) puede contener propiedades.
Operaciones SOAP básicas
- No sólo un simple intercambio de información cliente-servidor. Pero también reconocimiento automático servidor y busque este servidor, es decir Es posible que el cliente ni siquiera sepa nada sobre el servidor. Aquellos. el cliente primero busca el servidor, encuentra los servicios adecuados, comprende qué métodos existen, qué tiene el servidor y lo llama.
- El servidor publica su información (ubicación, qué métodos admite) para que el cliente encuentre este servidor. La publicación se produce en el directorio UDDI.
Estructura de los mensajes SOAP:
- Sobre SOAP: incluye el mensaje completo. Consta de una cabecera y un cuerpo.
- Encabezado de jabón - información adicional(autorización, por ejemplo).
- Cuerpo SOAP (cuerpo): el mensaje en sí.
- SOAP Fault (error) es un método para transmitir un error del servidor al cliente.
WSDL
WSDL(Lenguaje de descripción de servicios web): lenguaje para describir servicios web. Utilizado en jabón. Este es un tipo de documento que describe todo: qué espacios de nombres se usaron, qué esquemas de datos se usaron, qué tipos de mensajes espera el servidor del cliente, qué sobres pertenecen a qué método, qué métodos existen, a qué dirección enviar, etc. . En realidad, WSDL es un servicio web. Basta con que el cliente estudie el contenido de este documento; ya sabe todo sobre el servidor.
Cualquier servidor debe publicar WSDL.
WSDL consta de bloques:
- Definición del servicio en sí, es decir. punto de entrada, se indica el puerto.
- Formato de métodos. El punto de entrada está vinculado a las operaciones, es decir. ¿Qué métodos admite? Se indican el tipo de llamada y el método de transmisión. Dentro de cada método hay una explicación de la forma en que se transmiten los datos: en forma de SOAP.
- Métodos de enlace a un mensaje.
- Descripción de los propios mensajes.
