Unidad IV

WSDL
WSDL son las siglas en inglés de "Lenguaje de Descripción de Servicios Web"
(o "Web Services Description Language"), un lenguaje que está basado en
XML y que permite la descripción de los servicios web desplegados. WSDL se
utiliza también para la localización y ubicación de estos servicios en Internet.

Un documento WSDL no es más que un documento XML que describe ciertas

características propias de un servicio web, así como su localización y aquellos
parámetros y métodos que soporta.

Un documento WSDL define un servicio web utilizando a tal fin elementos XML,
como:

• <portType> para las operaciones que proporciona el servicio web

• <message> para los mensajes que utiliza por el servicio web
• <types> para los tipos de datos que utiliza el servicio web
• <binding> para los protocolos de comunicaciones que utiliza el servicio
web

Un documento WSDL tiene una estructura semejante a la siguiente:

<definitions>
<types>
los tipos de datos...
</types>
<message>
las definiciones del mensaje...
</message>
<portType>
las definiciones de operación ...
</portType>
<binding>
las definiciones de protocolo...
</binding>
</definitions>

Los puertos de WSDL

<portType> es el elemento XML de WSDL que define el servicio web, así como
las operaciones posibles mediante dicho servicio y los mensajes vinculados.
<portType> cumple una función análoga a la de una función de biblioteca en
programación clásica o a la de una clase en programación orientada a objetos.
Los mensajes WSDL

El elemento message define los datos que participan en una operación. Cada
mensaje puede tener una o varias partes, y cada parte puede considerarse
como si fuera los parámetros que se pasan en la llamada a una función en
programación clásica o un método en programación orientada a objetos.

Los tipos de datos en WSDL

Mediante el elemento <types> se definen los tipos de datos utilizados en el

servicio web. Para ello, WSDL utiliza XML Schema.

Los vínculos en WSDL

<binding> define el formato del mensaje y el protocolo para cada uno de los
puerto.

Ejemplo de un documento WSDL:

<message name="obtTerminoDePet">
<part name="param" type="xs:string"/>
</message>
<message name="obtTerminoDeResp">
<part name="valor" type="xs:string"/>
</message>
<portType name="terminosDeDiccionario">
<operation name="obtTermino">
<input message="obtTerminoDePet"/>
<output message="optTerminoDeResp"/>
</operation>
</portType>

Vemos como el portType define terminosDeDiccionario como el nombre de un

puerto y define obtTermino como el nombre de una operación. Esta operación
tiene un mensaje de entrada (es decir, un parámetro) denominado
obtTerminoDePet y un mensaje de salida (esto es, un resultado) denominado
obtTerminoDeResp. Los elementos message definen los tipos de datos que
están asociados a los mensajes.

terminosDeDiccionario equivale en programación clásica a una librería de

funciones; obtTermino equivale a una función, y obtTerminoDePet y
obtTerminoDeResp equivalen respectivamente a los parámetros de entrada y
salida.
Puertos

Un puerto define el punto de conexión a un servicio web. Es posible definirlo

como una librería de funciones (en programación clásica) o una clase (en
programación orientada a objetos). Puede compararse cada operación que
esté definida para un puerto a una función en cualquier lenguaje de
programación clásico.

Tipos de operación

Existen varios tipos de operación en WSDL. El tipo más frecuente es el

denominado "de petición-respuesta". Disponemos, además, de:

• Unidireccional: la operación recibe mensajes, sin retornar respuestas.

• Petición-respuesta: la operación recibe una petición y devuelve una
respuesta.
• Solicitud-respuesta: la operación puede enviar una petición y
permanecerá a la espera de una respuesta.
• Notificación: la operación puede enviar un mensaje sin esperar
respuesta.

Un ejemplo de operación de tipo unidireccional:

<message name="valorNuevo">
<part name="termino" type="xs:string"/>
<part name="valor" type="xs:string"/>
</message>
<portType name="terminosDeDiccionario">
<operation name="terminoNuevo">
<input name="terminoNuevo" message="valorNuevo"/>
</operation>
</portType>

En el ejemplo se define una operación unidireccional llamada terminoNuevo,

que permite introducir nuevos términos en el diccionario. Utiliza un mensaje de
entrada llamado valorNuevo, que maneja los parámetros "termino" y "valor".
Sin embargo, no se ha definido salida alguna para la operación.

Un ejemplo de operación de tipo petición-respuesta:

<message name="obtTerminoDePet">
<part name="param" type="xs:string"/>
</message>
<message name="obtTerminoDeResp">
<part name="valor" type="xs:string"/>
</message>
<portType name="terminosDeDiccionario">
<operation name="obtTermino">
<input message="obtTerminoDePet"/>
<output message="optTerminoDeResp"/>
</operation>
</portType>

En el ejemplo se definen 2 mensajes, de entrada y de salida, para la operación

obtTermino.

Enlaces

Los enlaces o vínculos de WSDL (también denominados "bindings") permiten la

definición de los formatos de mensaje y de protocolo para los servicios web. Un
ejemplo posible de enlace para una operación de tipo petición-respuesta para
SOAP sería:

<message name="obtTerminoDePet">
<part name="param" type="xs:string"/>
</message>
<message name="obtTerminoDeResp">
<part name="valor" type="xs:string"/>
</message>
<portType name="terminosDeDiccionario">
<operation name="obtTermino">
<input message="obtTerminoDePet"/>
<output message="optTerminoDeResp"/>
</operation>
</portType>
<binding type="terminosDeDiccionario" name="tD">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<operation>
<soap:operation soapAction="http://uoc.edu/obtTermino"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

El elemento <binding> cuenta con 2 atributos: "name" y "type". Con "name" (se
puede utilizar cualquier nombre, sin que coincida necesariamente con el
utilizado en la definición de port) se define el nombre del vínculo, y el atributo
"type" apunta al puerto del vínculo, que es, en este caso,
terminosDeDiccionario. El elemento soap:binding cuenta con 2 atributos: "style"
y "transport". "style" puede ser "rpc" o "document". En el ejemplo se ha utilizado
"document". "transport" define qué protocolo SOAP se debe utilizar; en el
ejemplo, HTTP.

"operation" define las operaciones que proporciona el puerto. Para cada se

debe especificar la acción SOAP que corresponda. También se debe
especificar el método para codificar la entrada (o "input") y la salida (u "output").
En el ejemplo, la codificación es "literal".
 UDDI

Para establecer una relación electrónica Contoso, Fabrikam Wing Nuts

necesita conseguir información acerca de los servicios web que admite
Contoso Motor Company. Lo ideal seria que Contoso publicara los detalles
técnicos de tal forma que cualquier suministrador interesado en establecer
relaciones comerciales con Contoso pudiera obtenerlos.

UDDI proporciona un servicio de directorio central para publicación de

información técnica relacionada con servicios web. UDDI es el resultado de
una iniciativa de la industria promovida por una cantidad importante de
empresas tecnológicas, entre las que se encuentra Microsoft, IBM y Arriba.
En http://www.uddi.org/community.html se puede obtener la lista completa
de participantes en la iniciativa UDDI.

UDDI es un ejemplo más del nivel sin precedentes de cooperación industrial

en torno a la adopción de los servicios web. Muchas compañías creyeron
que un servicio de directorio para anunciar servicios web seria crucial para
que estos ganaran mas critica y se temía que el tiempo necesario para
desarrollar la especificación de UDDI a través de un organismo de
normalización seria inaceptable.

Como resultado de algunas empresas desarrollaron de forma cooperativa la

especificación de UDDI y la infraestructura necesaria para soportarla. Una
vez que UDDI ha alcanzado <<un nivel de madurez razonable>> los
miembros del proyecto han acordado someter la especificación de UDDI a
un organismo de normalización.

Arquitectura de UDDI

La infraestructura que soporta UDDI se compone de un conjunto de

registros y registradores. Un registro contiene una copia completa del
directorio de UDDI; un registrador proporciona servicios de registro de UDDI
en nombre de un cliente.

Un registrador puede ser un ISP, un host de un mercado a negocio (B2B,

business to business), una compañía individual o del propio host de un
registro. Por ejemplo, Microsoft ofrece un registro y también una interfaz de
usuario (UI, User Interface) de HTML para crear y mantener registros dentro
del directorio. Contoso podría servir también como registrador en un
esfuerzo por animar a sus suministradores al registrar sus servicios dentro
del directorio UDDI.

En el momento de escribir el libro, Microsoft e IBM son las dos únicas

empresas que albergan registros. Tanto Hewlett-Packard como SAP se ha
comprometido a albergar registros adicionales.

Los registros se basan en un modelo de replicación de maestro único. Un

negocio debe elegir un registro para mantener su información. Todas las
actualizaciones realizadas en el directorio se replicaran a todos los demás
registros. Desde ese momento es posible consultar cualquier registro la
información actualizada.

En el diagrama que aparece a continuación se muestra a un usuario que

actualiza el directorio de negocio de UDDI por medio de un registrador para
que, a continuación, otro usuario tenga acceso a la información actualizada.

API de UDDI

Un registro de UDDI es, asimismo, un servicio web. Exponer una API basada
en SOAP para tener acceso y manipular entradas de directorio. En lugar de
mantener datos a través de un registrador un desarrollador puede
programar directamente con la API.

La versión 1 de la API de UDDI expone unos treinta métodos para

interactuar con un registro todos ellos con un comportamiento síncrono. El
siguiente ejemplo se muestra la estructura de un mensaje de petición de
UDDI:

<?XML versión=”1.0 ”encoding=”UTF-8”?>

<envelope xmlns=http://schemas.xmlsoap.org/soap/envelope/>

<body>

<find_business generic=”1.0 ”xmlns=”urn:uddi-org:api”>

<name>MyTestBusiness</name>

</find_business>

</body>

</envelope>
Un mensaje de UDDI debe cumplir ciertos requisitos mínimos para ser
validos. Algunos de los elementos requeridos se muestran en negrita en el
ejemplo anterior. Son los siguientes:

• La especificación de UDDI requiere que el mensaje de SOAP este

codificado con UTF-8
• Los elementos del cuerpo del documento UDDI deben pertenecer al
ámbito del espacio de nombres de la API de UDDI. El espacio de
nombres de la API de UDDI se identifica con el URI urn:uddi-org:api.
• La petición debe contener una cabecera HTTP SOAP Action cuyo valor
es de una cadena vacia. Cualquier otro valor se considera un error
• La versión de la API objetivo debe indicarse dentro del cuerpo del
mensaje utilizando el atributo generic.

Examinemos el último punto con más detalle. Al igual que cualquier otro
sistema, UDDI seguirá evolucionando. A medida que se realizan mejoras la
API tendrá que modificarse para exponer la nueva funcionalidad. En el
momento de escribir el libro la versión 2 de la API ha finalizado el proceso
de revisión, los miembros de uddi.org la han ratificado y se está
comenzando a implementar. Para evitar problemas a los clientes existentes
la organización UDDI diseño un sistema de versiones para mantener cierto
grado de compatibilidad hacia atrás.

La versión de la API se conoce como su genérico (generic). Todo mensaje de

UDDI, incluyendo mensajes de petición y respuesta, debe indicar cuál es su
genérico objetivo. Su atributo generic indica el numero de versión de la API
objetivo dentro del elemento raíz del cuerpo SOAP.

Es responsabilidad del registro la compatibilidad con el genérico actual y el

anterior. También debe admitir la versión 1 del generic.

Los métodos de la API de UDDI se pueden dividir en dos categorías: los

métodos de petición de información (inquiry) los métodos de publicación de
información publishing. Los métodos de petición de información permiten
realizar búsquedas y examinar el directorio, y los métodos de publicación de
información permiten modificar el contenido del directorio. Los mensajes
para los métodos de petición de información poseen un elemento raíz en el
cuerpo SOAP con el prefijo find_o get_. Con un par de excepciones los
mensajes de los métodos de publicación de información poseen un
elemento raíz en el cuerpo de mensajes de SOAP con el prefijo save_o
delete_.

La especificación técnica de la API de UDDI se publica como un documento

WSDL y como un documento de esquema de XML. La versión del esquema
de XML se encuentra en http://www.uddi.org/schema/2001/uddi_vl.xsd. El
documento WSDL para la API Inquiry se encuentra en
http://www.uddi.org/wsdl/inquire_vl-wsdl. Y el documento WSDL para la API
Publish en http://www.uddi.org/wsdl/publish_vl.wsdl.

En la tabla 9.1 se describen los métodos de petición de información.

Los métodos find_ se utilizan para búsquedas generales y los métodos get_
para obtener información detallada acerca de un registro en particular. En la
tabla 9.2 se describen los métodos de publicación de información.

Como se ha mencionado anteriormente, los métodos de publicación de

información son responsables de la manipulación de datos dentro del
directorio, los mensajes save_ manejan tanto creaciones como
actualizaciones. Cuando se crea un registro utilizando un método sabe_ el
registro genera un identificador único. Dicho identificador único se pasa a
las llamadas que se realizan al método save_ posteriormente para actualizar
el registro. Para todo mensaje save_ existe el correspondiente mensaje
delete_ que se utiliza para realizar eliminaciones.

Las modificaciones realizadas utilizando los métodos de publicación de

información deben hacerse de forma segura. La especificación de UDDI
indica que todos los mensajes de publicación de información deben
intercambiarse entre el cliente y el servidor con HTTPS. Esto evita que el
contenido del mensaje se modifique durante el trayecto.

Un registro de UDDI solo permite modificar y eliminar registros propios por

lo que es necesario incluir un símbolo de autenticación con cada una de las
peticiones para demostrar la identidad. Dicho símbolo se pasa como parte
de la firma de los métodos save_ y delete_.

Un símbolo de autenticación se obtiene pasando las credenciales al método

get_authtoken. Los detalles de implementación relativos a la forma en que
un registro crea un símbolo de autenticación son responsabilidad del propio
registro. El registro de Microsoft utiliza Passport para autenticar a sus a sus
usuarios. Se pasa un conjunto valido de credenciales de Passport de un
usuario registrado y el registrado y el registro devuelve un símbolo de
Passport valido.

Los métodos que define la API de UDDI confían en un gran número de

estructuras de datos. Algunas de ellas se tratan con más detalle en el
documento titulado <<UDDI Programmer’s API 1.0>> que se encuentra
disponible en varios formatos en www.uddi.org.