Tecnología del jabón. Protocolo SOAP y Servicios Web. ¿Qué es el jabón?

• Tutorial

¡Hola a todos!
Sucedió que en últimamente Empecé 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;
• escribe el tuyo propia descripción servicio web (WSDL);
• enviar las matrices del cliente del mismo tipo de datos al servidor.

Como habrás adivinado, toda la magia sucederá con usando PHP y clases integradas SoapClient y SoapServer. Nuestro conejo será un servicio de envío de mensajes SMS.

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 a través del 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?

Algo me dice que para esto necesitas enviar lo siguiente:

• número teléfono móvil, y también
• texto del mensaje SMS.

En principio, estas dos características son suficientes para enviar, pero inmediatamente me imagino el caso de que te llegue un SMS con felicitaciones de cumpleaños a las 3 de la mañana, ¡o a las 4! ¡En este momento estaré muy agradecido con todos por no olvidarse de mí! Por lo tanto, también enviaremos al servidor y

• fecha de envío del mensaje SMS.

Lo siguiente que me gustaría enviar al servidor es:

• Tipo de mensaje.

Este parámetro no es obligatorio, pero nos puede resultar muy útil si necesitamos decirle rápidamente al jefe cuántos de nuestros clientes hemos “encantado” con nuestra noticia, y además sacar algunas bonitas estadísticas al respecto.

¡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 permite el uso de una pequeña cantidad de recursos de red Con un gran número Métodos y 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 inglés Simple Object Protocolo de acceso- 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(Lenguaje de descripción de servicios web). Sí, sí, esto es precisamente lo que nos asusta a la mayoría de nosotros incluso de intentar tomar e 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 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?

Como se puede ver, este archivo y ahí está todo el servicio web. Al especificar la dirección del archivo WSDL en el cliente, ¡sabremos todo sobre cualquier servicio web! Como resultado, no necesitamos saber absolutamente nada sobre dónde se encuentra el servicio web. ¡Todo lo que necesitas saber es la ubicación de su archivo WSDL! Pronto descubriremos que SOAP no da tanto miedo como dicen los proverbios rusos.

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 un método de interacción entre un cliente y un servidor, y el lenguaje de marcado XML se utiliza como transporte para ello, en esta sección entenderemos 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.

Algo muy sencillo que no tiene extensiones en su interior. Su antípoda son los tipos complejos complejos. El ejemplo más simple de un tipo complejo que viene a la mente de todos son los objetos. Por ejemplo, un libro. El libro consta de propiedades: autor, Nombre, precio, número ISBN etc. Y estas propiedades, a su vez, pueden ser de tipos simples o complejos. Y la tarea del esquema XML es describir esto.

¡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:

71239876543 Mensaje de prueba 2013-07-20T12:00:00 12
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. La estructura general del paquete podría verse así:

71239876543 Mensaje de prueba 1 2013-07-20T12:00:00 12 71239876543 Mensaje de prueba N 2013-07-20T12:00:00 12
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.

Por lo general, para que todo nos funcione correctamente, necesitamos transferir un 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... La mayor parte del 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 transmisión. 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 el nuestro propio. 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” smsservice.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:

"; ?> /" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:http="http:// esquemas.xmlsoap.org/wsdl/http/" nombre="SmsWsdl" xmlns="http://schemas.xmlsoap.org/wsdl/"> /">

/smsservicio.php" />
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:

79871234567 Mensaje de prueba 1 2013-07-21T15:00:00.26 15
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:

79871234567 Mensaje de prueba 1 2013-07-21T15:00:00.26 15 79871234567 Mensaje de prueba 2 2014-08-22T16:01:10 16 79871234567 Mensaje de prueba 3 2014-08-22T16:01:10 17
¿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 exactamente de la misma forma, en forma de sobre. Es cierto que los mensajes SMS no se serializaron en XML de la manera que necesitábamos: tuvieron que estar envueltos 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 "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)
¿Qué nos aporta este conocimiento? Sólo que la ruta que elegimos no es correcta y no recibimos respuesta a la pregunta: "¿Cómo podemos obtener la estructura de datos correcta en el servidor?" 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:

79871234567 Mensaje de prueba 1 2013-07-21T15:00:00.26 15 79871234567 Mensaje de prueba 2 2014-08-22T16:01:10 16 79871234567 Mensaje de prueba 3 2014-08-22T16:01:10 17
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ó:

79871234567 Mensaje de prueba 1 2013-07-21T15:00:00.26 15 79871234567 Mensaje de prueba 2 2014-08-22T16:01:10 16 79871234567 Mensaje de prueba 3 2014-08-22T16:01:10 17
¡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).

También hicimos algunos descubrimientos durante nuestra pequeña investigación:

• 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).

JABÓN- un protocolo de texto que utiliza XML para intercambiar mensajes estructurados de forma distribuida entorno informático. 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. Especificación oficial ú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, varios programas a menudo generan 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. Objetos que procesan mensajes según reglas. ciertos protocolos Los SOAP 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.

Como se analizó en el capítulo anterior, los servicios web se comunican con los clientes y entre sí mediante el envío de mensajes en XML. Etiquetas para esto Implementaciones XML, las reglas para formatear un documento XML y el orden de intercambio de documentos están definidas por el protocolo SOAP. protocolo jabón creado en 1998 por un equipo de desarrolladores liderado por Dave Winer, quien trabajó en Microsoft Corporation y Userland. El nombre del protocolo, "Protocolo simple de acceso a objetos", refleja su propósito original: acceder a los métodos de objetos remotos. El propósito del protocolo ha cambiado; ahora es un protocolo para cualquier interacción entre servicios web y componentes de aplicaciones distribuidas débilmente acopladas. Ya no es del todo sencillo y no dice nada sobre los objetos. Muchos desarrolladores sugieren llamarlo "Protocolo de arquitectura orientada a servicios", dejando la abreviatura anterior. Para detener estos intentos, la especificación SOAP 1.2 establece que la palabra "SOAP" ya no se escribirá de ninguna manera.

A finales de 1999, el desarrollo del protocolo fue transferido al consorcio W3C (http:// www.w3.org/).

En mayo de 2000, el consorcio lanzó su versión de SOAP 1.1. Un mensaje escrito utilizando el protocolo SOAP tiene el formato de un documento XML que utiliza activamente espacios de nombres. Los nombres de los elementos XML de SOAP 1.1 hacen referencia al identificador de espacio de nombres http://schemas.xmlsoap.org/soap/envelope/.

El segundo borrador de SOAP 1.2 se publicó en 2001, su espacio de nombres en ese momento se llamaba http://www.w3.org/2001/06/soap-envelope.

Tenga en cuenta que es el identificador del espacio de nombres, no el número 1.1 o 1.2, lo que determina la versión de SOAP. El servidor no considerará el mensaje SOAP y devolverá un mensaje de error si lo detecta.

discrepancia en el espacio de nombres.

Mientras escribo esto, SOAP 1.1 sigue funcionando. La versión 1.2 no puede salir de la etapa preparatoria, pero ya se utiliza, por ejemplo, en SOAP::Lite, Apache SOAP 2.3, Apache Axis. Por lo tanto, en este capítulo describiré la versión 1.2, observando sus diferencias con la versión 1.1.

Especificación versión de trabajo SOAP siempre se almacena en http://www.w3.org/TR/SOAP/. Los documentos ubicados en esta dirección se reemplazan por otros nuevos cuando se reemplaza la versión funcional.

La versión borrador de SOAP se actualiza continuamente y el identificador del espacio de nombres cambia. Opción más nueva La versión borrador en el momento de escribir este artículo se encontraba en http://www.w3.org/TR/soapl2-partl/ y el espacio de nombres que utilizaba se llamaba http://www.w3.org/2002/06/soap. -sobre. Tenga en cuenta que la especificación SOAP 12 consta de dos partes: parte 1 y parte 2. La segunda parte de la especificación, la aplicación, contiene reglas para registrar tipos de datos complejos. La especificación tiene otra parte, partO: ejemplos de mensajes compilados según las reglas de SOAP 1.2.

Estructura del mensaje SOAP

La especificación define un mensaje SOAP como un documento XML que no contiene una declaración de tipo de documento ni instrucciones de procesamiento. El elemento raíz de este documento XML se llama . Un elemento puede tener atributos que definen espacios de nombres,

y otros atributos provistos de prefijos. El elemento raíz contiene uno. elemento opcional que contiene el encabezado del mensaje y un elemento requerido , en el que se registra el contenido del mensaje. Versión 1.1 permitida después del cuerpo. para escribir elementos arbitrarios, sus nombres debían ir precedidos. La versión 1.2 prohíbe escribir cualquier cosa después del elemento. . En breve, estructura general El mensaje SOAP es:

xmlns:env="http://www.w3.org/2002/06/soap-sobre">

< ! - Блоки заголовка ->

Elemento

, si está en el mensaje, se escribe primero en el cuerpo del elemento . Además de los atributos xmlns, puede contener un atributo de actor, que indica la dirección URI del servidor SOAP específico al que está destinado el mensaje.

El caso es que un mensaje SOAP puede pasar por varios servidores SOAP o por varias aplicaciones en el mismo servidor. Estas aplicaciones preprocesan los bloques de encabezado del mensaje y se los transmiten entre sí. Todos estos servidores y/o aplicaciones se denominan nodos SOAP. La especificación SOAP no define reglas para pasar un mensaje a través de una cadena de servidores. Para ello se están desarrollando otros protocolos, por ejemplo Microsoft WS-Routing.

El atributo de actor especifica el nodo SOAP de destino, el que se encuentra al final de la cadena y procesará todo el encabezado. Significado

El atributo de actor indica que el encabezado será procesado por el primer servidor que lo reciba. El atributo de actor puede aparecer en bloques de encabezado separados, indicando el nodo que maneja este bloque. Después del procesamiento, el bloque se elimina del mensaje SOAP.

En la versión 1.2, el atributo de actor se reemplaza por el atributo de rol porque en esta versión de SOAP, cada nodo desempeña uno o más roles. La especificación define actualmente tres roles de nodo SOAP.

El papel de http://^^.w3.org/2002/06/soap-envelope/role/ultimateReceiver lo desempeña el nodo de destino final que procesará el encabezado.

El papel http://www.w3.org/2002/06/soap-envelope/role/next lo desempeña el nodo intermedio o de destino. Un nodo de este tipo puede desempeñar otras funciones adicionales.

El rol http://www.w3.org/2002/06/soap-envelope/role/none no debe desempeñarlo ningún nodo SOAP.

Las aplicaciones distribuidas, según sus necesidades, pueden agregar otros roles a estos roles, por ejemplo, ingresar servidor intermedio, que verifica la firma digital y define esta función con alguna cadena URI.

El valor del atributo de rol puede ser cualquier cadena URI que indique el rol del nodo al que está destinado este bloque de encabezado. El valor predeterminado para este atributo es valor vacío, es decir, solo un par de comillas o la cadena URI http://\vw\v.w3.org/2002/06/soap-envelope/rale/ultimateReceiver.

El valor del atributo de rol indica que el bloque debe ser procesado por un nodo que desempeña el rol especificado por la misma cadena.

Otro atributo de elemento

, llamado urnstUnderstand, toma los valores o o 1. Su valor predeterminado es o. Si el atributo mustunderstand es igual a 1, entonces el nodo SOAP, al procesar el elemento, debe tener en cuenta su sintaxis definida en el esquema del documento, o no procesar el mensaje en absoluto. Esto aumenta la precisión del procesamiento de mensajes.

En SOAP versión 1.2, en lugar del número o, debe escribir la palabra falso y, en lugar del número 1, escribir la palabra verdadero.

En el cuerpo del encabezado

Puede anidar elementos arbitrarios, anteriormente llamados entradas de encabezado. En la versión 1.2, estos se denominan bloques de encabezado. Sus nombres están necesariamente marcados con prefijos. Los bloques de encabezado pueden contener los atributos rol o actor y deben entenderse. Su acción sólo se aplicará a este bloque. Esto permite que los bloques de encabezado individuales sean procesados ​​por nodos SOAP intermedios, aquellos cuyo rol coincide con el rol especificado por el atributo de rol. El Listado 3.1 muestra un ejemplo de dicho bloque.

Listado 3.1. Cabecera con un bloque

xmlns:t="http://some.com/transaction" env:rol=

"http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver" env:mustUnderstand="1">

Los elementos anidados dentro de bloques de encabezado ya no se denominan bloques. No pueden contener el rol, el actor y deben comprender los atributos.

Elemento debe escribirse inmediatamente después del elemento

, si está en el mensaje, o primero en el mensaje SOAP si falta el encabezado. al elemento Puede anidar elementos arbitrarios; la especificación no define su estructura de ninguna manera. Sin embargo, se define un elemento que contiene un mensaje de error.

Mensaje de error

Si un servidor SOAP, mientras procesa un mensaje SOAP recibido por él, detecta un error, dejará de procesar y enviará un mensaje SOAP al cliente, en cuyo cuerpo escribirá un elemento. con un mensaje de error.

En el mensaje escrito en el cuerpo de un elemento SOAP 1.1,

Hay cuatro partes descritas por los siguientes subelementos.

código de error - un mensaje indicando el tipo de error. Está destinado a un programa que maneja errores.

Descripción del error - una descripción verbal del tipo de error previsto para una persona.

Donde se encontró el error - el URI del servidor que detectó el error. Útil cuando un mensaje pasa por una cadena de nodos SOAP para aclarar la naturaleza del error. Se requieren nodos SOAP intermedios para registrar este elemento; no es necesario que el servidor SOAP de destino lo haga.

Detalles del error - describir los errores encontrados en el cuerpo mensaje, pero no en su título. Si no se encuentran errores durante el procesamiento del cuerpo, entonces falta este elemento.

Por ejemplo:

xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">

env:Debe entender SOAP debe comprender el error

La versión 1.2 de SOAP cambió el contenido del elemento como se describe en

espacio de nombres http://www.w3.org/2002/06/soap-envelope, incluye dos elementos obligatorios y tres elementos opcionales.

Elementos requeridos.

código de error . Contiene un subelemento requerido.<:value>con un código de error y un subelemento opcional , que contiene, nuevamente, el elemento con código de error aclaratorio y elemento , y luego todo se repite de forma recursiva.

Motivo del error . Contiene opcional atributo xml: lang, que indica el idioma del mensaje (consulte el Capítulo D) y un número arbitrario de elementos anidados que describen el error.

Elementos opcionales.

? - el URI del nodo SOAP intermedio que detectó el error.

? - la función del nodo SOAP que detectó el error.

? - descripción del error observado durante el procesamiento del cuerpo mensaje, pero no el título.

El Listado 3.2 muestra un mensaje de error que ocurrió al intentar ejecutar un procedimiento. El error es que los nombres de los argumentos del procedimiento están escritos incorrectamente en el mensaje SOAP y el procedimiento no puede entenderlos.

Listado 3.2. Mensaje de error

xmlns:env="http://www.w3.org/2002/06/soap-envelope" xmlns:rpc=’http://www.w3.org/2002/06/soap-rpc’>

env:Remitente

rpc:BadArgumentsc/env:Valor>

Procesamiento de ETror

xmlns:e="http://www.example.org/faults"> №yo no coincide 999

tipos de errores

La lista de códigos de error cambia y se amplía constantemente. La versión 1.1 define cuatro tipos de errores.

VersionMismatch: el espacio de nombres no se reconoce. Puede que esté desactualizado o que su nombre esté mal escrito.

MustUnderstand: un bloque de encabezado marcado con un atributo mustUnderstand con un valor de 1 no se ajusta a su sintaxis tal como se define en el esquema del documento.

Cliente: el documento XML que contiene el mensaje tiene un formato incorrecto y, por este motivo, el servidor no puede procesarlo. El cliente debe cambiar el mensaje.

Servidor: el servidor no puede procesar el mensaje grabado correctamente a su manera razones internas.

La versión 1.2 define cinco tipos de errores.

VersionMismatch: el espacio de nombres no se reconoce. Quizás esté desactualizado, o su nombre esté mal escrito, o haya un nombre en el mensaje elemento XML, no definido en este espacio de nombres. El servidor escribe el elemento en el encabezado de respuesta. , enumerando elementos anidados nombres correctos espacios de nombres comprendidos por el servidor. La respuesta del servidor se muestra en el Listado 3.3.

MustUnderstand: un bloque de encabezado marcado con el atributo mustunderstand establecido en verdadero no se ajusta a su sintaxis tal como se define en el esquema del documento. El servidor escribe los siguientes elementos en el encabezado de respuesta: , cuyo atributo qname contiene el nombre del bloque incorrecto. El Listado 3.4 contiene un ejemplo de la respuesta que daría el servidor si el encabezado del Listado 3.1 estuviera mal escrito.

DataEncodingUnknown: el mensaje contenía datos incomprensibles, tal vez estaba escrito en una codificación desconocida.

Remitente: el documento XML que contiene el mensaje tiene un formato incorrecto y, por este motivo, el servidor no puede procesarlo. El cliente debe cambiar el mensaje.

Receptor: el servidor no puede procesar el mensaje grabado correctamente por motivos internos, por ejemplo, falta el analizador XML requerido.

El servidor puede agregar algunos de sus propios tipos a estos tipos de error. Generalmente

ellos detallan tipos estándar, y mensajes sobre ellos aparecen en los elementos , como se muestra arriba en el Listado 3.2.

? Listado 3.3. Respuesta del servidor con un mensaje de error como VersionMismatch

xmlns:env="http://www.w3.org/2002/06/soap-sobre">

xmlns:upg="http://www.w3.org/2002/06/soap-upgrade">

xmlns:nsl="http://www.w3.org/2002/06/soap-sobre"/>

xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>

env: VersionMismatch

La versión no coincide

ListongZ.4. Respuesta del servidor con un mensaje de error como MustUnderstand

xmlns:t=’http://some.com/transaction’ />

env:Debe entender

Uno o más encabezados obligatorios no se entienden

Literatura:

Khabibullin I. Sh. Desarrollo de servicios web. usando Java. - San Petersburgo: BHV-Petersburg, 2003. - 400 p.: ill.

¿Qué es el jabón?

SOAP significa Protocolo simple de acceso a objetos. Espero que después de leer el artículo solo te quedes preguntándote: “¿Cuál es este nombre extraño?”

SOAP en su forma actual es un método de llamada a procedimiento remoto (RPC) a través de una red. (Sí, también se utiliza para transferir documentos como XML, pero lo omitiremos por ahora).

Vamos a resolverlo. Imagine que tiene un servicio que devuelve una cotización de acciones para un símbolo de cotización determinado. Envía los datos al sitio Nasdaq y los genera en función del HTML devuelto. resultado deseado. A continuación, para permitir que otros desarrolladores lo utilicen dentro de sus aplicaciones, se crea un componente de este servicio que encuentra información sobre cotizaciones a través de Internet. Funciona muy bien hasta que un día Nasdaq cambia el diseño de sus páginas. Debe reconsiderar toda la lógica del componente y enviar actualizaciones a todos los desarrolladores que lo utilicen. Y ellos, a su vez, necesitan enviar actualizaciones a todos sus usuarios. Si esto sucede de forma más o menos constante, puedes ganarte muchos enemigos entre tus compañeros desarrolladores. Y con los programadores, como usted sabe, no se puede jugar. No querrás sacar mañana una foto de tu gato favorito de la trituradora de la oficina, ¿verdad?

¿Qué hacer? Veamos... todo lo que necesitas es proporcionar una función que tome un ticker como entrada ( tipo cadena) y devolver una cotización de acciones (de tipo flotante o doble). Entonces, ¿no sería más fácil dejar que sus desarrolladores llamen a esta función a través de Internet de alguna manera? ¡Excelente! Otra novedad para mí es que existen COM, Corba y Java que han estado haciendo esto durante años... lo que es cierto, es cierto, pero estos métodos no están exentos de defectos. Remoto configuración COM no trivial. Además, es necesario abrir tantos puertos en el firewall que administrador del sistema No puedes conseguir suficiente cerveza. Sí, y tendrás que olvidarte de los usuarios de todos los sistemas operativos excepto Windows. Pero los usuarios de Linux a veces también se interesan por el intercambio.

Aunque parece que no todo está perdido para los usuarios de Linux si usan DCOM, hay más información aquí: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.

No puedo decir mucho sobre Corba y Java, así que como ejercicio invito a los lectores a encontrar las desventajas de estos enfoques.

SOAP es un estándar que le permite describir dicha llamada remota y la forma en que se devolverá el resultado. Por lo tanto, necesita alojar su función en una aplicación accesible a través de la red y recibir llamadas como paquetes SOAP. Luego valida la entrada, ejecuta su función y devuelve el resultado en un nuevo paquete SOAP. Todo el proceso puede ejecutarse a través de HTTP, por lo que no es necesario abrir muchos puertos en el firewall. ¿Es realmente sencillo?

¿De qué trata este artículo?

Este es el primero de una serie de artículos que estamos escribiendo sobre SOAP en Agni Software. En este artículo intentaré darle una idea de qué es SOAP y cómo escribir una aplicación que se comunique con un servidor SOAP.

Jabón y XML

Si SOAP todavía le parece sencillo, agreguemos XML. Ahora, en lugar del nombre de la función y los parámetros, obtenemos un sobre XML bastante complejo, como si estuviera diseñado para confundirlo. Pero no se apresure a asustarse. Hay más que eso y es necesario ver el panorama completo para apreciar la complejidad de SOAP.
Si no sabe qué es XML, primero lea mi artículo sobre XML aquí: http://www.agnisoft.com/white_papers/xml_delphi.asp.

Todos los paquetes SOAP están en formato XML. ¿Qué significa? Vamos a ver. Eche un vistazo a esta función (Pascal):
función GetStockQuote(Símbolo: cadena): doble; Se ve genial, pero el problema es que es Pascal. ¿De qué sirve esto? definición sencilla
para un desarrollador de Java? ¿O para alguien que trabaja con VB? Necesitamos algo que sea comprensible para todos, incluso para los programadores de VB. Así que proporcióneles XML que contenga la misma información (parámetros, valores de cotización de acciones, etc.). Creas un paquete SOAP, que es esencialmente una llamada a tu función, envuelta en XML para que cualquier aplicación en cualquier plataforma pueda entenderlo. Ahora veamos cómo se ve nuestra llamada SOAP:
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">


IBM

Informativo, ¿verdad? El jabón es cada vez más fácil ante nuestros ojos. Bueno, bromas aparte. Ahora intentaré explicarte cómo entender esta llamada SOAP.

Decodificación de etiquetas La primera etiqueta que te llama la atención es . Esta etiqueta es capa exterior

Un paquete SOAP que contiene varias declaraciones de espacios de nombres que no nos interesan especialmente, pero que son muy importantes para cualquier lenguaje de programación o analizador. Los espacios de nombres se definen para garantizar que el analizador comprenda los prefijos posteriores, como "SOAP-ENV:" o "xsd:". Siguiente etiqueta – . No está en este ejemplo en particular, pero si desea leer más al respecto, consulte la especificación SOAP aquí: http://www.w3.org/TR/SOAP/). Etiqueta en realidad contiene una llamada SOAP.

La siguiente etiqueta en la lista es . El nombre de la etiqueta, GetStockQuote, es la función que se llama. En terminología SOAP, esto se denomina operación. Por tanto, GetStockQuote es la operación que se debe realizar. ns1 es el espacio de nombres que apunta a urn:xmethods-quotes en nuestro caso.

Una nota sobre los espacios de nombres: un espacio de nombres permite calificar una etiqueta XML. Es imposible, por ejemplo, tener dos variables con el mismo nombre en un procedimiento, pero si están en dos diferentes procedimientos, no hay problemas. Por tanto, un procedimiento es un espacio de nombres, ya que todos los nombres que contiene son únicos. Del mismo modo, las etiquetas XML tienen su alcance dentro de los espacios de nombres, por lo que, dado un espacio de nombres y un nombre de etiqueta, puede identificarlo de forma única. Definiremos el espacio de nombres como un URI para diferenciar nuestro NS1 de los imitadores. En el ejemplo anterior, NS1 es un alias que apunta a urn:xmethods-quotes.

También preste atención al atributo encodingStyle: este atributo determina cómo se serializa la llamada SOAP.

Dentro de una etiqueta contiene parámetros. En nuestro caso más simple, solo tenemos un parámetro: etiqueta . Observe esta línea al lado de la etiqueta:
xsi:tipo="xsd:cadena"
Así es aproximadamente como se definen los tipos en XML. (Obsérvese con qué inteligencia utilicé la palabra "aproximadamente" al hacer una generalización sobre la tecnología que puede cambiar una vez que se publique el artículo). ¿Qué significa esto exactamente? Un tipo definido en el espacio de nombres xsi, que notarás que está definido en la etiqueta. – xsd:cadena. Y esto, a su vez, es una cadena, definida en el espacio de nombres xsd, nuevamente, definida anteriormente. (Estoy seguro de que los abogados estarían encantados con todo esto).

Dentro de una etiqueta Se indica "IBM". Este es el valor del parámetro de símbolo de la función GetStockQuote.

Bueno, al final, como gente decente, cerramos todas las etiquetas.

Entonces descubrimos el paquete SOAP que define la llamada al servidor SOAP. Un servidor SOAP con usando XML Los analizadores, el botón rojo y la estación espacial MIR decodifican esta llamada y determinan que necesita una cotización de acciones. Inmediatamente encuentra la cotización correcta y se la devuelve de esta forma:
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>


34.5


Después de desenvolver el sobre de SOAP, arrancar las cintas y hacer crujir el envoltorio, nos enteramos de que el precio de las acciones de IBM es 34,5.

La mayoría de los servidores comerciales devolverían mucho más información, por ejemplo, en qué moneda y a qué precio se compró la última acción. Y el precio de las acciones, tal vez, habría sido más exacto.

De esta manera sabemos qué espera el servidor SOAP y qué devolverá. Entonces, ¿CÓMO se envía esta información? Puedes utilizar cualquier transporte. El más cubierto es HTTP. No entraré en detalles sobre HTTP; para aquellos que no lo saben, es lo que utiliza su navegador para comunicarse con los sitios que visita.

La solicitud HTTP requerida se verá así:
POST /Cotización de acciones HTTP/1.1
Anfitrión: www.stockquoteserver.com

Longitud del contenido: nnnn
SOAPAction: "Algunos-URI"

El paquete de solicitud de jabón aquí... La única otra cosa que vale la pena destacar es el encabezado SOAPAction. Este encabezado indica el propósito de la solicitud y es obligatorio. Cada servidor SOAP puede tener cantidad ilimitada funciones y puede usar el encabezado SOAPAction para determinar qué función se llama. Los firewalls y multiplexores también pueden filtrar contenido según este encabezado.

respuesta SOAP de Servidores HTTP se verá así:
HTTP/1.1 200 correcto
Tipo de contenido: texto/xml; conjunto de caracteres="utf-8"
Longitud del contenido: nnnn

Paquete de respuesta Soap aquí... ¿Por qué HTTP? En primer lugar, administradores de red no es necesario abrir muchos puertos separados para llamadas SOAP... el servidor web puede procesar llamadas fácilmente, porque El puerto 80 suele estar abierto para que todos puedan recibir solicitudes entrantes. Otra ventaja es la extensibilidad de los servidores web que utilizan CGI, ISAPI y otros módulos nativos. Esta extensibilidad le permite escribir un módulo que procese solicitudes SOAP sin afectar otro contenido web.

Eso es todo

Espero que este artículo haya ayudado a arrojar algo de luz sobre SOAP. Si todavía estás aquí y quieres leer más sobre este tema, visita el sitio web de los autores: http://www.agnisoft.com/soap

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. Protocolo antiguo, se creó antes de que los esquemas (cómo validar 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) proporciona amplia elección: SMTP, FTP, HTTP, MSMQ.

SOAP es la base de la implementación de servicios web XML (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 de antemano toda la estructura de un mensaje utilizando esquemas XML: 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.