¿Qué son WSDL, SOAP y REST? Protocolo SOAP. Conceptos básicos. Estructura del mensaje SOAP

10 respuestas

WSDL es un documento XML que describe un servicio web. En realidad, significa lenguaje de definición de servicios web.

SOAP es un protocolo basado en XML que permite intercambiar información a través de un protocolo específico (como HTTP o SMTP) entre aplicaciones. Significa Protocolo simple de acceso a objetos y utiliza XML como formato de mensajería para transmitir información.

REST es un estilo arquitectónico para sistemas en red y significa transferencia de estado representativo. No es un estándar en sí, sino que utiliza estándares como HTTP, URL, XML, etc.

Cada vez que alguien menciona SOAP/WSDL pienso en objetos y clases definidas en xml...

"Se usa SOAP como cualquier clase de PHP. Sin embargo, en este caso la clase no existe en el sistema de archivos local de la aplicación, sino en el host remoto, al que se accede a través de http".... "Si estamos pensando en usar SOAP- servicio como otra clase PHP, entonces el documento WSDL es una lista de todos los métodos y propiedades disponibles de la clase".

Y cada vez que alguien habla de REST, pienso en comandos HTTP (métodos de solicitud) como POST, GET y DELETE.

Ejemplo: en palabras simples, si tienes un servicio web de calculadora.

WSDL: WSDL habla de la funcionalidad que puede implementar o exponer al cliente. Por ejemplo: sumar, eliminar, restar, etc.

SOAP: Cuando se utiliza SOAP, en realidad se realizan acciones como doDelete(), doSubtract(), doAdd(). Entonces SOAP y WSDL son manzanas y naranjas. No deberíamos compararlos. Ambos tienen su propia funcionalidad.

Por qué utilizamos SOAP y WSDL: para intercambiar datos independientes a través de la plataforma.

EDITAR: En la vida cotidiana normal:

WSDL: Cuando vamos a un restaurante, vemos elementos del menú, esto es WSDL.

Clases de proxy: Ahora, después de mirar los elementos del menú, tomamos la decisión (procesamos nuestra vista en el orden): Entonces, básicamente creamos clases Proxy basadas en el documento WSDL.

JABÓN: Luego, cuando realmente pedimos comida según el menú: se da a entender que usamos clases proxy para llamar a métodos de servicio que se realizan usando SOAP :)

SOAP → SOAP (Prototipo de acceso a objetos simples) es una capa de aplicación basada en protocolo diseñada para la comunicación de máquina a máquina. El protocolo define las reglas estándar. Todas las partes que utilizan un protocolo particular deben cumplir con las reglas del protocolo. Al igual que TCP, se desenrolla en la capa de transporte. El protocolo SOAP se entenderá a nivel de aplicación (cualquier aplicación que soporte SOAP - Axis2,.Net).

WSDL -> El mensaje SOAP consta de SoapEnevelope->SoapHeader y SoapBody. ¿No define cuál será el formato del mensaje? ¿Cuáles son todos los transportes (HTTP, JMS) compatibles? sin esta información. Es difícil para cualquier cliente que quiera utilizar un servicio web específico para crear un mensaje SOAP. Incluso si lo hacen, no estarán seguros de que funcionará todo el tiempo. WSDL es un salvavidas. WSDL (Lenguaje de descripción de servicios web) define las operaciones, los formatos de mensajes y los datos de transporte de un mensaje SOAP.

REST → REST (Transferencia de Estado de Representación) se basa en el transporte. A diferencia de SOAP, que está orientado a la acción, REST está más orientado a los recursos. REST encuentra recursos usando una URL (ejemplo -http://(serverAddress)/employees/employeeNumber/12345) y depende del protocolo de transporte (con HTTP-GET, POST, PUT, DELETE,...) para que las acciones realicen recursos . El servicio REST encuentra un recurso según la URL y realiza una acción según el verbo de acción de transporte. Se trata más de estilo arquitectónico y convenciones.

SOAP significa Protocolo de acceso a objetos simple (sic). Estaba destinado a realizar llamadas a procedimientos remotos a objetos remotos enviando XML a través de HTTP.

WSDL es un lenguaje de descripción de servicios web. Una solicitud que finaliza en un punto final ".wsdl" dará como resultado la presentación de un mensaje XML que describe la solicitud y la respuesta que se puede esperar que se utilice. Describe el contrato entre el servicio y el cliente.

REST utiliza HTTP para enviar mensajes a los servicios.

SOAP es una especificación, REST es un estilo.

No vas a entender "simplemente" algo complejo.

WSDL es un lenguaje basado en XML para describir un servicio web. Describe los mensajes, operaciones e información de la red de transporte utilizados por el servicio. Estos servicios web suelen utilizar SOAP, pero pueden utilizar otros protocolos.

WSDL es legible por un programa y, por lo tanto, puede usarse para generar todo o parte del código de cliente necesario para llamar a un servicio web. Esto es lo que significa llamar a los servicios web orientados a SOAP "autodescriptivos".

REST no está relacionado en absoluto con WSDL.

Wikipedia dice: "El lenguaje de descripción de servicios web es un lenguaje basado en XML que proporciona un modelo para describir servicios web". En otras palabras, WSDL se refiere a un servicio web como javadoc se refiere a la biblioteca java.

Sin embargo, una cosa muy buena de WSDL es que el software puede generar clientes y servidores utilizando WSDL.

Brett McLaughlin Traducción de Ilya Chekmenev

SOAP es el protocolo simple de acceso a objetos. Si nunca antes has oído hablar de él, entonces debes vivir en medio de la nada, lejos de la civilización. Se ha convertido en la última moda en programación web, y en parte integral de los servicios web, que con tanto fanatismo se utilizan en los desarrollos web de última generación. Si ha oído hablar de .NET de Microsoft, o la "revolución" peer-to-peer, entonces habrá oído hablar de tecnologías que dependen de SOAP (incluso si no sabe qué es). No hay uno, pero dos Implementaciones SOAP de Apache y Microsoft, que tienen miles de páginas dedicadas a ellas en su sitio de soporte MSDN (http://msdn.microsoft.com/).

En este artículo te contaré qué es SOAP y por qué es una parte tan importante en el desarrollo del paradigma de programación web. Esto le ayudará a saltarse los conceptos básicos y empezar a trabajar directamente con el kit de herramientas SOAP. Luego daré una descripción general rápida de los proyectos SOAP existentes y profundizaré en la implementación de Apache. Este artículo no pretende proporcionar una imagen completa de SOAP; mi libro, Java & XML, segunda edición, llena muchos de los vacíos. Encontrará respuestas a muchas de las preguntas que surgieron después de leer este artículo en el libro.

Introducción

Primero necesitas entender qué es SOAP. Puede leer la opinión completa (y bastante extensa) del W3C en http://www.w3.org/TR/SOAP. Luego, habiéndolo descubierto y descartado toda la cáscara, comprenderá que SOAP es solo un protocolo. Es un protocolo simple (no es necesario escribir uno nuevo para usarlo) basado en la idea de que en algún punto de una arquitectura distribuida existe la necesidad de intercambiar información. Además, para sistemas en los que existe posibilidad de sobrecargas y dificultades en el procesamiento de procesos, este protocolo resulta muy ventajoso porque es ligero y requiere una cantidad mínima de recursos. Finalmente, permite que todas las operaciones se realicen a través de HTTP, lo que permite evitar cosas tan complicadas como los firewalls y protegerse de las escuchas mediante sockets en una increíble cantidad de puertos. Lo principal es que te des cuenta de esto, y todo lo demás son detalles.

Por supuesto, le gustaría conocer estos detalles y no los ignoraré. Hay tres componentes básicos en la especificación SOAP: un sobre SOAP, un conjunto de reglas de cifrado y un medio de interacción entre la solicitud y la respuesta. Pensemos en un mensaje SOAP como una carta normal. ¿Aún recuerdas esas cosas antiguas en sobres con un sello postal y la dirección escrita en el frente? Esta analogía le ayudará a comprender más claramente el concepto de SOAP como "sobre". La Figura 12-1 muestra los procesos SOAP en forma de esta analogía.

Figura 12-1. Proceso de mensajes SOAP

Tenga esta imagen en mente y veamos los tres componentes de la especificación SOAP. Hablaré brevemente de cada uno de ellos, dando ejemplos que mejor representen el concepto. Estos tres componentes clave hacen que SOAP sea tan importante y significativo. El manejo de errores, la compatibilidad con varios cifrados, la serialización de parámetros y el hecho de que SOAP funcione a través de HTTP en la mayoría de los casos lo hacen más atractivo que otras soluciones para protocolos distribuidos.

SOAP proporciona un alto grado de interoperabilidad con otras aplicaciones, que cubrí con más detalle en mi libro. Por ahora, quiero centrarme en los elementos centrales de SOAP.

Un sobre SOAP es similar a un sobre de carta normal. Contiene información sobre el mensaje que se cifrará en la sección principal de SOAP, incluida información sobre el destinatario y el remitente, así como información sobre el mensaje en sí. Por ejemplo, el encabezado del sobre SOAP puede indicar cómo se debe procesar el mensaje. Antes de que una aplicación comience a procesar un mensaje, examina la información sobre el mensaje, incluso si puede procesarlo. A diferencia de la situación con las llamadas XML-RPC estándar (¿recuerdas? Los mensajes XML-RPC, el cifrado, etc., todo se combina en un único fragmento XML), con SOAP el procesamiento continuo se produce para aprender algo sobre el mensaje. Un mensaje SOAP típico también puede incluir un estilo de cifrado que ayudará al destinatario a procesar el mensaje. El ejemplo 12-1 muestra un sobre SOAP que termina con una especificación de codificación.

Ejemplo 12-1: Sobre SOAP

Plataforma improvisada http://www-106.ibm.com/developerworks/library/x-soapbx1.html

Como puede ver, el cifrado se establece dentro del sobre, lo que permite a la aplicación determinar (usando el valor del atributo estilo de codificación), si puede leer el mensaje entrante ubicado en el elemento Cuerpo. Asegúrese de que el espacio de nombres del sobre SOAP sea correcto; de lo contrario, los servidores SOAP que reciben su mensaje informarán un error de discrepancia de versión y no podrá comunicarse con ellos.

Cifrado

El segundo elemento importante de SOAP es la capacidad de cifrar tipos de datos personalizados. Con RPC (y XML-RPC), el cifrado solo se puede realizar en tipos de datos predefinidos que sean compatibles con el kit de herramientas XML-RPC que descargó. Cifrar otros tipos de datos requiere que usted mismo modifique el servidor y el cliente RPC. Con SOAP, se puede utilizar un esquema XML con bastante facilidad para especificar nuevos tipos de datos (utilizando la estructura tipo complejo, discutido en el Capítulo 2 de mi libro), y estos nuevos tipos se pueden representar en XML como parte de la sección principal de SOAP. Gracias a la integración del esquema XML, puede cifrar cualquier tipo de datos en un mensaje SOAP describiéndolo lógicamente en un esquema XML.

Llamar

La mejor manera de entender cómo funciona una llamada SOAP es compararla con algo con lo que esté familiarizado, como XML-RPC. Si recuerda, la llamada XML-RPC es similar al fragmento de código presentado en el Ejemplo 12-2.

Ejemplo 12-2. Llamada a XML-RPC

// Especificación del procesador XML (analizador) que se utilizará XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser"); // Especificando el servidor al que se realiza la conexión XmlRpcClient client = new XmlRpcClient("http://rpc.middleearth.com"); // Creando parámetros Vector params = new Vector(); params.addElement(número de vuelo); params.addElement(numSeats); params.addElement(tipo de tarjeta de crédito); params.addElement(creditCardNum); // Solicitar entradas booleanas compradas = (Boolean)client.execute("ticketCounter.buyTickets", params); // Procesa la respuesta

Creé un programa sencillo para pedir billetes de avión. Ahora observe el Ejemplo 12-3, que demuestra una llamada SOAP.

Ejemplo 12-3. Llamar a jabón

// Creando parámetros Vector params = new Vector(); params.addElement(new Parameter("Número de vuelo", Integer.class, Número de vuelo, nulo)); params.addElement(new Parameter("numSeats", Integer.class, numSeats, null)); params.addElement(new Parameter("creditCardType", String.class, creditCardType, null)); params.addElement(new Parameter("creditCardNumber", Long.class, creditCardNum, null)); // Creando un objeto de llamada Call call = new Call(); call.setTargetObjectURI("urna:xml-boletos-de-avión-de-hoy"); call.setMethodName("comprarEntradas"); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC); call.setParams(parámetros); // Respuesta de llamada res = call.invoke(new URL("http://rpc.middleearth.com"), ""); // Procesa la respuesta

Como puede ver, la llamada real representada por el objeto Llamar, residente de la memoria. Le permite especificar el destino de la llamada, el método de llamada, el estilo de cifrado, los parámetros y muchos otros parámetros que no se presentan en este ejemplo. Este es un mecanismo más flexible que el método XML-RPC, ya que le permite especificar explícitamente un conjunto de parámetros diferentes que están implícitamente definidos en XML-RPC. Más adelante en este artículo, aprenderá más sobre el proceso de llamada, incluido cómo SOAP maneja las solicitudes no válidas, la jerarquía de errores y, por supuesto, los resultados de la llamada devueltos.

Después de una introducción tan breve, ya sabes lo suficiente como para interesarte por esta cosa tan divertida. Ahora permítanme presentarles la implementación SOAP que voy a utilizar. Explicaré las razones por las que lo elegí y veré algunos ejemplos de código.

Ajustes

Ahora que has aprendido los conceptos básicos del concepto, es hora de la parte divertida: la programación. Para hacer esto, necesitará un proyecto o producto conveniente que sea más fácil de encontrar de lo que parece a primera vista. Si necesita un proyecto Java que proporcione capacidades SOAP, no necesita buscar mucho para encontrar uno. Hay dos grupos de productos: comerciales y gratuitos. Como en mi libro, evitaré mencionar productos comerciales. Esto no se debe en absoluto a que sean malos (al contrario, algunos son excelentes), sino a que me gustaría que cualquier lector pudiera probar cualquiera de los ejemplos expuestos. Esto se debe a la accesibilidad, que muchos productos comerciales no tienen. Debes pagar para usarlos, o usarlos temporalmente por un período de tiempo limitado después de descargarlos.

Por lo tanto, abordamos sin problemas los proyectos de código abierto. De este ámbito sólo puedo nombrar un producto: Apache SOAP. Se encuentra en http://xml.apache.org/soap y proporciona un conjunto de herramientas SOAP para Java. En el momento de escribir este artículo, se lanzó la versión 2.2, que puede descargar desde el sitio web de Apache. Es esta versión la que usaré en los ejemplos de este artículo.

Otras alternativas

Antes de continuar con la instalación y configuración de Apache SOAP, responderé algunas preguntas que quizás se le hayan ocurrido. Creo que he explicado bastante claramente las razones por las que no uso productos comerciales. Sin embargo, es posible que esté pensando en otros proyectos de código abierto o relacionados que le gustaría utilizar y se sorprende de que no haya comentado sobre ellos.

¿Qué pasa con IBM SOAP4J?

La primera en la lista de alternativas es una implementación de IBM: SOAP4J. El trabajo de IBM formó la base del proyecto Apache SOAP, justo cuando XML4J de IBM creció hasta convertirse en lo que ahora se conoce como el proyecto de analizador XML Apache Xerces. Se supone que la implementación de IBM será rediseñada, fusionándose con Apache SOAP. Lo mismo sucedió con XML4J de IBM: ahora solo proporciona paquetes en Xerces. Esto solo resalta las tendencias: los grandes fabricantes a menudo apoyan y usan proyectos OpenSource, en este caso ambos proyectos (Apache e IBM) usan la misma base de código.

¿Está Microsoft fuera del juego?

Por supuesto que no. Microsoft y su implementación SOAP, así como todo el movimiento .NET (que se analiza con más detalle en mi libro), son bastante importantes. Realmente quería pasar la mayor parte de mi tiempo analizando en detalle la implementación SOAP de Microsoft, pero solo admite objetos COM y no admite Java. Por estos motivos, dicha descripción no podría incluirse en un artículo sobre Java y XML. Sin embargo, Microsoft (a pesar de todas las quejas que nosotros, como desarrolladores, tenemos sobre esta empresa) ha realizado un trabajo importante en el campo de los servicios web, y cometerás un error si lo descartas sin pensarlo dos veces, guiado sólo por emociones crudas. Si necesita trabajar con componentes COM o Visual Basic, le recomiendo que intente utilizar el kit de herramientas SOAP de Microsoft, disponible en http://msdn.microsoft.com/library/default.asp?url=/nhp/Default .asp ?contentid=28000523 junto con muchos otros recursos SOAP.

¿Qué es el eje?

Aquellos de ustedes que siguen las actividades de Apache deben haber oído hablar de Apache Axis. Axis es un conjunto de herramientas SOAP de próxima generación también desarrollado bajo el paraguas de Apache XML. SOAP (una especificación, no una implementación específica), que últimamente se ha desarrollado rápida y radicalmente, es muy difícil de seguir. Intentar crear una versión de SOAP que cumpla plenamente con los requisitos actuales a medida que evolucionan también es todo un desafío. Como resultado, la versión actual de Apache SOAP ofrece una solución limitada por su diseño. Habiendo decidido que no valía la pena intentar rediseñar completamente la herramienta existente, los desarrolladores de Apache comenzaron a crear un proyecto basado en el nuevo código. Así nació Axis. El nombre SOAP también sufrió un cambio, primero de SOAP a XP y luego a XMLP. Luego, el nombre de la especificación se eliminó del nombre del nuevo SOAP y nació el nombre "Axis". Pero ahora parece que el W3C está volviendo al nombre de la especificación SOAP (versión 1.2 o 2.0), por lo que las cosas aún pueden cambiar y ¡habrá aún más confusión!

Piense en IBM SOAP4J como una arquitectura?1 del kit de herramientas SOAP. ¿Qué pasa con Apache SOAP (que se analiza en este artículo) como arquitectura? Y Axis representa la arquitectura ?3, una arquitectura de nueva generación. Este proyecto utiliza SAX mientras que Apache SOAP está basado en DOM. Además, Axis, a diferencia de Apache SOAP, proporciona un enfoque más fácil de usar para la interacción del usuario. Después de enumerar estas ventajas, quizás se pregunte por qué no elegí Axis como tema de estudio. Sería un poco prematuro. Actualmente, solo se está preparando para su lanzamiento la versión 0.51 de Axis. Esta aún no es una versión beta, ni siquiera una versión alfa. Me encantaría hablar sobre las nuevas funciones de Axis, pero no tendría ninguna posibilidad de convencer a su dirección de que puede utilizar software de código abierto sub-alfa para las necesidades críticas de su sistema. Así que decidí centrarme en algo que eres real. puedes usar ya Hoy- Jabón Apache. Creo que cuando se publique la versión final de Apache Axis, actualizaré este material en la próxima edición de mi libro. Hasta entonces, centrémonos en la solución que ya está disponible.

Instalación

Hay dos formas posibles de instalación de SOAP. La primera es iniciar un cliente SOAP utilizando la API SOAP para comunicarse con un servidor que pueda aceptar mensajes SOAP. La segunda forma es ejecutar un servidor SOAP que pueda recibir mensajes de un cliente SOAP. En esta sección he descrito ambos procedimientos.

Cliente

Para utilizar el cliente SOAP, primero debe descargar Apache SOAP, disponible en http://xml.apache.org/dist/soap. Descargué la versión 2.2 en formato binario (del subdirectorio versión-2.2). Luego debes descomprimir el contenido del archivo en un directorio de tu computadora. En mi caso fue el directorio javaxml2 (c:\javaxml2 en mi computadora con Windows /javaxml2 en mi computadora Mac OS X). Como resultado, los archivos se descomprimieron en /javaxml2/soap-2_2. También deberá descargar el paquete JavaMail disponible en Sun http://java.sun.com/products/javamail/. Será necesario que sea compatible con el protocolo de transferencia SMTP utilizado por Apache SOAP. Luego descargue Java Beans Activation Framework (JAF), también disponible en Sun http://java.sun.com/products/beans/glasgow/jaf.html. Basado en el supuesto de que ya tiene Xerces u otro analizador XML instalado y listo para usar.

Nota: Asegúrese de que su analizador XML sea compatible con JAXP y utilice el espacio de nombres correctamente. Lo más probable es que su analizador cumpla con estos requisitos. Si tiene problemas, es mejor volver a utilizar Xerces.

Nota: Utilice las últimas versiones de Xerces. La versión 1.4 y superior servirá. Hay varios errores con SOAP y Xerces 1.3(.1), por lo que desaconsejo el uso de esta combinación.

Descomprima los paquetes JavaMail y JAF y luego incluya sus archivos jar en su classpath así como en la biblioteca tarro de jabón. Cada uno de estos archivos jar debe estar ubicado en el directorio raíz del programa correspondiente o en un subdirectorio. /lib. Cuando termine su variable ruta de clases debería verse algo como esto:

$ echo $CLASSPATH /javaxml2/soap-2_2/lib/soap.jar:/javaxml2/lib/xerces.jar: /javaxml2/javamail-1.2/mail.jar:/javaxml2/jaf-1.0.1/activation.jar

Para Windows se verá así:

c:\>echo %CLASSPATH% c:\javaxml2\soap-2_2\lib\soap.jar;c:\javaxml2\lib\xerces.jar; c:\javaxml2\javamail-1.2\mail.jar;c:\javaxml2\jaf-1.0.1\activación.jar

Y finalmente agregue el directorio javaxml2/jabón-2_2/ a tu ruta de clases para ejecutar ejemplos SOAP. He descrito la configuración de varios ejemplos en este capítulo.

Servidor

Para crear un conjunto de componentes de servidor compatibles con SOAP, primero necesita un motor de servlet. Como en capítulos anteriores, utilicé Apache Tomcat (disponible en http://jakarta.apache.org/) como ejemplo para este capítulo. Deberá agregar todo lo que el cliente necesita ruta de clases servidor. La forma más sencilla de hacerlo es restablecer tarro de jabón, activación.jar Y correo.jar, así como su analizador, en el directorio de bibliotecas de su motor de servlet. Para Tomcat, este es el directorio /lib, que contiene bibliotecas para carga automática. Si desea brindar soporte para scripts (que no se analizan en este capítulo, pero sí en los ejemplos de Apache SOAP), debe poner bsf.jar(disponible en http://oss.software.ibm.com/developerworks/projects/bsf) y js.jar(disponible en http://www.mozilla.org/rhino/) en el mismo directorio.

Nota: Si estás usando Xerces con Tomcat, necesitarás repetir el truco que cubrí en el Capítulo 10. Cambiar nombre analizador.jar V z_parser.jar, A jaxp.jar V z_jaxp.jar para asegurarse de que xerces.jar y la versión incluida de JAXP se carga antes que cualquier otro analizador o implementación de JAXP.

Luego reinicie su motor de servlet, después de lo cual estará listo para escribir componentes del servidor SOAP.

Servlet de enrutador y cliente de administración

Además de las operaciones básicas, Apache SOAP incluye un servlet de enrutador y un cliente de administración. Incluso si no tienes intención de utilizarlos, te recomiendo que los instales para comprobar que SOAP está instalado correctamente. Este proceso depende del motor de servlet que esté utilizando, por lo que limitaré el proceso de instalación a Tomcat. Las instrucciones de instalación para algunos otros motores de servlet se pueden encontrar en http://xml.apache.org/soap/docs/index.html.

La instalación en Tomcat es muy sencilla: basta con coger el archivo jabon.guerra del directorio jabón-2_2/aplicaciones web y suéltelo en el directorio $TOMCAT_HOME/aplicaciones web- ¡y eso es todo! Para comprobar la instalación, introduzca la dirección en su navegador http://localhost:8080/soap/servlet/rpcrouter. Debería recibir una respuesta similar a la que se muestra en la Figura 12-2.

Figura 12-2. Servlet RPC del enrutador

Aunque el mensaje parece ser un mensaje de error, indica que todo está funcionando correctamente. Debería obtener la misma respuesta si dirige su navegador a la dirección del cliente del administrador: http://localhost:8080/soap/servlet/messagerouter.

Para terminar de probar el servidor y el cliente, asegúrese de haber seguido todas las instrucciones completamente. Luego ejecute la siguiente clase Java como se muestra a continuación para admitir la URL de su servlet para el servlet del enrutador RPC:

C:\>java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter list Servicios implementados:

Debería obtener una lista vacía de servicios como se muestra arriba. Si recibe algún mensaje, revise la larga lista de posibles errores disponible en http://xml.apache.org/soap/docs/trouble/index.html. Esta es la lista más completa de problemas que puede encontrar. Si recibe una lista vacía, significa que la configuración está completa y está listo para comenzar a ver los ejemplos proporcionados en este capítulo.

Empecemos

Hay tres etapas principales al escribir cualquier sistema basado en SOAP. Una vez enumerados, comentaré brevemente cada uno de ellos:

• Elegir entre mensajes SOAP-RPC y SOAP;
• Escribir u obtener acceso a un servicio SOAP;
• Escribir o acceder a un cliente SOAP.

El primer paso es elegir si utilizará SOAP para llamadas RPC (en las que se ejecuta un procedimiento remoto en el servidor) o mensajes (en los que el cliente simplemente envía información al servidor). Analizo estos procesos en detalle a continuación. Una vez que haya tomado esta decisión, deberá acceder o crear su propio servicio. Por supuesto, dado que todos somos profesionales de Java, este capítulo cubre cómo crear el suyo propio. Y finalmente, necesitas escribir un cliente para este servicio, ¡eso es todo!

¿RPC o mensajería?

Su primera tarea no tiene nada que ver con la programación y es más de diseño. Debe elegir si utilizará el servicio RPC o de mensajes. Asumiremos que está familiarizado con RPC (por ejemplo, leyendo uno de los capítulos de mi libro). El cliente ejecuta un procedimiento remoto en el servidor y luego recibe una respuesta. En este escenario, SOAP actúa como un sistema XML-RPC mejorado que proporciona un mejor manejo de errores y transferencia de tipos de datos complejos a través de la red. Ya está familiarizado con este concepto y, dado que los sistemas RPC son más fáciles de escribir en SOAP, comenzaré con ellos. Este artículo describe cómo crear un servicio RPC, un cliente RPC y cómo poner el sistema en acción.

Otra forma de trabajar SOAP se basa en el intercambio de mensajes. En lugar de realizar trámites remotos, se utiliza únicamente para intercambiar información. Como puedes adivinar, esta es una herramienta poderosa que no requiere que el cliente conozca los métodos individuales de ningún servidor. También hace que el modelado de sistemas remotos esté más aislado al permitir que los paquetes de datos (paquetes en sentido figurado, no en el sentido de red) se envíen a otros sistemas. Al mismo tiempo, otros sistemas no necesitan conocer las operaciones que se realizaron con estos datos. Este estilo es más complejo que la programación RPC, por lo que no lo describiré aquí. Lo encontrará en mi libro, junto con otros detalles de la interacción entre empresas. Primero, familiarícese con la programación SOAP-RPC.

Como la mayoría de los problemas de diseño, tomar esta decisión depende de usted. Analice su aplicación e intente determinar por qué necesita utilizar SOAP. Si tiene un servidor y un conjunto de clientes que realizan funciones comerciales específicas bajo demanda, entonces RPC es más adecuado para usted. En sistemas complejos en los que el intercambio de datos es más que simplemente realizar funciones comerciales específicas bajo demanda, el uso de mensajes SOAP es mucho más preferible.

servicio RPC

Ahora que las formalidades han terminado, es hora de actuar. Como sabes, en RPC necesitarás clases cuyos métodos se ejecutarán de forma remota.

Fragmentos de código

Comenzaré mirando algunos fragmentos de código para el servidor. Estos fragmentos son clases con métodos que se ejecutan para clientes RPC. Usé código de mi libro como ejemplos. En lugar de utilizar clases simples, elegí un ejemplo más complejo para demostrar las capacidades de SOAP lo más claramente posible. Entonces, utilicé la clase CD como ejemplo. Primero definimos el elemento. mapa para cada tipo de parámetro no estándar. Para atributo estilo de codificación, al menos en Apache SOAP 2.2. debe especificar el valor http://schemas.xmlsoap.org/soap/encoding/. Esta es actualmente la única codificación admitida. Debe especificar el espacio de nombres para el tipo definido por el usuario y luego el nombre de la clase con el prefijo del espacio de nombres para ese tipo. En nuestro caso, para estos fines utilicé un espacio de nombres ficticio y un prefijo simple " incógnita". Luego usando el atributo tipo java, establezca el nombre real de la clase Java (para este caso - javaxml2.CD). Y por último, kuralesil con atributos. java2XMLNombreClase Y xml2JavaNombreClase. Con su ayuda, se especifica una clase que se convierte de Java a XML y viceversa. Utilicé la increíblemente útil clase BeanSerializer, que también se incluye con Apache SOAP. Si su parámetro personalizado está en formato JavaBean, este serializador y deserializador le evitará tener que escribir el suyo propio. Necesitas una clase con un constructor predeterminado (recuerda, para la clase CD definí un constructor simple sin parámetros) y publicar todos los datos de esta clase usando métodos. conjuntoXXX Y obtenerXXX. porque clase CD satisface perfectamente todos estos requisitos, BeanSerializador Funciona perfecto.

Nota: que clase CD cumple con los requisitos BeanSerializador. no importa mucho. La mayoría de las clases se convierten fácilmente a este formato. Por lo tanto, recomiendo evitar escribir sus propios serializadores y deserializadores. Este es un dolor de cabeza adicional (nada complicado, pero sí demasiado laborioso) y le recomiendo que ahorre energía y utilice la conversión de beans en sus parámetros personalizados. En muchos casos, las conversiones de beans solo requieren un constructor predeterminado (sin parámetros) en su clase.

Ahora vamos a recrear frasco archivo y reinstale nuestro servicio:

(gandalf)/javaxml2/Ch12$ java org.apache.soap.server.ServiceManagerClient http://localhost:8080/soap/servlet/rpcrouter xml/CDCatalogDD.xml

Atención: Si deja su motor de servlet en ejecución y vuelve a alojar un servicio al mismo tiempo, deberá reiniciar el motor de servlet para habilitar las nuevas clases para el servicio SOAP y volver a alojar el servicio.

Ahora todo lo que queda es modificar el cliente para que utilice nuevas clases y métodos. El ejemplo 12-10 contiene una versión modificada de la clase de cliente CDAdder. Se resaltan los cambios realizados en la versión anterior.

Ejemplo 12-10: clase CDAdder actualizada

paquete javaxml2; importar java.net.URL; importar java.util.Vector; importar org.apache.soap.Constants; importar org.apache.soap.Fault; importar org.apache.soap.SOAPException; importar org.apache.soap.encoding.SOAPMappingRegistry; importar org.apache.soap.encoding.soapenc.BeanSerializer; importar org.apache.soap.rpc.Call; importar org.apache.soap.rpc.Parameter; importar org.apache.soap.rpc.Response; importar org.apache.soap.util.xml.QName; CDAdder de clase pública ( public void add (URL URL, título de cadena, artista de cadena, etiqueta de cadena) lanza SOAPException ( System.out.println("Agregar un CD con el título "" + título + "" artista "" + artista + "" estudio " + etiqueta); CD cd = nuevo CD (título, artista, sello); // Crea un objeto de llamada Llamada Llamada call = new Call(); call.setSOAPMappingRegistry(registro); call.setTargetObjectURI("urna:catálogo de cd"); call.setMethodName("agregarCD"); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);// Configuración de parámetros Vector params = new Vector(); params.addElement(nuevo parámetro("cd", CD.class, cd, null)); call.setParams(parámetros); public static void main(String args) ( if (args.length != 4) ( System.out.println("Plantilla: java javaxml2.CDAdder " + "\"[Título del CD]\" \"[Nombre del artista]\ " \"[CD de estudio]\""); try ( // URL del servidor SOAP al que se realiza la conexión URL url = new URL(args); // Obtener valores para el nuevo CD String title = args; Artista de cuerdas = argumentos; Etiqueta de cadena = argumentos;

// Agrega el CD CDAdder adder = new CDAdder(); CD:

sumador.add(url, título, artista, etiqueta);

) capturar (Excepción e) ( e.printStackTrace(); ) ) ) BeanSerializador El único cambio realmente interesante está en el mapeo de clases. CD// Asigna este tipo para que pueda usarse con SOAP SOAPMappingRegistry registro = new SOAPMappingRegistry(); Serializador BeanSerializer = nuevo BeanSerializer(); registro.mapTypes(Constants.NS_URI_SOAP_ENC, nuevo QName("urna:cd-catalog-demo", "cd"), CD.class, serializador, serializador); Así es como se puede codificar y transmitir un parámetro de usuario a través de la red. Ya te he dicho cómo es la clase. se puede utilizar para procesar parámetros en formato JavaBean, como la clase . Utilicé un descriptor de ubicación para indicarlos al servidor, aunque ahora necesito decirle al cliente que use este serializador y deserializador. Esta función la realiza la clase. SOAPMappingRegistro . Método tipos de mapas() toma la cadena cifrada (nuevamente, es mejor usar una constante para esto NS_URI_SOAP_ENC BeanSerializador) e información sobre el tipo de parámetro para el cual se debe utilizar la serialización especial. El QName se especifica primero. Es por eso que se utilizó el espacio de nombres extraño en el descriptor de alojamiento. Debe proporcionar la misma URN aquí, así como el nombre local del elemento (para este ejemplo, "CD") y luego el objeto Java. Llamar Clase clase que será serializada (.

CD.clase

) y finalmente una instancia de la clase para serialización y deserialización. Para este ejemplo, ambos casos implicarán una instancia. Una vez que todas estas configuraciones se hayan ingresado en el registro, notifique al objeto

usando el método setSOAPMapping-Registry() para ti. Todo se produce según el mismo modelo. Para ponerse a prueba, puede consultar los archivos de ejemplo de mi libro, que ya contienen estas clases actualizadas.

Nota: Puedes decidir eso porque la clase setSOAPMapping-Registry() no interactúa directamente con el objeto CD(devuelto por el método lista() el tipo importa tabla hash), entonces no es necesario realizar ningún cambio. Sin embargo, la clase devuelta tabla hash contiene instancias de objetos CD. Si SOAP no sabe cómo deserializarlos, el cliente arrojará un error. En este caso, para solucionar el problema debes especificar en el objeto Llamar Copiar Serializador BeanSerializer = nuevo BeanSerializer();.

Manejo eficiente de errores

Ahora que ha visto objetos personalizados y ha realizado llamadas RPC y demás, permítame hablar sobre un tema menos interesante: el manejo de errores. Con cualquier transacción de red, pueden ocurrir muchas fallas. El servicio no inicia, hay un error en el servidor, no se puede encontrar el objeto, faltan clases y muchos otros problemas. Hasta ahora simplemente he usado el método fallo.getString() para generar mensajes de error. Pero es posible que este método no siempre sea útil. Para verlo en acción, descomente el constructor. CDCatálogo:

Catálogo de CD público() ( //catálogo = nueva Hashtable(); // Crea un directorio addCD(new CD("Nickel Creek", "Nickel Creek", "Sugar Hill"));

addCD(nuevo CD("Let it Fall", "Sean Watkins", "Sugar Hill")); addCD(nuevo CD("Límites aéreos", "Michael Hedges", "Windham Hill")); addCD(nuevo CD("Taproot", "Michael Hedges", "Windham Hill")); tabla hash)

Vuelva a compilarlo, reinicie el motor de servlet y vuelva a alojarlo. Esto resultará en una excepción.

Excepción de puntero nulo cuando el constructor de la clase intenta agregar CD a no inicializado. Al iniciar el cliente aparecerá un mensaje de error, pero no será muy informativo: (gandalf)/javaxml2/build$ java javaxml2.CDLister http://localhost:8080/soap/servlet/rpcrouter Ver el directorio del CD actual. Error: no se puede resolver el objeto de destino: nulo Esta no es en absoluto la información que puede ayudar a identificar y corregir un error. Sin embargo, el marco hace frente correctamente al manejo de errores. Te acuerdas DOMFaultListener, que especificaste como el valor del elemento oyente de fallas? Ha llegado el momento de que entre en el juego. Objeto devuelto en caso de error Falla:

importar java.net.URL; importar java.util.Enumeration; importar java.util.Hashtable; importar java.util.Iterator; importar java.util.Vector; importar org.apache.soap.Constants; importar org.apache.soap.Fault; importar org.apache.soap.SOAPException; importar org.apache.soap.encoding.SOAPMappingRegistry; importar org.apache.soap.encoding.soapenc.BeanSerializer; importar org.apache.soap.rpc.Call; importar org.apache.soap.rpc.Parameter; importar org.apache.soap.rpc.Response; importar org.apache.soap.util.xml.QName;

Ahora hagamos cambios para manejar errores en el método list():

if (!response.generatedFault()) ( Parámetro returnValue = respuesta.getReturnValue(); Hashtable catalog = (Hashtable)returnValue.getValue(); Enumeración e = catalog.keys(); while (e.hasMoreElements()) ( Cadena título = (String)e.nextElement(); CD cd = (CD)catalog.get(título) System.out.println(" "" + cd.getTitle() + "" artista " + cd.getArtist(); + "estudios" + cd.getLabel()); else ( Fallo fallo = respuesta.getFault(); System.out.println("Error: " + fallo.getFaultString()); Entradas vectoriales = fallo.getDetailEntries();

for (Iterator i = entradas.iterator(); i.hasNext();) ( org.w3c.dom.Element entrada = (org.w3c.dom.Element)i.next(); System.out.println(entrada .getFirstChild().getNodeValue()); Usando el método obtenerEntradasDetalles() obtiene acceso al servicio SOAP y al servidor de datos sin procesar que respalda el problema. El código los reprocesa (normalmente solo hay un elemento, pero requiere mucha atención) e intercepta el DOM. Elemento

, contenido en cada entrada. Básicamente, aquí está el XML con el que estás trabajando: SOAP-ENV:Servidor.BadTargetObjectURI No se puede resolver el objetivo: nulo

¡Esto es lo que queremos! En otras palabras, el objeto Fault le da acceso a la parte del sobre SOAP que contiene errores. Además, Apache SOAP proporciona un seguimiento de la pila de Java cuando se producen errores, proporcionando la información detallada necesaria para corregirlos. Interceptando un elemento pilaTrace e imprimir el valor del nodo Texto

desde este elemento su cliente puede imprimir el seguimiento de la pila del servidor. Al compilar estos cambios y reiniciar el cliente obtendrá el siguiente resultado: (CDCatalog.java:14) en java.lang.Class.newInstance0(Método nativo) en java.lang.Class.newInstance(Class.java:237)

No es mucho mejor, pero al menos puedes ver algunos fragmentos de información de que ocurrió una excepción. addCD(nuevo CD("Límites aéreos", "Michael Hedges", "Windham Hill")); e incluso averiguar los números de línea en las clases de servidor en las que ocurrió este problema. El resultado de estos cambios recientes le ha dado una idea clara del problema de manejo de errores. Ahora deberías comprobar si hay errores en las clases de tu servidor. Sí, casi lo olvido, antes de eso no olvides volver a cambiar tu clase. CDCatálogo¡Para deshacernos de los errores que introdujimos intencionalmente para mayor claridad!

1. Se habla mucho sobre ejecutar SOAP sobre otros protocolos como SMTP (o incluso Jabber). El estándar SOAP no proporciona esto actualmente, pero es posible que se agreguen capacidades similares en el futuro. Por lo tanto, no se sorprenda si encuentra discusiones activas sobre este tema.

SOAP (Protocolo simple de acceso a objetos) Es un protocolo estandarizado para transferir mensajes entre un cliente y un servidor. Normalmente se utiliza junto con HTTP(S), pero también puede funcionar con otros protocolos de capa de aplicación (como SMTP y FTP).
Probar SOAP desde el punto de vista de las técnicas de prueba no es fundamentalmente diferente de trabajar con otras API, pero requiere una preparación preliminar (en términos de teoría de protocolos) y herramientas de prueba especiales. En este artículo, me gustaría formular una pequeña lista de verificación de conocimientos y habilidades necesarios, que será igualmente útil tanto para un evaluador de SOAP (que a menudo no tiene idea de qué agarrar después de configurar la tarea) como para un gerente que está obligados a evaluar los conocimientos de los evaluadores y desarrollar planes de formación.

Base teórica

El hecho de que SOAP sea un protocolo tiene muchas implicaciones para las pruebas: es necesario estudiar el protocolo en sí, los estándares y protocolos "primarios" en los que se basa y (según sea necesario) las extensiones existentes.

XML
XML es un lenguaje de marcado similar a HTML. Cualquier mensaje enviado/recibido vía SOAP es un documento XML en el que los datos están convenientemente estructurados y son fáciles de leer, por ejemplo:

Julia
natasha
Recordatorio
¡No olvides escribir un artículo!

Puede obtener más información sobre XML en w3schools o codenet (en ruso). Asegúrese de prestar atención a la descripción de los espacios de nombres (un método para resolver conflictos al describir elementos en XML); su uso es obligatorio en SOAP.

XSD
A la hora de trabajar, siempre es conveniente tener una descripción estandarizada de posibles documentos XML y comprobar su correcto llenado. Existe una definición de esquema XML (o XSD para abreviar) para este propósito. Las dos características principales de XSD para un probador son la descripción de tipos de datos y la imposición de restricciones sobre posibles valores. Por ejemplo, el elemento del ejemplo anterior puede hacerse opcional y limitarse a 255 caracteres usando XSD:

...







...

Extensiones de jabón
En su trabajo, también puede encontrar varias "extensiones" de SOAP, estándares como WS-*. Uno de los más habituales es WS-Security, que permite trabajar con cifrado y firmas electrónicas. A menudo, junto con él se utiliza WS-Policy, con el que puede gestionar los derechos de uso de su servicio.

Ejemplo de uso de WS-Security:

Alicia
6S3P2EWNP3lQf+9VC3emNoT57oQ=
YF6j8V/CAqi+1nRsGLRbuZhi
2008-04-28T10:02:11Z

Todas estas extensiones son estructuras bastante complejas que no se utilizan en todos los servicios SOAP; Es poco probable que su estudio detallado en la etapa inicial de dominio de las pruebas SOAP sea relevante.

Herramientas

Como ya comprenderás, SOAP es un asunto serio; para trabajar con él es necesario conocer la teoría y numerosos estándares. En la práctica, tal complejidad generaría costos laborales muy importantes (por ejemplo, habría que mirar el diagrama en un cuaderno cada vez y enviar solicitudes con curl). Por ello, se han creado herramientas para facilitar el trabajo con SOAP.

Editores XML/XSD
Un buen probador comienza a realizar pruebas en la etapa de redacción de la documentación, por lo que es conveniente utilizar editores especiales para probar circuitos. Los dos más famosos son Oxygen (multiplataforma) y Altova (solo Windows); A ambos se les paga. Se trata de programas muy potentes que los analistas utilizan activamente al describir servicios.

En mi práctica, tres funciones del editor resultaron útiles: visualización XSD, generación XML basada en XSD y validación XML basada en XSD.

1. Visualización XSD necesario para una representación visual del diagrama, lo que le permitirá identificar rápidamente los elementos y atributos requeridos, así como las restricciones existentes. Por ejemplo, para CheckTextRequest, el elemento de texto es obligatorio y los tres atributos son opcionales (el atributo de opciones tiene un valor predeterminado de cero).

La visualización es necesaria cuando hay muchos tipos y restricciones en el diagrama. Si sólo necesita esto y no quiere pagar por editores especiales, puede considerar alternativas gratuitas (por ejemplo, JDeveloper).

2. Generación XML basada en XSDútil cuando desea ver un ejemplo válido de un mensaje. Lo uso para experimentar rápidamente con posibles finalización de mensajes y probar los matices de cómo funcionan las restricciones.

3. Después de utilizar la función del punto 2, es útil realizar Validación XML contra XSD– es decir, verifique que el mensaje sea correcto. Juntas, las características 2 y 3 le permiten detectar defectos complicados en XSD incluso cuando el servicio en sí está en desarrollo.

Herramienta de prueba: SoapUI

Las pruebas SOAP casi siempre implican el uso de SoapUI. Puede leer sobre el uso de esta herramienta en varias fuentes (,), pero será más eficaz leer la documentación oficial. Identifico 8 niveles condicionales de competencia en SoapUI:

Nivel 1: puedo enviar solicitudes
Aprenda a crear un proyecto basado en WSDL. SoapUI puede generar todas las consultas necesarias para usted; Lo único que tienes que hacer es comprobar que están cumplimentados correctamente y pulsar el botón “Enviar”. Una vez que haya desarrollado las habilidades para crear consultas válidas, debe dominar el arte de crear consultas incorrectas que causan errores.

Nivel 2: puedo realizar conjuntos de pruebas y casos de prueba
Empiece a realizar minipruebas automáticas. Los kits de prueba y los casos de prueba le permiten crear scripts de prueba de API, preparar datos para solicitudes y verificar automáticamente la respuesta recibida para garantizar que coincida con lo esperado. Al principio, pueden usarse simplemente como colecciones de consultas. Por ejemplo, si ha creado un defecto y desea comprobarlo rápidamente después de solucionarlo, puede asignar un kit de prueba independiente específicamente para solicitudes de defectos.

Nivel 3: puedo escribir afirmaciones
Después de dominar los casos de prueba, le resultará útil aprender cómo hacerlos verificables automáticamente. Después de esto, ya no necesitará buscar información sobre la respuesta con los ojos: si hay una verificación automática, los casos se marcarán en verde (si se pasa la verificación) o en rojo (si no se pasa). SoapUI proporciona un gran conjunto de afirmaciones posibles, pero las más convenientes y simples son Contiene y No contiene. Con su ayuda, podrá comprobar la presencia de un texto específico en la respuesta recibida. Estas comprobaciones también admiten búsquedas de expresiones regulares.

Nivel 4: use XPath y/o XQuery en aserciones
Para aquellos que están un poco familiarizados con la interfaz de usuario usando Selenium, el lenguaje XPath es algo familiar. En términos generales, XPath le permite buscar elementos en un documento XML. XQuery es una tecnología similar que puede utilizar XPath internamente; este lenguaje es mucho más poderoso, se parece a SQL. Ambos lenguajes se pueden utilizar en Afirmaciones. Con su ayuda, las comprobaciones son más específicas y estables, por lo que sus casos gozarán de mayor confianza.

Nivel 5: puedo escribir pruebas complejas usando pasos especiales

Los casos de prueba pueden contener no solo una solicitud, sino también varias (por ejemplo, cuando desea emular el escenario de usuario estándar "crear entidad" → "exportar entidad"). Puede haber otros pasos especiales entre solicitudes, por ejemplo:

• Propiedades y transferencia de propiedad (ayuda a reutilizar datos y transferirlos entre solicitudes);
• Solicitud JDBC (utilizada para recuperar datos de la base de datos);
• Goto condicional (le permite hacer ramas o bucles en el caso de prueba);
• Ejecute TestCase (ayuda a colocar algunas consultas típicas en casos de prueba separados y llamarlas cuando sea necesario).

Nivel 6: uso de scripts Groovy

SoapUI te permite escribir scripts Groovy en una variedad de lugares. El caso más simple es generar datos en la consulta misma usando inserciones $(=). Utilizo estos insertos todo el tiempo:

• $(=nueva fecha().formato(“aaaa-MM-dd’T’HH:mm:ss”))– insertar la fecha y hora actuales en el formato requerido;
• $(=java.util.UUID.randomUUID())– para insertar un GUID aleatorio formado correctamente.

Los guiones completos se pueden utilizar como pasos en casos y verificaciones. En algún momento, descubrirás que varios pasos especiales del quinto nivel se pueden reemplazar con un guión.

Nivel 7: uso de MockServices
SoapUI basado en WSDL puede generar objetos simulados. Un objeto simulado es la simulación más simple de un servicio. Con la ayuda de "simulacros", puede comenzar a escribir y depurar casos de prueba incluso antes de que el servicio esté realmente disponible para realizar pruebas. También se pueden utilizar como “talones” para servicios que no están disponibles temporalmente.

Nivel 8 – Dios SoapUI
Conoce la diferencia entre las versiones paga y gratuita de SoapUI y utiliza la API de SoapUI en su código. Utiliza complementos y ejecuta casos a través de la línea de comando y/o CI. Sus casos de prueba son simples y fáciles de mantener. En general, con este instrumento te "comiste al perro". Me encantaría hablar con alguien que domine SoapUI a este nivel. Si eres uno, ¡regístrate en los comentarios!

Pruebas con lenguajes de programación

A continuación se muestra un ejemplo de cómo se ve una solicitud a la API de YandexSpeller, realizada con groovy-wslite:

importar wslite.soap.*
cliente def = nuevo SOAPClient("http://speller.yandex.net/services/spellservice?WSDL")
def respuesta = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
cuerpo (
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") (
texto("error")
}
}
}
afirmar "error" == respuesta.CheckTextResponse.SpellResult.error.s.text()
afirmar "1" == [correo electrónico protegido]()

Hasta donde yo sé, todavía no existen marcos de alto nivel (como Rest-assured) para las pruebas SOAP, pero recientemente ha aparecido una herramienta interesante: el karate. Con su ayuda, puede describir casos para probar SOAP y REST en forma de scripts como Cucumber / Gherkin. Para muchos evaluadores, recurrir al kárate será una solución ideal, porque tales escenarios, en términos de la complejidad de escribir y apoyar casos, se ubicarán en algún punto intermedio entre el uso de SoapUI y la escritura de su propio marco para probar SOAP.

Conclusión

Es poco probable que alguna vez quieras probar SOAP solo por ti mismo (como podrías hacerlo con REST). Este es un protocolo pesado que se utiliza en soluciones empresariales serias. Pero su pesadez es al mismo tiempo un regalo para el evaluador: todas las tecnologías utilizadas están estandarizadas y existen herramientas de trabajo de alta calidad. Todo lo que se requiere del evaluador es el deseo de aprenderlos y utilizarlos.

Reunimos la misma lista de verificación de habilidades necesarias para un evaluador. Entonces, si recién está comenzando a probar los servicios SOAP, necesita saber y poder utilizar:

• WSDL.
• JABÓN.
• Editores XML/XSD (a nivel de visualización XSD).
• SoapUI en el nivel 1.

Como puede ver, el énfasis principal está en aprender los estándares; en SoapUI basta con poder realizar consultas. A medida que se sumerja en las pruebas SOAP, encontrará tareas que requerirán habilidades y conocimientos más serios, pero no debe intentar aprender todo de una vez. La coherencia a la hora de aumentar el nivel de complejidad de las tareas realizadas es mucho más importante. ¡Siguiendo esta recomendación algún día te darás cuenta de que te has convertido en un buen especialista en este campo!

Historia de la creación

Con la llegada de las computadoras personales, surgió 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.

JABÓN- un protocolo de texto que utiliza XML para intercambiar mensajes estructurados en un entorno informático distribuido. Originalmente, SOAP estaba destinado principalmente a implementar llamadas a procedimientos remotos (RPC), y el nombre era un acrónimo: Protocolo simple de acceso a objetos. El protocolo se utiliza ahora para intercambiar mensajes arbitrarios en formato XML, y no sólo para llamar a procedimientos. La especificación oficial de la última versión 1.2 del protocolo no descifra el nombre SOAP de ninguna manera. SOAP es una extensión del protocolo XML-RPC. SOAP se puede utilizar con cualquier protocolo de capa de aplicación: SMTP, FTP, HTTP, etc. Sin embargo, su interacción con cada uno de estos protocolos tiene sus propias características que deben definirse por separado. La mayoría de las veces, SOAP se utiliza sobre HTTP. SOAP es uno de los estándares en los que se basan las tecnologías de servicios web. La comunicación entre los servicios web y sus clientes se realiza a través de mensajes en formato XML. SOAP (Protocolo simple de acceso a objetos) es un protocolo de mensajes para seleccionar servicios web. Podemos decir que el formato SOAP es ideal para la tecnología RPC (Llamada a Procedimiento Remoto), ya que el mensaje SOAP contiene parámetros enviados por el cliente o un valor de retorno enviado por el servicio.

Ventajas de utilizar el formato SOAP:

· Tipos de datos más flexibles.

· Soporte para encabezados y extensiones:

Defectos:

· El uso de SOAP para transmitir mensajes aumenta su volumen y reduce la velocidad de procesamiento. En sistemas donde la velocidad es importante, es más común enviar documentos XML a través de HTTP directamente, donde los parámetros de solicitud se pasan como parámetros HTTP normales.

· Aunque SOAP es un estándar, diferentes programas suelen generar mensajes en un formato incompatible. Por ejemplo, el servidor WebLogic no entenderá una solicitud generada por un cliente AXIS.

Conceptos básicos del protocolo: La parte que envía el mensaje SOAP se denomina remitente SOAP y la parte que lo recibe se denomina receptor SOAP. La ruta que sigue un mensaje SOAP desde el remitente original hasta el destinatario final se denomina ruta del mensaje. La ruta del mensaje contiene el remitente original, el destinatario final y 0 o más intermediarios SOAP. Los objetos que procesan mensajes según las reglas de protocolos SOAP específicos se denominan nodos SOAP. La unidad elemental de información que participa en el intercambio entre nodos SOAP se denomina mensaje SOAP; es un documento XML con un elemento raíz contenedor SOAP.