Protocolo SOAP y Servicios Web. ¿Qué es WSDL, SOAP y REST?

El título del tema es realmente una pregunta, porque... Yo mismo no sé qué es y por primera vez intentaré trabajar con ello en el marco de este artículo. Lo único que puedo garantizar es que el código que se presenta a continuación funcionará, pero mis frases serán solo suposiciones y conjeturas sobre cómo yo mismo entiendo todo esto. Entonces, vámonos...

Introducción

Necesitamos comenzar con por qué se creó el concepto de servicios web. Cuando apareció este concepto en el mundo, ya existían tecnologías que permitían que las aplicaciones interactuaran a distancia, donde un programa podía llamar a algún método en otro programa, que podía ejecutarse en una computadora ubicada en otra ciudad o incluso país. Todo esto se abrevia como RPC (Llamada a procedimiento remoto). Los ejemplos incluyen tecnologías CORBA y, para Java, RMI (invocación de método remoto). Y todo parece ir bien en ellos, especialmente en CORBA, porque... Puedes trabajar con él en cualquier lenguaje de programación, pero todavía faltaba algo. Creo que la desventaja de CORBA es que funciona a través de algunos de sus propios protocolos de red en lugar de un simple HTTP, que atravesará cualquier firewall. La idea del servicio web era crear un RPC que se insertaría en paquetes HTTP. Así comenzó el desarrollo de la norma. Cuáles son los conceptos básicos de esta norma:

1. JABÓN. Antes de llamar a un procedimiento remoto, debe describir esta llamada en un archivo XML en formato SOAP. SOAP es simplemente uno de los muchos códigos XML que se utilizan en los servicios web. Todo lo que queremos enviar a algún lugar a través de HTTP primero se convierte en una descripción XML SOAP, luego se introduce en un paquete HTTP y se envía a otra computadora en la red a través de TCP/IP.
2. WSDL. Hay un servicio web, es decir. un programa cuyos métodos se pueden llamar de forma remota. Pero el estándar requiere que este programa vaya acompañado de una descripción que diga que "sí, tienes razón: este es realmente un servicio web y puedes llamar a tales o cuales métodos desde él". Esta descripción está representada por otro archivo XML, que tiene un formato diferente, concretamente WSDL. Aquellos. WSDL es sólo un archivo XML que describe un servicio web y nada más.

¿Por qué preguntas tan brevemente? ¿No puedes ser más específico? Probablemente sea posible, pero para hacerlo tendrás que recurrir a libros como T. Mashnin, "Java Web Services". Allí, a lo largo de las primeras 200 páginas, se encuentra una descripción detallada de cada etiqueta de los estándares SOAP y WSDL. ¿Vale la pena hacerlo? En mi opinión no, porque... todo esto se crea automáticamente en Java, y solo necesitas escribir el contenido de los métodos que se supone que deben llamarse de forma remota. Entonces, apareció una API como JAX-RPC en Java. Si alguien no lo sabe, cuando dice que Java tiene tal o cual API, significa que hay un paquete con un conjunto de clases que encapsulan la tecnología en cuestión. JAX-RPC evolucionó con el tiempo de una versión a otra y finalmente se convirtió en JAX-WS. Obviamente, WS significa WebService y uno podría pensar que esto es simplemente un cambio de nombre de RPC como palabra de moda popular en estos días. Esto no es cierto, porque Ahora los servicios web se han alejado de la idea original y le permiten no solo llamar a métodos remotos, sino también simplemente enviar mensajes de documentos en formato SOAP. Todavía no sé por qué es necesario; es poco probable que la respuesta aquí sea "por si acaso es necesario". A mí mismo me gustaría aprender de camaradas más experimentados. Y por último, apareció JAX-RS para los llamados servicios web RESTful, pero este es el tema de un artículo aparte. La introducción puede terminar aquí, porque... A continuación aprenderemos a trabajar con JAX-WS.

Enfoque general

En los servicios web siempre hay un cliente y un servidor. El servidor es nuestro servicio web y a veces se le llama punto final (como en el punto final al que llegan los mensajes SOAP del cliente). Necesitamos hacer lo siguiente:

1. Describe la interfaz de nuestro servicio web.
2. Implementar esta interfaz
3. Lanzar nuestro servicio web
4. Escriba un cliente y llame de forma remota al método de servicio web deseado

Puede iniciar un servicio web de diferentes maneras: describir una clase con el método principal e iniciar el servicio web directamente como un servidor, o implementarlo en un servidor como Tomcat o cualquier otro. En el segundo caso, nosotros mismos no iniciamos un nuevo servidor ni abrimos otro puerto en la computadora, sino que simplemente le decimos al contenedor de servlets Tomcat que “hemos escrito clases de servicios web aquí, publíquelas para que todos los que se comuniquen con usted puedan utilice nuestro servicio web." Independientemente del método de lanzamiento del servicio web, tendremos el mismo cliente.

Servidor

Lancemos IDEA y creemos un nuevo proyecto. Crear nuevo proyecto. Indiquemos el nombre HolaWebService y presione el botón Próximo, luego botón Finalizar. en una carpeta src creemos un paquete ru.javarush.ws. En este paquete crearemos la interfaz HelloWebService: paquete ru. javarush. ws; // estas son anotaciones, es decir una forma de marcar nuestras clases y métodos, // en relación con la tecnología de servicios web importar javax. jws. Método Web; importar javax. jws. Servicio web; importar javax. jws. jabón. Encuadernación SOAP; // decimos que nuestra interfaz funcionará como un servicio web@ServicioWeb // decimos que el servicio web se utilizará para llamar a métodos@SOAPBinding (estilo = SOAPBinding. Estilo. RPC) interfaz pública HelloWebService ( // decimos que este método se puede llamar de forma remota@WebMethod public String getHelloString(nombre de cadena); ) En este código, las clases WebService y WebMethod son las llamadas anotaciones y no hacen nada más que marcar nuestra interfaz y su método como un servicio web. Lo mismo se aplica a la clase SOAPBinding. La única diferencia es que SOAPBinding es una anotación con parámetros. En este caso, el parámetro de estilo se utiliza con un valor que indica que el servicio web no funcionará a través de mensajes de documentos, sino como un RPC clásico, es decir. para llamar a un método. Implementemos nuestra lógica de interfaz y creemos una clase HelloWebServiceImpl en nuestro paquete. Por cierto, observo que finalizar una clase con Impl es una convención en Java, según la cual la implementación de interfaces se designa así (Impl - de la palabra implementación, es decir, implementación). Esto no es un requisito y usted es libre de nombrar la clase como quiera, pero los buenos modales lo requieren: paquete ru. javarush. ws; // la misma anotación que cuando se describe la interfaz, importar javax. jws. Servicio web; // pero aquí se usa con el parámetro endpointInterface,// indicando el nombre completo de la clase de interfaz de nuestro servicio web @WebService(interfazpunto final="ru.javarush.ws.HelloWebService" src) la clase pública HelloWebServiceImpl implementa HelloWebService ( @Override public String getHelloString (nombre de cadena) ( // solo devuelve el saludo devolver "Hola, " + nombre + "!" ; ) ) Lancemos nuestro servicio web como un servidor independiente, es decir. sin la participación de ningún Tomcat ni servidores de aplicaciones (este es un tema para una discusión aparte). Para hacer esto, en la estructura del proyecto en la carpeta importar ru. javarush. ws. HolaWebServiceImpl; clase pública HelloWebServicePublisher (public static void main (String... args) ( // inicia el servidor web en el puerto 1986 // y a la dirección especificada en el primer argumento,// inicia el servicio web pasado en el segundo argumento Punto final. publicar("http://localhost:1986/wss/hola" , nuevo HelloWebServiceImpl () );) ) Ahora ejecutemos esta clase haciendo clic

Mayús+F10

. No aparecerá nada en la consola, pero el servidor se está ejecutando. Puede verificar esto escribiendo la línea http://localhost:1986/wss/hello?wsdl en su navegador. La página que se abre, por un lado, demuestra que tenemos un servidor web (http://) ejecutándose en el puerto 1986 de nuestro ordenador (localhost) y, por otro lado, muestra una descripción WSDL de nuestro servicio web. Si detiene la aplicación, la descripción dejará de estar disponible, al igual que el servicio web en sí, por lo que no haremos esto, sino que pasaremos a escribir el cliente. src Cliente En la carpeta del proyecto Creemos un paquete ru.javarush.client y en él la clase HelloWebServiceClient con el método principal: paquete ru. javarush. cliente;// necesario para obtener la descripción wsdl y atravesarla // llegar al propio servicio web importar java. neto. URL; // esta excepción ocurrirá cuando se trabaje con un objeto URL importar java. neto. Excepción de URL con formato incorrecto;// clases para analizar xml con descripción wsdl // y alcanza la etiqueta de servicio que contiene importar javax. xml. espacio de nombres. QNombre; importar javax. xml. ws. Servicio;// interfaz de nuestro servicio web (necesitamos más) importar ru. javarush. ws. HolaWebService;) ; clase pública HelloWebServiceClient (public static void main (String args) lanza MalformedURLException ( // crea un enlace a la descripción wsdl URL URL = nueva URL ("http://localhost:1986/wss/hola?wsdl" // Observamos los parámetros del siguiente constructor en la primera etiqueta de la descripción WSDL: definiciones// mira el primer argumento en el atributo targetNamespace // mira el segundo argumento en el atributo de nombre QName qname = nuevo QName ("http://ws.site/", "HelloWebServiceImplService");// Ahora podemos acceder a la etiqueta de servicio en la descripción de wsdl, Servicio servicio = Servicio. crear (url, nombreq); Sistema. afuera. println (hola. getHelloString ("JavaRush"));

) ) Di el máximo de comentarios sobre el código en el listado. No tengo nada que agregar, así que ejecutemos (Shift+F10). Deberíamos ver el texto en la consola: ¡Hola, JavaRush! Si no lo vio, probablemente olvidó iniciar el servicio web.

Conclusión Este tema proporcionó una breve excursión a los servicios web. Una vez más, diré que gran parte de lo que escribí son mis suposiciones sobre cómo funciona y, por lo tanto, no debes confiar demasiado en mí. Agradecería que personas con conocimientos me corrigieran, porque así aprenderé algo.

UPD.

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.

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.

Como parámetros se pueden pasar no sólo tipos simples, sino también objetos y 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 (cuáles son los 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, la descripción de métodos y tipos se produce automáticamente. Aquellos. el programador en el servidor solo necesita decir que este método se puede llamar a través de un servicio web y la descripción wsdl se generará automáticamente.

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. Usando esta descripción, el cliente puede construir su propia estructura interna de clases de objetos, la llamada. 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);

• 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

También hay muchas desventajas:

• Tamaño de mensaje excesivamente grande. 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 para redes locales tiene más demanda; en particular, Sharepoint tiene un servicio web de jabón con el que puede comunicarse con éxito (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 se admite la compatibilidad con métodos antiguos, 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, también hay una descripción textual de los métodos para desarrolladores externos.
• http://86.57.245.235/TimeTable/Service.asmx?WSDL: descripción wsdl de 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" ru

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.

Historia de la creación

Con la llegada de las computadoras personales, también apareció la necesidad de combinarlas. Al principio eran simples conexiones por cable, luego aparecieron protocolos de red que unían computadoras que ejecutaban el mismo sistema operativo, con el desarrollo de la tecnología desapareció la necesidad de tener un sistema operativo en todas las computadoras y fue posible combinar computadoras con diferentes sistemas operativos; Internet ha cambiado la velocidad del avance en el camino de la unificación.

Pero aún hoy no se han resuelto todos los problemas de integración; lamentablemente no existía un protocolo único para la comunicación entre aplicaciones y servicios de Internet. Para resolver este problema, empresas como Microsoft, DevelopMentor, UserLand Software, IBM y Lotus Development se unieron y, como resultado de sus actividades conjuntas, se creó el Protocolo simple de acceso a objetos, un protocolo simple de acceso a objetos que describe un estándar para procedimientos remotos. llamadas basadas en el lenguaje XML (lenguaje de marcado extensible - lenguaje de marcado extensible). SOAP está diseñado para simplificar enormemente el desarrollo de aplicaciones en varios idiomas y herramientas de integración empresarial. Los inicios se hicieron con SOAP 1.0, que requería el protocolo HTTP para funcionar.

Después de la aparición de la versión inicial de SOAP, creada, como ya se señaló, gracias al esfuerzo conjunto de Microsoft, DevelopMentor y UserLand, IBM y Lotus se unieron al desarrollo del producto. Como resultado, la especificación ha sido objeto de una importante revisión para adaptarse mejor a la integración de entornos heterogéneos. La principal diferencia entre la siguiente versión de SOAP 1.1 y la versión inicial fue la transición de XML-Data de Microsoft a XML Schema. Además, en la nueva versión la especificación ya no depende de los protocolos de transporte. SOAP 1.0 requería el protocolo HTTP, mientras que para SOAP 1.1 el tipo de transporte no importa: puede usar correo electrónico o enlaces de mensajes para reenviar mensajes. Las empresas que ya habían adoptado SOAP 1.0 se encontraron atadas a la tecnología no estándar de Microsoft. Sin embargo, varios productos prometedores de esta corporación, incluidos BizTalk Server y SQL Server 7.0, también se basan en XML-Data. Con la llegada de la versión 1.1, el círculo de partidarios del protocolo SOAP se está ampliando.

La versión original de SOAP 1.1 presentada al Grupo de Trabajo Técnico de Internet del IETF se basó en la tecnología de datos XML propuesta por Microsoft en enero de 1998. Sin embargo, durante el proceso de revisión de estándares del W3C, la estructura subyacente fue reemplazada por un esquema XML. Se pidió al World Wide Web Consortium que considerara SOAP 1.1 como un estándar potencial.

La última versión de la especificación SOAP (Protocolo simple de acceso a objetos) está disponible en el servidor web que atiende a los miembros del programa para desarrolladores de MSDN™ (http://msdn.microsoft.com/). SOAP es un protocolo abierto basado en estándares que define, basado en XML (lenguaje de marcado extensible), un formato común para la comunicación entre cualquier aplicación y servicio de Internet. Esta versión amplía las capacidades de SOAP para comunicaciones asincrónicas para incluir soporte no sólo para HTTP, sino también para protocolos de Internet como SMTP, FTP y TCP/IP. La última versión de la especificación SOAP ha recibido un amplio apoyo de empresas como ActiveState Tool Corp., Ariba Inc., BORN Information Services Inc., Commerce One Inc., Compaq Computer Corp., DevelopMentor Inc., Extensibility Inc., IBM, IONA Technologies PLC, Intel Corp., Lotus Development Corp., ObjectSpace Inc., Rogue Wave Software Inc., Scriptics Corp., Secret Labs AB, UserLand Software y Zveno Pty. Limitado. La especificación SOAP proporciona un mecanismo común para integrar servicios a través de Internet y/o intranets, independientemente del sistema operativo, modelo de objetos o lenguaje de programación utilizado. Basado en los estándares de Internet XML y HTTP, SOAP permite que cualquier aplicación nueva o existente se comunique entre sí. Los sitios web que admiten SOAP pueden convertirse en servicios web a los que se puede acceder mediante programación pura y que no requieren intervención humana. Una infraestructura única que permite la interacción directa entre aplicaciones conectadas a Internet abre nuevas oportunidades para integrar servicios y dispositivos, sin importar dónde se encuentren en Internet.

Servicios web y SOAP

Los servicios web y SOAP están diseñados para resolver los problemas de comunicación de aplicaciones multiplataforma. Este artículo le ayudará a conocer mejor estas nuevas tecnologías prometedoras.

¿Qué es el jabón?

Las tecnologías utilizadas actualmente para la llamada a métodos remotos (DCOM, CORBA/IIOP y RMI) son bastante difíciles de configurar y organizar la interacción. Esto conlleva problemas en el funcionamiento y funcionamiento de los sistemas distribuidos (problemas de seguridad, transporte a través de cortafuegos, etc.). Los problemas existentes se resolvieron con éxito mediante la creación de SOAP (Protocolo simple de acceso a objetos), un protocolo simple basado en XML para intercambiar mensajes en entornos distribuidos (WWW). Está diseñado para crear servicios web y métodos de llamada de forma remota. SOAP se puede utilizar con diferentes protocolos de transporte, incluidos HTTP, SMTP, etc.

¿Qué son los servicios web?

Los servicios web son funcionalidades y datos expuestos para su uso por aplicaciones externas que interactúan con los servicios a través de protocolos y formatos de datos estándar. Los servicios web son completamente independientes del lenguaje y la plataforma de implementación. La tecnología de servicios web es la piedra angular del modelo de programación .NET de Microsoft. Para demostrar las capacidades de SOAP, utilicé la implementación recientemente lanzada de SOAP Toolkit versión 2.0 de Microsoft. Cabe señalar que la versión actual de Toolkit es notablemente diferente de la anterior (Microsoft SOAP Toolkit para Visual Studio 6.0) y de la versión beta de SOAP Toolkit 2.0.

Mecanismo de interacción entre cliente y servidor.

1. La aplicación cliente crea una instancia del objeto SOAPClient
2. SOAPClient lee archivos de descripción de métodos de servicios web (WSDL y metalenguaje de servicios web - WSML). Estos archivos también se pueden almacenar en el cliente.
3. La aplicación cliente, utilizando las capacidades de enlace tardío del objeto SOAPClient, llama al método de servicio. SOAPClient genera un paquete de solicitud (sobre SOAP) y lo envía al servidor. Se puede utilizar cualquier protocolo de transporte, pero normalmente se utiliza HTTP.
4. El paquete toma una aplicación de servidor de escucha (puede ser una aplicación ISAPI o una página ASP), crea un objeto SOAPServer y le pasa el paquete de solicitud.
5. SOAPServer lee la descripción del servicio web, carga la descripción y solicita el paquete en árboles DOM XML
6. SOAPServer llama a un método del objeto/aplicación que implementa el servicio
7. El objeto SOAPServer convierte los resultados de la ejecución del método o la descripción del error en un paquete de respuesta y lo envía al cliente.
8. El objeto SOAPClient analiza el paquete recibido y devuelve a la aplicación cliente los resultados del servicio o una descripción del error ocurrido.

Un archivo WSDL es un documento XML que describe los métodos proporcionados por un servicio web. También parámetros de métodos, sus tipos, nombres y ubicación del servicio Listener. El asistente del kit de herramientas SOAP genera automáticamente este documento.

Sobre SOAP (paquete): un documento XML que contiene una solicitud/respuesta para ejecutar un método. Lo más conveniente es considerarlo como un sobre postal en el que se incluye información. La etiqueta del sobre debe ser el elemento raíz del paquete. El elemento Encabezado es opcional, pero el elemento Cuerpo debe estar presente y ser un hijo directo del elemento Sobre. Si se produce un error de ejecución del método, el servidor genera un paquete que contiene un elemento Fault en la etiqueta Body, que contiene una descripción detallada del error. Si utiliza las interfaces de alto nivel SOAPClient, SOAPServer, entonces no tiene que entrar en las complejidades del formato del paquete, pero, si lo desea, puede utilizar interfaces de bajo nivel o incluso crear un paquete con sus propias manos.

El modelo de objetos SOAP Toolkit permite trabajar con objetos API de bajo nivel:

• SoapConnector: proporciona trabajo con el protocolo de transporte para el intercambio de paquetes SOAP.
• SoapConnectorFactory: proporciona un método para crear un conector para el protocolo de transporte especificado en el archivo WSDL (etiqueta).
• SoapReader: lee mensajes SOAP y crea árboles DOM XML
• SoapSerializer: contiene métodos para crear un mensaje SOAP
• IsoapTypeMapper, SoapTypeMapperFactory: interfaces que le permiten trabajar con tipos de datos complejos

Al utilizar objetos API de alto nivel, solo puede transferir datos de tipos simples (int, srting, float...), pero la especificación SOAP 1.1 le permite trabajar con tipos de datos más complejos, como matrices, estructuras, listas y sus combinaciones. Para trabajar con estos tipos, debe utilizar las interfaces IsoapTypeMapper y SoapTypeMapperFactory.

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. Las etiquetas de esta implementación XML, las reglas para formatear el documento XML y el orden en el que se intercambian los documentos están definidos por el protocolo SOAP. El protocolo SOAP fue creado en 1998 por un equipo de desarrolladores liderado por Dave Winer, que trabajaba 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.

La especificación SOAP en funcionamiento 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. El borrador más reciente 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 era 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 un elemento opcional que contiene el encabezado del mensaje y un elemento obligatorio. , 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 resumen, la estructura general de un 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, introducir un servidor intermedio que verifica la firma digital y definir este rol 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 el 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 un atributo xml opcional: 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 debido a motivos internos.

La versión 1.2 define cinco tipos de errores.

VersionMismatch: el espacio de nombres no se reconoce. Puede que esté desactualizado, que su nombre esté mal escrito o que haya un nombre de elemento XML en el mensaje que no esté definido en ese espacio de nombres. El servidor escribe el elemento en el encabezado de respuesta. , enumerando elementos anidados nombres de espacios de nombres correctos entendidos 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

detallan tipos estándar y mensajes sobre ellos aparecen en 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 utilizando Java. - San Petersburgo: BHV-Petersburg, 2003. - 400 p.: ill.

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. El mensaje SOAP en sí es un documento XML que contiene primero un sobre SOAP y luego un elemento XML que especifica el espacio de nombres y los atributos de SOAP, si los hay. 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.