Servicio wsdl. Lenguaje de descripción de servicios web (WSDL): Andrew Troelsen. Enviar objetos complejos

Los elementos de extensión de enlace se utilizan para especificar una gramática específica para los mensajes de error (5) entrantes (3) y salientes (4). También se puede especificar información sobre el nivel de operación (2) y el nivel de vinculación (1).

El elemento de enlace de operación contiene datos para la operación del mismo nombre del tipo de puerto asociado. Sin embargo, el nombre de la operación en caso general no es único (ejemplo: sobrecarga de métodos/funciones, uso de los mismos nombres con diferentes firmas), por lo que puede no ser suficiente determinar de forma única la operación de destino del tipo de puerto. En tales casos, la operación objetivo se aborda utilizando tarea adicional los nombres de elementos wsdl:input y wsdl:output correspondientes utilizando el atributo de nombre.

Vinculante debería Instale solo un protocolo.

Vinculante no debería contener información de dirección.

Puerto

Un puerto define un único punto final estableciendo una dirección a la que vincularse.

1. <wsdl:definiciones .... >
2. <wsdl:servicio .... > *
3. <wsdl:puerto nombre = "nmtoken" enlace = "qname" > *
4. <-- extensibility element (1) -->
5. wsdl:puerto>
6. wsdl:servicio>
7. wsdl:definiciones>

El atributo de nombre especifica un nombre único entre todos los puertos dentro del documento WSDL. El atributo de enlace de tipo QName contiene una referencia al enlace (ver).

Los elementos de extensión (1) se utilizan para especificar la dirección.

Puerto no debería especifique más de una dirección.

Puerto no debería contener cualquier información vinculante distinta de una dirección.

Servicio

Un servicio agrupa un conjunto de puertos relacionados.

1. <wsdl:definiciones .... >
2. <wsdl:servicio nombre = "nmtoken" > *
3. <wsdl:puerto .... /> *
4. wsdl:servicio>
5. wsdl:definiciones>

El atributo de nombre especifica un nombre único entre todos los servicios definidos en el documento WSDL.

Los puertos dentro de un servicio se conectan de la siguiente manera:

• Los puertos no se comunican entre sí (es decir, la salida de un puerto no es la entrada de otro).
• Si un servicio tiene varios puertos que comparten tipo general puertos, pero utilizan enlaces diferentes o tienen direcciones diferentes, dichos puertos son alternativos. Cada uno de estos puertos implementa un comportamiento lógicamente equivalente (dentro de las restricciones de transporte y formato de mensaje impuestas por el enlace correspondiente). Esto permite al cliente seleccionar un puerto específico para la comunicación según varios criterios (soporte de protocolo de transporte, etc.).
• Al observar los puertos, puede determinar qué tipos de puertos admite el servicio. A partir de estos datos, el cliente puede determinar la capacidad de interactuar con un servicio específico. Esto es útil si existe una conexión entre operaciones de diferentes tipos de puertos y el servicio necesita admitir todos los tipos de puertos necesarios para realizar una determinada tarea.

1. Esta es una traducción gratuita, parcial y ampliada del documento Lenguaje de descripción de servicios web (WSDL) 1.1 del 15 de marzo de 2001.
2. Es extremadamente inconveniente trabajar con términos indeclinables escritos en latín y, además, están traducidos de forma inequívoca. Por lo tanto, el nombre original se da sólo cuando se introduce un nuevo término, y más adelante en el texto se utiliza la traducción al ruso.

En este artículo hablaré sobre qué es un archivo WSDL, por qué es necesario y cómo trabajar con él.

Mapa del artículo

¿Qué es WSDL?

WSDL es un lenguaje de descripción de servicios web que tiene estructura XML. El objetivo principal de un archivo WSDL es servir de interfaz para acceder a funciones de servicio y devolver tipos de datos; ruta al servidor que procesa solicitudes, etc.

La ruta al archivo wsdl suele verse así: http://host/services/wsdl/gbdar-v2-2.wsdl

Existen muchas herramientas y bibliotecas diseñadas para leer un archivo WSDL.

JabónUi

Una de esas herramientas es SoapUi(). Al instalar una distribución diseñada para su plataforma, puede crear nuevo proyecto por el equipo del proyecto File/New SoapUi. En el cuadro de diálogo para crear un nuevo proyecto, deje habilitada la casilla Crear solicitudes de muestra.

Ejecutando consultas

En el nuevo proyecto, se crearán automáticamente plantillas de solicitud para el servicio, cuya descripción está contenida en el archivo wsdl. A la izquierda del árbol verá una lista de funciones contenidas en el archivo WSDL. Expondré la función de replicación. En su interior hay una solicitud Solicitud1, al hacer doble clic en ella veremos un cuadro de diálogo con una plantilla de solicitud, en lugar de los parámetros predeterminados habrá signos de interrogación. Para que la función se ejecute correctamente, debe completar todos los parámetros no marcados con la etiqueta Opcional y luego hacer clic en el triángulo verde en la esquina superior izquierda del cuadro de diálogo.

Si todos los parámetros se especifican correctamente, la respuesta del servicio a la solicitud aparecerá a la derecha.

SoapUi brinda la posibilidad de ver los parámetros de un archivo WSDL; para hacer esto, debe hacer doble clic en el nombre de la interfaz (marcado con un icono verde en el árbol de archivos WSDL, para mí: gdbar-v2-2SOAP). En el cuadro de diálogo puede encontrar:

• Pestaña Descripción general - descripción parámetros generales WSDL, una lista de funciones y acciones de servidor asociadas
• Pestaña Puntos finales de servicio — ruta al servidor y otros parámetros
• Contenido WSDL - árbol de navegación de archivos
• Cumplimiento de WS-I — aquí puede crear un informe WS-I en la interfaz

Generación de documentación

SoapUi nos permite generar documentación de funciones WSDL. Para hacer esto, haga clic clic derecho a través de la interfaz y llame al comando Generar Documentación. Como resultado, recibiremos un manual detallado en formato html.

Eso es todo, suscríbete a nuevas publicaciones, deja comentarios, haz sugerencias para mejorar el artículo.

Una descripción estandarizada facilita su comprensión y uso. Digamos que ha encontrado un servicio que resuelve los problemas que necesita y desea utilizarlo en sus soluciones. La forma más sencilla de obtener información sobre el diseño de otra persona y sus capacidades es consultar la descripción WSDL. Los documentos WSDL pueden constar de varios módulos o hacer referencia a otros documentos o esquemas XML (XSD) que describen los tipos de datos utilizados en el servicio web. Inicialmente, se propusieron varias opciones para mantener una descripción y dos actores importantes, Microsoft e IBM, presentaron su visión de este problema. El primero desarrolló y propuso el SDL (Lenguaje de descripción de servicios), que se incluyó en la primera versión del SOAP Toolkit de la empresa. IBM presentó su visión del problema en Network NASSL (Lenguaje de especificación de servicios accesible), que se implementó en SOAP4J como un conjunto de herramientas NASSL. Las ideas propuestas en NASSL inspiraron a Microsoft a continuar desarrollando el lenguaje de descripción, lo que dio como resultado el nacimiento del lenguaje de contrato SOAP (SCL). Esta solución demostró ser muy eficaz, se perfeccionó teniendo en cuenta los deseos de terceros fabricantes y el 15 de marzo de 2001 la idea se convirtió en la especificación WSDL 1.1. Por supuesto, el campo de la informática no puede vivir tantos años sin cambios, por lo que la versión 2.0 apareció el 27 de marzo de 2006 y desde el 26 de junio de 2007 tiene un carácter consultivo.

Referencia de comandos de Unix/Linux

Historia

WSDL 1.0 (septiembre de 2000) fue desarrollado por IBM, Microsoft y Ariba para describir servicios web para el kit de herramientas SOAP.

WSDL 1.1, lanzado en marzo de 2001. De hecho, este es un WSDL 1.0 formalizado. No existen diferencias fundamentales entre estas versiones.

WSDL 1.2 (junio de 2003) todavía funciona bajo W3C. La mayoría de los proveedores de SOAP no admiten WSDL 1.2.

WSDL 2.0 recibió soporte oficial del W3C en junio de 2007. WSDL 1.2 pasó a llamarse WSDL 2.0 porque tenía importantes diferencias con la versión anterior.

Diseño de servicios web

El uso que hace el autor del término servicios web se refiere exclusivamente al tipo de tecnología que se centra en la interacción. Esto significa que esta tecnología está estandarizada: los sistemas heterogéneos sólo funcionan si existen estándares abiertos. En este caso, la pregunta relevante es: ¿serán los servicios web la solución a su problema? Hoy en día, la palabra “servicios web” ya no es suficiente para hablar de la reputación de la empresa que los utiliza, por lo que sería mejor si existieran otras razones de peso para utilizarlos. Si monitorea ambos extremos del canal, es posible que haya más tecnologías adecuadas. Ahora es sólo el comienzo de una era estándares abiertos procesamiento de datos distribuidos. Por lo tanto, el costo de respaldar los servicios web en este mercado aún no formado sigue siendo alto: esto significa una disminución de la productividad, un aumento de los costos de desarrollo y un deterioro de la seguridad. La idea de que los servicios web son “compatibles con los cortafuegos” es engañosa. De hecho, los cortafuegos convencionales protegen los activos corporativos de los "atacantes" que utilizan puntos débiles en el software de aplicación, resultante de la apertura de puertos en los que se ejecutan servicios protegidos. Por otro lado, los servicios web exponen el software de aplicación a través de estos puertos.

En otras palabras, debilitan la seguridad al permitir que personas no autorizadas accedan a las aplicaciones, exactamente lo que evitaría un firewall de red. Por tanto, se necesita una nueva generación de cortafuegos. Ya hay varios actores nuevos en el mercado que ofrecen este tipo de productos. Los proveedores de cortafuegos convencionales también están empezando a darse cuenta de este problema. Pero esto es sólo el comienzo y dicha tecnología aún tiene que demostrar su eficacia. Incluso si planea utilizar servicios web, debe recordar que no es necesario utilizar SOAP. Por ejemplo, el autor de este artículo ha visto formularios pasados ​​como argumento de solicitud de llamada a procedimiento remoto SOAP (SOAP-RPC). También encontró formularios que se devolvieron como parte de una respuesta de llamada a procedimiento remoto SOAP. Nunca pudo encontrar ningún beneficio adicional al usar SOAP. Si los componentes distribuidos se pueden desarrollar en diferentes lenguajes de programación, entonces se necesita un lenguaje de definición de interfaz (IDL) neutral para el lenguaje de programación para especificar cómo se deben utilizar los servicios. En CORBA ( Arquitectura general intermediario de solicitud de objetos, arquitectura común de intermediario de solicitud de objetos), como DCOM (modelo de objetos componentes distribuidos), existe dicho lenguaje. El IDL es un contrato entre el iniciador del servicio y el proveedor, pero sólo recopila la sintaxis. La semántica sigue sin estar clara: IDL deja abierta la cuestión de qué hace el servicio. WSDL es el IDL de los servicios web. Describe cómo llamar a servicios web. También define las respuestas que pueden recibirse o no cuando la llamada tiene éxito.

La especificación WSDL regula estrictamente el formato de los mensajes, los protocolos utilizados y la dirección donde se encuentran los servicios. Desafortunadamente, incluso una descripción clara y estricta en el WSDL no garantiza un diseño de alta calidad. Como todos los lenguajes IDL, WSDL es fuerte en sintaxis y débil en semántica. Sin embargo, no deben descuidarse: en última instancia, lo importante es la semántica, mientras que la sintaxis se utiliza simplemente para revelarla.

Diseño de interfaz

Antes de comenzar a escribir WSDL, debe acordar con sus clientes qué debe hacer el servicio web. Los casos de uso deben registrarse, definiendo claramente cómo interactúa el servicio con su entorno. Supongamos que un programa agente (actor) llama a un servicio web con algún propósito. En este caso, es necesario crear no sólo un escenario de “día soleado”, que implementa la tarea, sino también un escenario de “día lluvioso”, cuando el resultado es negativo. ¿Qué garantías puede ofrecer el sistema de que el objetivo se ha conseguido con éxito? ¿Y cuando no? ¿Dónde está la línea de responsabilidad entre el cliente y el servidor? No se puede subestimar la importancia de definir claramente los requisitos. En esta etapa vale la pena pensar en el propósito del proyecto. ¿Qué es exactamente? ¿Qué datos deben recibirse del cliente y qué debe proporcionar el servidor? Cometer un error en este paso puede generar costos importantes. Por ejemplo, considere un servicio web que toma como parámetros una lista de programas instalados y la cantidad de espacio libre en disco. Luego, este servicio debería devolver una lista de aplicaciones para actualizar.

Si hay suficiente espacio, no hay problemas. Sin embargo, ¿qué pasa si no es suficiente? ¿Cómo selecciono los productos para los que necesito instalar nuevas versiones? ¿Se supone que el cliente debe eliminar las versiones antiguas de los programas para dejar espacio a las nuevas? No son preguntas fáciles, cuya solución requerirá el desarrollo de algoritmos complejos, cuya implementación puede implicar errores. Por supuesto, ningún sistema debería definirse de esta manera. El servidor debe proporcionar una lista de aplicaciones, las dependencias entre ellas y los requisitos de recursos que requieren. Es responsabilidad del cliente decidir qué paquete instalar. Por tanto, al confiar esta tarea al servidor, el cliente no ganará nada; sólo aumentará los costes de desarrollo de la parte del servidor. Por lo tanto, es necesario analizar los costos de etapa inicial. En este caso, puede ignorar los detalles técnicos: el servicio puede verse como una caja negra. Pero no podemos descuidar los detalles sobre la interacción entre este servicio y su entorno. El siguiente paso es analizar cómo se pueden implementar los casos de uso.

¿Habrá una única interfaz (portType en WSDL versión 1.1) que proporcione todas las funciones? ¿O múltiples interfaces? Cada interfaz se puede ofrecer en múltiples puntos finales, pero generalmente debe ser indivisible. Es decir, el punto final debe proporcionar toda la funcionalidad o ninguna. Asimismo, la interfaz debe ser semánticamente consistente. Lo anterior pretende ser una guía y una cuestión de sentido común, aunque nada en la especificación WSDL impide una interpretación diferente. ¿Se requieren interfaces de soporte? ¿Cómo y cuándo deben convocarse? ¿Cuál es la naturaleza de esta dependencia? Todavía no existen estándares, sólo recomendaciones sobre cómo manejar las “coreografías de servicios”, cómo permitir que los servicios establezcan hipervínculos con otros servicios. En otras palabras, ésta es un área problemática inexplorada.

WSDL (Lenguaje de descripción de servicios web) la versión 1.1 se publicó el 15 de marzo de 2001. WSDL es un formato basado en XML que se utiliza para describir servicios web mediante mensajes que contienen información sobre cómo acceder a un servicio web específico. WSDL ampliable, que le permite describir servicios (servicios) y sus mensajes, independientemente de qué formatos de mensaje o protocolos de red se utilizan para el transporte, sin embargo, el más utilizado es WSDL 1.1 junto con SOAP 1.1, HTTP GET/POST y MIME. Desde WSDL fue desarrollado conjuntamente con SOAP, y en su desarrollo participaron las mismas empresas Microsoft, Ariba e IBM. Si consideramos el documento WSDL intuitivamente podemos decir que permite responde 4 preguntas:

1) ¿qué estás haciendo? La respuesta a esta pregunta se da en una forma adecuada tanto para la percepción humana como para la percepción mecánica. Respuesta para la persona en las etiquetas:<nombre/>, <documentación/>, para coche -<mensaje/>, <tipo de punto>

2) ¿Qué idioma hablas? (¿Qué tipos estás usando?) Responde en la etiqueta:<tipos/>

3) ¿Cómo me comunicaré con usted? (¿cómo accederá el cliente al servicio web?): HTTP o SMTP. La respuesta está en<vinculante/>

4) ¿Dónde puedo encontrarte? (¿Dónde puedo encontrar este servicio web o cuál es su URL?). La respuesta es:<servicio/>

Estructura:

Cada documento WSDL se puede dividir en tres partes lógicas:

1. definir tipos de datos - determinar el tipo de mensajes enviados y recibidos por el servicio XML

2. operaciones abstractas - lista de operaciones que se pueden realizar con mensajes

3. enlace de servicios - el método en el que se entregará el mensaje

Documentos WSDL Se puede crear manualmente, pero el lenguaje está estrictamente formalizado. WSDL le permite automatizar el proceso de escritura WSDL-documentos. Muchas herramientas de creación de servicios web contienen utilidades que crean automáticamente WSDL-archivos que describen servicios web listos para usar. Por ejemplo, herramienta de creación de servicios web Eje Apache contiene una clase Java2WSDL, creando WSDL- un archivo de una clase o interfaz Java que describe un servicio web. El paquete IBM WSTK, que incluye Eje, contiene la utilidad java2wsdl, que crea y ejecuta un objeto de esta clase. Funciona desde la línea de comando.

Elementos del documento WSDL

Describamos las etiquetas WSDL más utilizadas:

Etiqueta es la etiqueta raíz de todos los documentos WSDL. Define varios espacios de nombres:

1)El espacio de nombres de destino es el espacio de nombres de nuestro servicio web.

2) xmlns: espacio de nombres de documentos WSDL estándar

3)xmlns: SOAP_ENC – espacio de nombres utilizado para describir la codificación SOAP

4) xmlns: impl e intf – el espacio de nombres de la implementación y definición de nuestro servicio web

· Documento de Definición de Servicio Web

· Documento para implementar un servicio web

Para simplificar, como regla general, usan 1 archivo que contiene toda la información.

Elemento - proporciona información sobre los datos que se transfieren de un punto final a otro.

Para describir una llamada RPC, debe crear un mensaje de entrada y un mensaje de salida.

Dentro de este elemento, puede especificar parámetros del método utilizando el elemento

Elemento Describe y define las operaciones o métodos soportados por un servicio web.

Las operaciones pueden tener mensajes de entrada así como mensajes de error.

Elemento - describe cómo las operaciones especificadas en un tipo de puerto se transmitirán a través de la red. Porque El elemento utiliza un tipo de puerto, debe especificar un tipo definido anteriormente en algún lugar del documento.

Elemento - indica dónde encontrar el servicio web

Elemento importar . Muy a menudo, el elemento de servicio se asigna a su documento wsdl por razones prácticas.

Para permitir que un documento wsdl se junte en uno solo, se utiliza el elemento de importación. Le permite incluir un documento wsdl en otro.

Elemento tipos le permite especificar los tipos de datos transmitidos si no son estándar.

WSDL admite 4 modos de operaciones:

· operaciones unidireccionales o unidireccionales. El mensaje se envía al punto final del servicio. En este caso, la operación se describe mediante un solo mensaje de entrada.

· Solicitud-Respuesta – modo solicitud-respuesta. Este modo de operación es el más común. En este modo, la descripción de la operación contiene un mensaje de entrada, un mensaje de salida y un mensaje de error opcional.

· Operación tipo solicitud-respuesta. En este modo, un punto final es cliente de otro punto final. El formato de operación es similar al modo de solicitud-respuesta, pero los datos de salida aparecen antes de los datos de entrada.

· Notificación de operación. Este modo es otra versión de la primitiva de transmisión unidireccional, en la que el punto final envía el mensaje en lugar de recibirlo. La operación contiene sólo un mensaje de salida.

Cómo define WSDL 1.1 los servicios web y cómo crear modelos Java para verificar y transformar documentos WSDL

Serie de contenido:

Acerca de esta serie de artículos

servicios web - función importante Tecnologías Java™ en la informática empresarial. En esta serie de artículos, el consultor de servicios web y XML Denis Sosnovsky habla sobre las principales estructuras y tecnologías valiosas para los desarrolladores de Java que utilizan servicios web. Sigue los artículos de la serie para estar al día de las últimas novedades en este ámbito y saber cómo aplicarlas en tus propios proyectos.

Los servicios web para aplicaciones empresariales dependen en gran medida del uso de definiciones de servicios. Las definiciones de servicio describen el acuerdo básico entre el proveedor de servicios y cualquier consumidor potencial, detallando los tipos de funciones proporcionadas por el servicio y los mensajes dentro de cada función. Los proveedores y consumidores son libres de elegir cómo implementar sus objetos de intercambio en la medida en que los mensajes reales que envían se ajusten a la definición del servicio. El uso de una definición de servicio que describe cómo se intercambian los mensajes XML es lo que distingue a los servicios web de las tecnologías de programación distribuida anteriores.

fueron ofrecidos varios metodos definiciones de servicios web, pero el enfoque más utilizado sigue siendo WSDL 1.1. WSDL 1.1 tiene algunas deficiencias, incluida una estructura demasiado compleja que dificulta la lectura para los no iniciados. También sufre de la falta de una autoridad definición formal, lo que da como resultado sucesivas "aclaraciones" que llenan algunos de los vacíos en el documento de especificación original. Como resultado, las pilas de servicios web intentan manejar documentos WSDL 1.1 de la forma más flexible posible. Esta flexibilidad puede aumentar la confusión en la comprensión de WSDL 1.1, como ven los desarrolladores. amplia gama Estructuras WSDL sin ninguna indicación de qué enfoque es preferible.

En este artículo, le mostraremos cómo analizar documentos WSDL 1.1 y veremos las primeras partes del modelo Java para validar documentos WSDL y convertirlos al formato estándar.

Análisis de WSDL 1.1

Espacios de nombres utilizados

Este artículo utiliza:

• prefijo wsdl para representar el espacio de nombres WSDL 1.1 http://schemas.xmlsoap.org/wsdl/;
• el prefijo SOAP para el espacio de nombres http://schemas.xmlsoap.org/wsdl/soap/ utilizado por la extensión SOAP 1.1 para WSDL 1.1;
• Prefijo xs para el espacio de nombres http://www.w3.org/2001/XMLSchema utilizado para las definiciones de esquemas XML.

La revisión 1.1 del WSDL, publicada a principios de 2001, ha sido técnicamente reemplazada por las recomendaciones del W3C WSDL 2.0, publicadas en 2007. WSDL 2.0 ofrece una estructura más limpia que WSDL 1.1 junto con una mayor flexibilidad. Pero WSDL 2.0 sufre el problema del huevo y la gallina: WSDL 2.0 no se usa ampliamente porque no cuenta con un soporte generalizado y, debido a que no se usa ampliamente, los desarrolladores de pilas de servicios web tienen pocos incentivos para respaldarlo. A pesar de todas sus deficiencias, WSDL 1.1 es suficientemente bueno para la mayoría de los propósitos.

La especificación WSDL 1.1 original era imprecisa con respecto al número de funciones utilizadas. Debido a que el objetivo de WSDL era trabajar con definiciones de servicios SOAP, también incluía soporte para características SOAP (como la codificación rpc) que luego resultaron no ser deseables. Web de la organización La Organización de Interoperabilidad de Servicios (WS-I) ha abordado estos problemas en el Perfil de referencia (BP), que proporciona orientación práctica para servicios web que utilizan SOAP y WSDL. BP 1.0 se aprobó en 2004 y BP 1.1 se lanzó en 2006. Este artículo cubre WSDL 1.1 según las recomendaciones de WS-I BP y no aborda características obsoletas reales, como la codificación rpc para SOAP.

Se supone que la estructura de los documentos XML está especificada por definiciones de esquemas XML. La especificación WSDL 1.1 original incluía una descripción del esquema, pero el esquema no coincide con las descripciones textuales en varios aspectos. Esto fue corregido posteriormente en versión modificada esquema, pero el documento WSDL 1.1 no se editó para reflejar este cambio. El equipo de BP WS-I decidió entonces contribuir más más cambios en el esquema WSDL y ha creado lo que se promociona como pautas prácticas para este esquema resbaladizo. Los documentos escritos para una versión de un esquema generalmente no son compatibles con otras versiones (a pesar de usar el mismo espacio de nombres), pero afortunadamente la mayoría de las herramientas de servicios web ignoran en gran medida el esquema y aceptan lo que parezca razonable. (Consulte los enlaces a muchos esquemas WSDL en la sección).

Incluso la versión BP WS-I del esquema WSDL 1.1 no hace mucho para garantizar el cumplimiento de la especificación del documento WSDL 1.1. El diagrama no refleja todas las limitaciones del WS-I BP, especialmente con respecto al orden de los componentes. Además, el esquema XML no puede manejar muchos tipos de restricciones fáciles de establecer en los documentos (como atributos alternativos o elementos adicionales requeridos de un esquema separado). Por lo tanto, verificar que un documento WSDL 1.1 se ajuste a la especificación WSDL 1.1 (modificada por WS-I BP) implica mucho más que simplemente realizar la validación del esquema XML. Volveremos a este tema más adelante en este artículo. Pero primero, veamos la estructura de las descripciones de servicios WSDL 1.1.

Descripción Componentes

Los documentos WSDL 1.1 utilizan un elemento raíz fijo y con un nombre conveniente . dentro de esto elemento raíz el espacio de nombres WSDL 1.1 define un elemento secundario "pasivo" (simplemente un enlace a documentos WSDL 1.1 individuales) y cinco "activos" elementos secundarios(que en realidad constituyen la descripción del servicio):

• hace referencia a un documento WSDL 1.1 independiente con descripciones que se incluirán en ese documento;
• define tipos o elementos XML utilizados para mensajería;
• define el mensaje real en términos de tipos o elementos XML;
• define un conjunto abstracto de operaciones realizadas por el servicio;
• define la implementación real utilizando protocolos y formatos específicos;
• Define el servicio como un todo, que normalmente incluye uno o más elementos. con información de acceso a elementos .

También hay un elemento , que se puede utilizar con fines de documentación como primer elemento secundario , así como el primer hijo de cualquiera de los elementos anteriores.

Una descripción completa de un servicio normalmente requiere al menos un elemento de cada uno de estos tipos, excepto , pero no es necesario que estén todos en el mismo documento. Para armar un completo Descripciones WSDL de varios documentos se puede utilizar , que permite subdividir las descripciones para adaptarlas a las necesidades de la organización. Por ejemplo, los primeros tres elementos de la descripción ( , Y ) juntos componen descripción completa interfaz de servicio (quizás definida por el grupo de arquitectura), por lo que tiene sentido mantenerlos separados de los elementos orientados a la implementación Y . Todas las pilas de servicios web principales admiten la división de descripciones en múltiples documentos WSDL.

El Listado 1 muestra un ejemplo de una descripción de servicio WSDL dividida en dos documentos WSDL, de modo que los componentes de descripción de la interfaz estén contenidos en el archivo BookServerInterface.wsdl y los componentes de implementación estén contenidos en el archivo BookServerImpl.wsdl. El Listado 1 muestra BookServerInterface.wsdl.

Listado 1. BookServerInterface.wsdl

Definición de la interfaz del servicio de libros. ... ... Implementación del servicio de libros. Esto crea una biblioteca inicial de libros cuando se carga la clase, luego admite llamadas a métodos para acceder a la información de la biblioteca (incluida la adición de libros nuevos). Consigue el libro con un ISBN particular. ... Añade un nuevo libro.

El Listado 2 muestra BookServerImpl.wsdl. Elemento al principio importa la descripción de la interfaz BookServerInterface.wsdl.

Listado 2. BookServerImpl.wsdl

Definición de implementación real del servicio de libros. ...

Además de las definiciones de elementos (y atributos) en el espacio de nombres WSDL 1.1, WSDL 1.1 también define elementos adicionales. Están destinados a llenar celdas específicas en las descripciones de servicios WSDL 1.1 para la transmisión. información adicional requerido para un tipo específico de servicio. Los únicos elementos adicionales de WSDL 1.1 que todavía se utilizan ampliamente son los enlaces para SOAP 1.1 (estos se introducen en , en los elementos Y ), que se definieron en la especificación WSDL 1.1 original, y para SOAP 1.2, definido por una especificación separada en 2006.

Detalles del componente

Elemento contiene todas las definiciones XML utilizadas para los mensajes, como uno o más elementos . (WSDL permite alternativas de esquemas XML para estas definiciones, pero la mayoría de las pilas solo admiten esquemas XML). Si es necesario, elementos puede usar o para incluir otros esquemas externos al WSDL (así como hacer referencia a esquemas separados dentro del mismo WSDL).

Dado que un elemento puede contener cualquier número de definiciones de esquema, no hay razón para utilizar más de un elemento en un documento WSDL . al elemento se encuentra en la parte superior de BookServerInterface.wsdl.

Además Y , todos los componentes nivel superior Al documento WSDL se le asignan nombres individuales utilizando el atributo de nombre requerido. Cuando se utiliza el atributo targetNamespace en el elemento raíz documento (que suele ser mejor), los nombres de estos componentes se definen en este espacio de nombres de destino. Esto significa que al definir un nombre, es suficiente asignar la parte simple o "local" del nombre, pero las referencias a ese componente deben calificar el nombre usando un prefijo de espacio de nombres o usando un espacio de nombres predeterminado. La Figura 1 muestra los vínculos más importantes entre los componentes WSDL, con líneas continuas que representan vínculos por nombre completo y líneas de puntos que representan vínculos por nombre utilizados para la identificación sin calificación de espacio de nombres.

Figura 1. Relaciones entre los componentes WSDL

Mensajes representados por elementos. , se encuentran en el núcleo de las descripciones de servicios WSDL. Elementos son descripciones de datos XML transferidos entre el cliente y el proveedor de servicios. cada elemento contiene cero o más (normalmente uno) elementos secundarios . Cada elemento de parte requiere su propio atributo de nombre (único dentro ) y uno de los atributos de elemento o tipo que hace referencia a la definición del esquema de datos XML. Múltiples elementos se muestra en , después del elemento en BookServerInterface.wsdl.

Elementos definir una interfaz de servicio abstracta en términos de mensajes enviados y recibidos del servicio. Elementos contener cualquier número de elementos secundarios . Cada elemento hijo requiere su propio atributo de nombre (BP WS-I requiere que sea único dentro ) y contiene uno o más elementos secundarios que describen los mensajes utilizados por la operación. Los elementos secundarios son de tres tipos, correspondientes a diferentes usos:

• : datos enviados por el cliente al proveedor de servicios como entrada a la operación;
• : datos devueltos al cliente por el proveedor del servicio como resultado de una operación;
• : Datos devueltos al cliente por el proveedor del servicio cuando se produce un error durante el procesamiento.

WSDL 1.1 define varios patrones de interacción entre un cliente y un proveedor de servicios, representados por varias secuencias de elementos secundarios. Y , pero no todos los modelos están lo suficientemente bien definidos como para implementarlos. BP WS-I permite sólo dos modelos: operaciones de solicitud-respuesta, donde debería y operaciones unidireccionales que contienen solo . En el caso de operaciones de solicitud-respuesta (con diferencia, el tipo más común) detrás de los elementos Y puede ir seguido de cualquier número de elementos .

cada elemento , o se refiere a una descripción de mensaje a través del atributo de mensaje requerido. Esta es una referencia calificada de espacio de nombres, por lo que generalmente requiere agregar un prefijo. Se pueden ver ejemplos en: por ejemplo, cuando un elemento utilizado en la descripción de la operación getBook. (El prefijo tns sirve como definición del elemento raíz con el mismo URI de espacio de nombres que el atributo targetNamespace).

De muchas maneras puede considerarse el equivalente lógico de una interfaz Java, por lo que los elementos son equivalentes a métodos, elementos - parámetros del método, elementos - los resultados de los métodos y los elementos - excepciones marcadas. Estas coincidencias se utilizan para generar código java desde WSDL, como ocurre con la mayoría de las herramientas que generan WSDL desde código existente Java.

Comparación de SOAP 1.1 y 1.2

SOAP 1.1 se ha utilizado ampliamente para servicios web desde que se publicó la especificación en 2000. SOAP 1.2 se desarrolló con un apoyo más amplio de la industria a través del W3C y se publicó como estándar oficial del W3C en 2007. SOAP 1.2 está mejor documentado y es más limpio que SOAP 1.1, con algunos de los aspectos desagradables de 1.1 eliminados quirúrgicamente. A pesar de esta estructura limpia, para la mayoría de los servicios web hay poca diferencia práctica entre ellos. Quizás la característica más importante de SOAP 1.2 es que es la única forma oficialmente admitida de aprovechar el soporte mejorado de SOAP para archivos adjuntos de empaquetado optimizado (XOP) binario XML y el mecanismo de optimización de transmisión de mensajes SOAP (MTOM). en un bucle Servicios web Java He estado usando SOAP 1.1 hasta ahora porque algunas pilas antiguas no soportan SOAP 1.2, pero para desarrollar nuevos servicios web, 1.2 es probablemente una mejor opción.

Elementos representar una instancia de una interfaz abstracta definida , que es visible al principio de BookServerImpl.wsdl. El atributo tipo contiene nombre completo el tipo de puerto implementado en el enlace.

Elementos secundarios Contiene información detallada sobre cómo se implementa el tipo de puerto. Los elementos secundarios del espacio de nombres WSDL corresponden a elementos y debería usar el mismo valor de nombre – y no enlaces con aclaración del espacio de nombres, como en el caso . esta conexión se muestra mediante líneas de puntos en el nivel . La misma relación por nombre se aplica a los elementos secundarios. / / elementos . A pesar de esta reutilización de los mismos nombres de elementos, el contenido de estos elementos difiere significativamente cuando son elementos secundarios. , no el elemento .

Las extensiones definidas por WSDL entran en juego en . elemento hijo utilizado en una definición de servicio SOAP (el único tipo de servicio permitido por WS-I BP, aunque WSDL 1.1 también permite enlaces HTTP). Este artículo utiliza el atributo de transporte requerido para especificar el tipo de transporte utilizado por el enlace. (HTTP, como se ve en el valor http://schemas.xmlsoap.org/soap/http en , es la única opción permitida por WS-I BP). El atributo de estilo opcional le permite elegir entre los estilos rpc y de documento. para representar datos XML (el valor más común de documento corresponde a mensajes que utilizan elementos de definición de esquema en lugar de tipo).

Dentro de cada elemento hijo elemento elemento se puede utilizar para especificar el valor de una SOAPAction con el fin de identificar solicitudes para llamar a esa operación (y potencialmente también para anular la elección de documento o estilo rpc especificado por el elemento , aunque BP WS-I prohíbe dicho uso). Cada elemento hijo / / contiene otro elemento adicional, que siempre es un elemento (lo que indica que los datos del mensaje se envían en el cuerpo del mensaje SOAP; los datos e incluso los errores también se pueden enviar en los encabezados SOAP, aunque no lo recomiendo) para o , o su equivalente , usado con .

El último componente El elemento de descripción del servicio WSDL es , que consta de un grupo de elementos . cada elemento asocia la dirección de acceso con . La dirección de acceso está contenida en un elemento adicional anidado .

Trabajar con WSDL

No es sorprendente que con todas las variaciones en los esquemas y reglas para los documentos WSDL 1.1, muchos documentos no se ajusten a las mejores prácticas de BP WS-I. El apoyo a muchas desviaciones de las mejores prácticas en todas las pilas de servicios web ha ayudado a perpetuar el uso de diseños obsoletos o incorrectos, lo que ha llevado a la propagación de malas prácticas en toda la industria. Y definitivamente no soy inmune a esta infección: mientras miraba los documentos WSDL que proporcioné como ejemplos de código para esta serie, me sorprendió descubrir que ninguno de ellos era completamente correcto.

Entonces, cuando decidí escribir este artículo, pensé que sería bueno incluir una herramienta que le permita comparar los documentos WSDL con las mejores prácticas. Parecería que a partir de aquí sólo hay un paso para convertir documentos WSDL en forma correcta, siempre que el WSDL original esté libre de errores. Pero había mucho más trabajo del que había planeado originalmente y información completa Incluiré información sobre este modelo en los próximos dos artículos de esta serie.

Se han creado muchos modelos diferentes para trabajar con documentos WSDL en Java, incluido el ampliamente utilizado Lenguaje de descripción de servicios web para Java Toolkit (WSDL4J), que es una implementación de referencia de JSR 110 (consulte la sección). Ninguno de estos modelos se ajusta a lo que me propuse hacer, debido a la doble naturaleza del problema: primero, leer documentos WSDL en cualquier forma semiinteligente e informar errores y desviaciones de las mejores prácticas, y segundo, escribir WSDL sin errores. documentos reformateados en una forma consistente con recomendaciones prácticas. WSDL4J, por ejemplo, no conserva el orden de los elementos de entrada para que se puedan informar problemas de orden, y no maneja definiciones de esquemas, por lo que no puede usarse directamente para verificar referencias de elementos. . Así que tuve que elegir entre un planteamiento del problema más realista y escribir el mío propio. propio modelo. Naturalmente, decidí escribir mi propio modelo.

modelo WSDL

Validación y Verificación

En este artículo utilizo el término verificación para referirse a la verificación de la validez de un documento WSDL, porque el término alternativo validación, comúnmente utilizado para documentos XML, significa comparar documentos con una definición de esquema.

Anteriormente, implementé parcialmente un modelo WSDL para usarlo con el enlace de datos JiBX como parte del proyecto JiBX/WS. Este modelo es sólo para inferencia e incluye relativamente pequeño número clases que en algunos casos combinan datos de elementos anidados de una estructura XML WSDL ( combinado con un elemento hijo , , Y adentro en combinación con el elemento o etc.). Esta estructura de clases compacta facilitó la creación del subconjunto de documentos WSDL compatibles con el marco, pero cuando comencé a considerar la creación de una herramienta de verificación y reestructuración basada en este modelo, me di cuenta de que el modelo para admitir la entrada de WSDL posiblemente mal estructurado Necesita estar más cerca de la presentación XML.

Otra opción es generar código a partir del esquema WS-I BP para WSDL 1.1. Después de ver esto, me di cuenta de que simplemente usar las clases generadas directamente generaría confusión, ya que el diseño incluye tipos redundantes, así como algunas construcciones incómodas que se utilizan para representar diferentes modelos de mensajería (algunos de los cuales luego fueron prohibidos por el WS- Texto I BP) .

Así que terminé compilando las clases a mano, aunque el resultado fue casi el mismo que si hubiera comenzado con el código generado a partir del esquema y simplemente redujera la duplicación y la complejidad innecesarias. El enlace de datos JiBX admite múltiples enlaces a las mismas clases, por lo que pude crear un enlace de entrada para manejar toda la gama de variaciones permitidas por cualquier versión de WSDL 1.1, aunque configurar el enlace de salida para la salida WSDL solo fue una forma de mejores prácticas.

El Listado 3 muestra la parte de la clase Definiciones correspondiente al elemento raíz. .

Listado 3. Clase de definiciones (parcial)

Las definiciones de clases públicas extienden ElementBase ( /** Lista de elementos secundarios en el orden esperado. */ enumeración estática AddState (inválido, importaciones, tipos, mensaje, tipo de puerto, enlace, servicio); /** Lista de nombres de atributos permitidos. */ público final estático StringArray s_allowedAttributes = new StringArray(new String("nombre", "targetNamespace" )); m_validationContext; /** Estado actual (usado para verificar el orden en el que */ /** se agregan los niños). */ privado AddState m_state; /** El nombre de esta definición. */ cadena privada m_name; /** Espacio de nombres WSDL de destino. */ cadena privada m_targetNamespace; /** Lista de todos los elementos secundarios importados. */ Lista privada m_imports = nueva lista de matrices (); /** Lista de todos los tipos de elementos secundarios. */ Lista privada m_types = nueva lista de matrices (); /** Lista de todos los mensajes de elementos secundarios. */ Lista privada m_messages = nueva lista de matrices (); /** Lista de todos los elementos secundarios de portType. */ Lista privada M_portTypes = nueva ArrayList (); /** Lista de todos los enlaces de elementos secundarios. */ Lista privada m_bindings = nueva lista de matrices (); /** Lista de todos los servicios infantiles. */ Lista privada m_services = nueva ArrayList m_nameMessageMap = nuevo HashMap ();/** Asigna el nombre calificado al tipo de puerto en esta definición. */ Mapa privado< m_state.ordinal()) { // отчет о дочерних элементах вне ожидаемого порядка m_validationContext.addWarning ("Child element of wsdl:definitions out of order", comp); m_state = AddState.invalid; } } } ... /** * Добавление немаршаллизированного дочернего элемента wsdl:message. * Здесь же сообщение индексируется по имени для доступа с целью валидации. * * @param child */ public void addMessage(Message child) { checkAdd(AddState.message, child); m_messages.add(child); addName(child.getName(), child, m_nameMessageMap); } ...

m_namePortTypeMap = nuevo HashMap ();/** Asigne el nombre calificado al mensaje en esta definición. */ Mapa privado . Cada configurador también ejecuta una verificación de estado para detectar elementos desordenados.

Permitido en cualquier elemento WSDL atributos adicionales y elementos (generalmente todos los atributos o elementos que no utilizan el espacio de nombres WSDL 1.1). Un ejemplo de tal elementos adicionales Las configuraciones de WS-Policy integradas en los documentos WSDL de artículos anteriores de esta serie sirven como referencia, al igual que los enlaces a las políticas reales. Es mejor que estos elementos adicionales precedan a cualquier elemento secundario del espacio de nombres WSDL 1.1, y así es como se manejan en el enlace de salida. El enlace de entrada maneja elementos y atributos adicionales mediante código. clase base de clases de elementos WSDL que no se muestran en y permite que los elementos sigan en cualquier orden (generando una advertencia si siguen a un elemento del espacio de nombres WSDL 1.1).

El modelo procesa elementos conocidos utilizando enlaces separados para cada uno. espacio extra nombres, cada uno con su propio conjunto de clases. Analizaré el manejo de estos elementos adicionales con más detalle en el próximo número. Servicios web Java, donde se presentará el código fuente con más detalle.

Verificación del modelo

Se realiza alguna verificación básica de los datos WSDL a medida que se agregan objetos no ordenados correspondientes a elementos a la estructura de árbol del documento WSDL, como se muestra en el código addMessage() al final de . Este código utiliza el método checkAdd() para verificar el orden de los elementos secundarios y el método addName() para verificar que se presenta un nombre válido (el texto coincide con el tipo de esquema NCName y el valor es único dentro del tipo de elemento) y asigna el nombre al objeto. Pero esto es sólo comprobar la información más básica para elemento individual; Para comprobar otras propiedades de cada elemento y las relaciones entre elementos, es necesario. código adicional verificación.

JiBX te permite llamar a los manejadores extensiones personalizadas como parte del proceso de organización y desorganización. Para ejecutar la lógica de verificación, el modelo WSDL utiliza uno de estos controladores adicionales, el método post-set. El método post-set se llama después de que el objeto asociado haya terminado de descomponerse, por lo que esto suele ser buen camino realizar comprobaciones como la verificación de objetos. En el caso de la verificación WSDL, el enfoque más simple es realizar toda la verificación de objetos desde un único método post-set en el elemento raíz. . Este enfoque evita el problema de hacer referencia directa a los componentes del documento WSDL cuando los componentes no aparecen en el orden esperado.

Otros complementos

Este artículo proporciona los conceptos básicos de la estructura y el uso de WSDL y una introducción al modelo de datos Java para WSDL, que está diseñado para respaldar la verificación de documentos WSDL y su transformación en un formato de mejores prácticas.

El próximo artículo continuará con este tema analizando los problemas que se encuentran comúnmente al escribir aserciones de WS-Policy y WS-SecurityPolicy. También examinará más de cerca el modelo WSDL y el proceso de verificación, incluida la ampliación del modelo para incluir aserciones WS-Policy/WS-SecurityPolicy integradas en el WSDL.