WSDL (Web Services Description Language)

Cuando se ha realizado la introducción a los servicios se ha hablado del documento de descripción de servicio, que permitía identificar un servicio y así actuar como interfaz de comunicación con otros servicios que quisieran usarlo. Así también, gracias a este documento un servicio puede ser descubierto. Posteriormente se ha introducido el concepto de la orientación a servicios de bajo acoplamiento y cómo se conseguía gracias al contrato estandarizado y por lo tanto, a la descripción de servicio incluida en él. En el ámbito de los

74

servicios web, la implementación de un descripción de servicio se realiza con el documento WSDL que es una combinación de SOAP y XML Schema.

Un programa cliente que pretenda usar un servicio web puede leer el WSDL para determinar qué funciones están disponibles en el servicio, esto se realiza a partir del punto de contacto que permite la comunicación, a este punto de contacto se llama service endpoint y estará indicado en el WSDL. Los tipos de datos usados por las operaciones del servicio se incluyen en el archivo WSDL en forma de XML Schema. El cliente puede usar SOAP para hacer la llamada a una de las funciones listadas en el WSDL, que como hemos visto cuando se ha explicado SOAP, el nombre usado de la operación en el mensaje SOAP debe coincidir con la operación definida en el WSDL.

Una vez introducido el concepto de WSDL y su finalidad, entraremos en detalle en cómo está estructurado.

Estructura del WSDL

La estructura de un WSDL se puede diferenciar en dos categorías separadas tal y como se refleja en la Figura 48.

Fig. 48. Estructura de un WSDL. [7]

Estas dos categorías son la descripción abstracta y la descripción concreta. La descripción abstracta es la parte del WSDL que establece las interfaces del servicio, es decir, todas aquellas partes del servicio que se pueden definir sin tener en cuenta ningún tipo de tecnología en concreto. De esta forma se preserva la integridad del servicio y si en un futuro se cambia la tecnología estas partes no habrá que cambiarlas. Las partes que sí que deberían de cambiar son las de la descripción concreta, debido que en esta parte del WSDL es dónde se asocia la descripción abstracta a un tipo de tecnología en concreto, por ejemplo,

75

el protocolo de transporte usado en la comunicación. Veamos en detalle cada parte del WSDL.

Descripción abstracta

La descripción abstracta está compuesta de las siguientes secciones:

• Tipos de datos: a esta sección le corresponde la etiqueta <type>. Es donde se describen los tipos de datos usados en los mensajes. Se utiliza XML Schema para definirlos.

• Mensajes: a esta sección le corresponde la etiqueta <message>. Es la definición abstracta de los elementos del mensaje. Con los mensajes definimos los datos intercambiados en las peticiones y respuestas establecidas entre el solicitante del servicio y el servicio. En los mensajes por lo tanto, estarán definidos los parámetros y valores de retorno usados. Estos parámetros pueden definirse a partir de las estructuras creadas en la sección de tipos de datos mediante el atributo element, o se puede indicar directamente un tipo si el dato es de tipo básico, como por ejemplo un String, mediante el atributo type.

• PortType o Interface: a esta sección le corresponde la etiqueta <portType>. Es la definición abstracta de las operaciones permitidas, dentro de cada operación se definen qué mensajes se recibirán (mensajes input) o se enviarán (mensajes output). Estos mensajes serán los definidos previamente en la sección de mensajes. En función de si se puede o no recibir mensajes dentro de las operaciones, hay cuatro tipos de transmisiones permitidas, tal y como se muestra en la Figura 49.

Fig. 49. Tipos de transmisiones permitidas en el WSDL. [7]

One-way: El servicio solamente recibe mensajes, es decir solamente tiene mensajes del tipo input.

Request-Response: El servicio recibe un mensaje y devuelve otro mensaje de respuesta, por lo tanto tendrá un mensaje input y otro output.

76

Solicit-Response: El proceso inverso a Request-Response, el servicio envía un mensaje y recibe una respuesta, con lo que tendrá un mensaje output y otro input.
Notification: El proceso inverso a One-way, el servicio solamente envía mensajes,

por consiguiente, tendrá solamente mensajes del tipo output.

Una vez vistas las secciones de la descripción abstracta, detallaremos las secciones de la descripción concreta.

Descripción concreta

La descripción concreta está compuesta de las siguientes secciones:

• Binding: a esta sección le corresponde la etiqueta <binding>. En esta sección se especifica un protocolo de comunicación concreto (SOAP/HTTP, HTTP GET/POST, etc…) y un formato de datos para una operación en particular. Es decir, asociamos una implementación tecnológica concreta, a las operaciones del servicio.

• Servicios: a esta sección le corresponde la etiqueta <service>. En ella se definen los puertos que especifican los endpoints. Harán referencia a un Binding. Definen pues, dónde se estará preparado para recibir/enviar mensajes.

Para ejemplificar todos estos conceptos detallados tanto en la descripción abstracta como concreta, analizaremos un WSDL de ejemplo y comentaremos cada sección:

<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types>

<schema targetNamespace="http://example.com/stockquote.xsd"

xmlns="http://www.w3.org/2000/10/XMLSchema">

<element name="TradePriceRequest"> <complexType>

<all>

<element name="tickerSymbol" type="string"/> </all>

</complexType> </element>

<element name="TradePrice"> <complexType>

<all>

<element name="price" type="float"/> </all>

77 </complexType> </element> </schema> </types>

<message name="GetLastTradePriceInput">

<part name="body" element="xsd1:TradePriceRequest"/> </message>

<message name="GetLastTradePriceOutput">

<part name="body" element="xsd1:TradePrice"/> </message>

<portType name="StockQuotePortType">

<operation name="GetLastTradePrice">

<input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation>

</portType>

<binding name="StockQuoteSoapBinding"

type="tns:StockQuotePortType">

<soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLastTradePrice">

<soap:operation

soapAction="http://example.com/GetLastTradePrice"/> <input>

<soap:body use="literal"/> </input>

<output>

<soap:body use="literal"/> </output>

</operation> </binding>

<service name="StockQuoteService">

<documentation>My first service</documentation> <port name="StockQuotePort"

binding="tns:StockQuoteSoapBinding">

<soap:address location="http://example.com/stockquote"/> </port>

</service>

</definitions>

78 Types

Se definen dos tipos de datos, TradePriceRequest que tendrá un elemento tickerSympol del tipo string (cadena de caracteres) que solo podrá aparecer una vez. Esto se define con la etiqueta <all>.

El segundo elemento definido es TradePrice que tendrá un subelemento Price del tipo float (decimal).

Message

Se definen dos mensajes el primero GetLasTradePriceInput hace referencia al elemento TradePriceRequest definido en la sección types, y GetLastTradePriceOutput que hará referencia al elemento TradePrice también definido en la sección types.

PortType

Se define la operación GetLastTradePrice dónde el mensaje de la petición será el mensaje GetLastTradePriceInput y la respuesta será el mensaje GetLastTradePriceOutput.

Por lo tanto, se está definiendo una operación dónde se enviará un identificador de valor bursátil (tickerSymbol) y se recibirá la respuesta de su valor actual en el mercado (Price). Binding

En esta sección se define el binding StockQuoteSoapBinding donde se indica que la operación GetLastTradePrice se hará sobre el protocolo HTTP/SOAP a partir del atributo

transport=http://schemas.xmlsoap.org/soap/http

Hasta este punto todo se había definido de forma abstracta, las operaciones y los mensajes. Es con el binding dónde se le da unas características concretas de protocolo de transporte. Service

Se define el endpoint donde llegaran las peticiones para el binding. El endpoint se define en: <soap:addresslocation="http://example.com/stockquote"/>

Esto significa que la petición SOAP realizada por el consumidor del servicio se deberá enviar a la URL definida en el atributo location.

79

Una vez vistos los puntos más importantes de los servicios web realizaremos una comparativa entre los principios de service-orientation y los servicios web, para ver como éstos proveen una implementación de dichos principios, y por lo tanto, para construir soluciones SOA.