El lenguaje de descripción de servicios web ( WSDL / ˈwɪzdəl / ) es un lenguaje de descripción de interfaz basado en XML que se utiliza para describir la funcionalidad ofrecida por un servicio web . [ cita necesaria ] El acrónimo también se utiliza para cualquier descripción WSDL específica de un servicio web (también conocido como archivo WSDL ), que proporciona una descripción legible por máquina de cómo se puede llamar al servicio, qué parámetros espera y qué estructuras de datos que devuelve. Por lo tanto, su propósito es más o menos similar al de una firma tipográfica en un lenguaje de programación.
La última versión de WSDL, que se convirtió en recomendación del W3C en 2007, es WSDL 2.0. El significado del acrónimo ha cambiado desde la versión 1.1, donde la "D" significaba "Definición".
El WSDL describe los servicios como colecciones de puntos finales o puertos de red . La especificación WSDL proporciona un formato XML para documentos para este propósito. Las definiciones abstractas de puertos y mensajes se separan de su uso o instancia concreta, permitiendo la reutilización de estas definiciones. Un puerto se define asociando una dirección de red con un enlace reutilizable, y una colección de puertos define un servicio. Los mensajes son descripciones abstractas de los datos que se intercambian y los tipos de puertos son colecciones abstractas de operaciones admitidas. Las especificaciones concretas de protocolo y formato de datos para un tipo de puerto particular constituyen un enlace reutilizable, donde las operaciones y los mensajes luego se vinculan a un protocolo de red y formato de mensaje concretos. De esta forma, WSDL describe la interfaz pública del servicio web.
WSDL se utiliza a menudo en combinación con SOAP y un esquema XML para proporcionar servicios web a través de Internet . Un programa cliente que se conecta a un servicio web puede leer el archivo WSDL para determinar qué operaciones están disponibles en el servidor. Todos los tipos de datos especiales utilizados están integrados en el archivo WSDL en forma de esquema XML. Luego, el cliente puede usar SOAP para llamar a una de las operaciones enumeradas en el archivo WSDL, usando, por ejemplo, XML sobre HTTP .
La versión actual de la especificación es 2.0; La versión 1.1 no ha sido respaldada por el W3C , pero la versión 2.0 es una recomendación del W3C . [1] WSDL 1.2 pasó a llamarse WSDL 2.0 debido a sus diferencias sustanciales con WSDL 1.1. Al aceptar el enlace a todos los métodos de solicitud HTTP (no solo GET y POST como en la versión 1.1), la especificación WSDL 2.0 ofrece un mejor soporte para los servicios web RESTful y es mucho más sencilla de implementar. [2] [3] Sin embargo, el soporte para esta especificación aún es deficiente en los kits de desarrollo de software para servicios web que a menudo ofrecen herramientas sólo para WSDL 1.1. [ necesita actualización ] [ cita necesaria ] Por ejemplo, la versión 2.0 del Business Process Execution Language (BPEL) solo admite WSDL 1.1.
<?xml versión="1.0" codificación="UTF-8"?> <descripción xmlns= "http://www.w3.org/ns/wsdl" xmlns:tns= "http://www.tmsws.com /wsdl20sample" xmlns:whttp= "http://schemas.xmlsoap.org/wsdl/http/" xmlns:wsoap= "http://schemas.xmlsoap.org/wsdl/soap/" targetNamespace= "http:// www.tmsws.com/wsdl20sample" > <documentación> Este es un documento WSDL 2.0 de muestra . </documentación> <!-- Tipo abstracto --> <tipos> <xs:schema xmlns:xs= "http://www.w3.org/2001/XMLSchema" xmlns= "http://www.tmsws.com/wsdl20sample" targetNamespace= "http://www.example.com/wsdl20sample" > <xs:element name= "solicitud" > ... </xs:element> <xs:element name= "respuesta" > ... </ xs:elemento> </xs:schema> </tipos> <!-- Interfaces abstractas --> < nombre de interfaz= "Interfaz1" > < nombre de error= "Error1" elemento= "tns:response" /> < nombre de operación= "Obtener" patrón= "http://www.w3 .org/ns/wsdl/in-out" > <input messageLabel= "In" element= "tns:request" /> <output messageLabel= "Out" element= "tns:response" /> < /operación> </ interfaz> <!-- Enlace concreto a través de HTTP --> < nombre de enlace= "HttpBinding" interfaz= "tns:Interface1" tipo= "http://www.w3.org/ns/wsdl/http" > <operación ref= " tns:Get" whttp:method= "GET" /> </binding> <!-- Unión de hormigón con SOAP--> <binding name= "SoapBinding" interface= "tns:Interface1" type= "http://www .w3.org/ns/wsdl/soap" wsoap:protocol= "http://www.w3.org/2003/05/soap/bindings/HTTP/" wsoap:mepDefault= "http://www.w3. org/2003/05/soap/mep/request-response" > <operación ref= "tns:Get" /> </binding> <!-- Servicio web que ofrece puntos finales para ambos enlaces--> < nombre del servicio= "Service1" interfaz= "tns:Interface1" > < nombre del punto final= "HttpEndpoint" enlace= "tns:HttpBinding" dirección= "http:// www.example.com/rest/" /> < nombre del punto final= "SoapEndpoint" vinculante= "tns:SoapBinding" dirección= "http://www.example.com/soap/" /> </servicio> </descripción > WSDL 1.0 (septiembre de 2000) fue desarrollado por IBM , Microsoft y Ariba para describir los servicios web para su kit de herramientas SOAP. Fue creado combinando dos lenguajes de descripción de servicios: NASSL (lenguaje de especificación de servicios de aplicaciones de red) de IBM y SDL (lenguaje de descripción de servicios) de Microsoft.
WSDL 1.1, publicado en marzo de 2001, es la formalización de WSDL 1.0. No se introdujeron cambios importantes entre 1.0 y 1.1.
WSDL 1.2 (junio de 2003) era un borrador de trabajo en el W3C, pero se convirtió en WSDL 2.0. Según W3C: WSDL 1.2 es más fácil y flexible para los desarrolladores que la versión anterior. WSDL 1.2 intenta eliminar funciones no interoperables y también define mejor el enlace HTTP 1.1. WSDL 1.2 no era compatible con la mayoría de los servidores/proveedores SOAP.
WSDL 2.0 se convirtió en una recomendación del W3C en junio de 2007. WSDL 1.2 pasó a llamarse WSDL 2.0 porque tiene diferencias sustanciales con respecto a WSDL 1.1. Los cambios son los siguientes:
Subconjunto WSDL (SWSDL) [4] es un WSDL con las operaciones de subconjunto de un WSDL original. Un desarrollador puede utilizar SWSDL para acceder al servicio de subconjunto y así manejar un subconjunto de código de servicio web. Se puede utilizar un subconjunto WSDL para realizar pruebas de servicios web y desarrollo de arriba hacia abajo. La división de un servicio web se puede realizar utilizando un WSDL de subconjunto para acceder al servicio de subconjunto. El servicio de subconjunto se puede clasificar en capas utilizando SWSDL. Los SWSDL se utilizan para análisis, pruebas y desarrollo de arriba hacia abajo de servicios web. AWSCM [5] es una herramienta que puede identificar operaciones de subconjunto en un archivo WSDL para construir un subconjunto WSDL.
Dado que los archivos WSDL son una especificación basada en XML para describir un servicio web, los archivos WSDL son susceptibles de sufrir ataques. [6] Para mitigar la vulnerabilidad de estos archivos, se recomienda limitar el acceso a los archivos WSDL generados, establecer restricciones de acceso adecuadas en las definiciones WSDL y evitar definiciones innecesarias en los servicios web.