XML y Servicios Web

La evolucin del Web

El World Wide Web ha pasado de ser un medio
para la publicacin de informacin y contenidos,
a convertirse en una plataforma para el diseo y
desarrollo de aplicaciones informticas
distribuidas
El navegador se ha convertido en un cliente
universal que facilita el desarrollo de
aplicaciones y la adopcin de nuevas soluciones
tecnolgicas, al reducir costes de mantenimiento.
A lo largo del pasado ao se ha popularizado un
nuevo paradigma en el diseo de aplicaciones
informticas para la web: los llamados web
services (servicios web).
 La evolucin del Web
En el modelo de aplicacin web tradicional
encontramos una importante limitacin: la
interaccin comienza y termina en dos puntos
claramente definidos: la peticin del usuario y la
respuesta de la aplicacin informtica.
nicamente son dos los interlocutores que
participan en este proceso
En cada intercambio de informacin que se
produce, la aplicacin informtica debe
construir una pgina resultado en formato
HTML para presentar la informacin al usuario.
Qu sucedecera si la aplicacin informtica
tuviese que recurrir a un tercer sistema
informtico para satisfacer la peticin cursada por
el usuario?
 La evolucin del Web
Un servicio web se suele definir como una unidad
de aplicacin capaz de ofrecer datos o servicios
de procesamiento a otras aplicaciones
informticas.
As, una aplicacin podra ofrecer distintos
servicios a otras aplicaciones. Las caractersticas
de estos servicios son:

Que se solicitan a travs del web

Que los resultados de su ejecucin tambin se
devuelven a la aplicacin peticionaria a travs
del web
Que se tramitan segn un modelo
estandarizado.
 La evolucin del Web
El concepto de servicio web est arropado por
una serie de estndares publicados por el W3C y
apoyados por los principales fabricantes de
tecnologa (IBM, Microsoft, etc.),
Estos estndares sealan cmo se deben cursar
las peticiones de servicio a servidores remotos, la
forma en la cual stos deben enviar los
resultados, y cmo se deben publicar o dar a
conocer los servicios que estn accesibles a
travs de un servidor web.
Ninguno de estos estndares trata la forma en la
que debe implementarse o programarse el
servicio en s mismo. En este punto, se deja
libertad absoluta a los fabricantes y proveedores
para elegir el lenguaje de programacin que
deseen utilizar.
 Qu es un servicio web
Un servicio web consiste en una funcin
disponible en un servidor conectado al web. Esta
funcin puede consistir en cualquier cosa:
Realizar un simple clculo con unos datos que se le
envan como parmetro,
Acceder a una base de datos para recuperar un conjunto
de registros,
Validar la correccin de una informacin o contrastarla
frente a otros datos, etc.

El servicio web podr ser solicitado desde otro programa

informtico que se ejecute en un ordenador conectado al
web. Junto a la solicitud de la ejecucin, se pueden enviar
al ordenador que ofrece el servicio unos parmetros que el
servicio web remoto tomar como base para el clculo o la
funcin.
 Qu es un servicio web
La aplicacin que acta como cliente debe
conocer:
La URL del servidor remoto que ofrece el servicio,
El nombre del servicio que se solicita, y
Los parmetros que se deben enviar junto con la
llamada al servicio.

Estos datos se enviarn mediante HTTP

El servidor que ofrece el servicio web leer los
parmetros que se le han enviado, llamar a un
componente o programa encargado de
implementar el servicio, y los resultados que se
obtengan de su ejecucin sern devueltos al
servidor que solicit la ejecucin del servicio.
 Estndares para servicios web
Los servicios web se definen a partir de las
siguientes especificaciones:

SOAP (Simple Object Access Protocol)

WSDL (Web Services Description Language)
UDDI (Universal Description, Discovery and Integration)

Del mantenimiento de las dos primeras, SOAP y

WSDL se encarga el W3C. En el caso de UDDI, se
trata de un proyecto en el que participan distintas
empresas
El lenguage XML constituye la base de todos
ellos.
Arquitectura de servicios
Web. SOAP
 Propiedades de SOAP:
es un protocolo ligero
es simple y extensible
se usa para comunicacin entre aplicaciones
est diseado para comunicarse va HTTP
no est ligado a ninguna tecnologa de
componentes
no est ligado a ningn lenguaje de
programacin
est basado en XML
est coordinado por W3C (estndar)
 Por otro lado, SOAP es la clave de la
tecnologa .NET de Microsoft (aunque
adems, .NET define una mquina
virtual y el lenguaje C#).
 La arquitectura de servicios Web se
basa en la utilizacin de XML como
mecanismo para intercambio de
datos. Basndose en esta tecnologa,
se han definido una serie de
estndares para posibilitar la
interaccin entre los diferentes roles
que forman la arquitectura. Estos
estndares son: SOAP, WSDL y
UUDI.
 SOAP (Simple Object Access
Protocol)
La especificacin SOAP indica cmo se deben
codificar los mensajes que circularn entre las dos
aplicaciones.
Fue definido inicialmente por Microsoft, Userland
Software y DevelopMentor, a da de hoy se trata de
una especificacin mantenida por el W3C que
cuenta con el apoyo de otros fabricantes como
IBM, HP, Oracle, etc.
La especificacin SOAP define dos modelos de
mensajes:
Un mensaje que se enviar desde la aplicacin cliente a la
aplicacin servidor, solicitando la ejecucin de un mtodo
al que se pasan una serie de parmetros.
Un mensaje que se enviar desde la aplicacin servidor a
la cliente, y que contendr datos XML con los resultados
de la ejecucin del mtodo solicitado.
 Aunque los mensajes SOAP pueden
ser utilizados en combinacin con
diferentes protocolos de red, la
definicin actual nicamente abarca
HTTP.
 Partes de un mensaje SOAP
Envelope. El elemento Envelope es el
elemento principal del documento, por
lo que debe estar presente en todos los
mensajes. Envelope incluye las
referencias a los espacios de nombres
utilizados por el documento y tambin
puede incluir algunos atributos
adicionales, como encodingStyle,
atributo que indica las reglas para
serializacin de los datos utilizados en
el mensaje SOAP.
 Header. Se trata de un elemento
opcional; si aparece debe ser el
primer elemento hijo de Envelope.
Dado que un mensaje SOAP puede
atravesar diversos nodos hasta llegar
a su destino, Header puede utilizarse
para suministrar algn tipo de
informacin adicional a esos nodos.
 Body. Este elemento contiene la
parte principal del mensaje SOAP.
Para los mensajes de tipo RPC, Body
contiene las llamadas y respuestas a
procedimientos remotos. En los
servicios Web orientados a
documento, este elemento contiene
el documento XML que va a ser
procesado por el servicio.
Estructura de un mensaje
SOAP:
 Ejemplo mensaje SOAP peticin
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope xmlns:SOAP-
ENV=http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<catalogo:buscaIsbn
xmlns:catalogo="http://catalogo.org/cat">
<catalogo:isbn>
84-4553-3334-2X
</catalogo:isbn>
</catalogo:buscaIsbn>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 Ejemplo mensaje SOAP respuesta
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope xmlns:SOAP-
ENV=http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<catalogo:buscaIsbnResponse
xmlns:catalogo="http://catalogo.org/cat">
<catalogo:titulo>
Catalogar materiales especiales
</catalogo:titulo>
<catalogo:autor>Marta de Juanes</catalogo:autor>
</catalogo:buscaIsbnResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
 Implementar SOAP
Para facilitar la creacin y el formateo de
los mensajes SOAP que deben
intercambiar las aplicaciones web, los
programadores disponen de distintas
utilidades y aplicaciones
Estas implementaciones incluyen
utilidades para generar los mensajes a
partir de componentes
Actualmente existen ciertas diferencias
en las implementaciones de los distintos
fabricantes
 SOAP en RPC (Remote
Procedure Calls).
Una de las principales aplicaciones
de SOAP es la encapsulacin de
llamadas a procedimientos remotos
en documentos XML. En estos casos,
de elemento Body debe tener las
siguientes caractersticas:
 Cuando se trate de un mensaje de
llamada a mtodo, Body debe
contener un elemento cuyo nombre
coincida con el nombre del mtodo
llamado. Dicho elemento debe
contener en sus subelementos los
valores de los parmetros de entrada
del mtodo. Por ejemplo, para
invocar al siguiente mtodo:
 En el caso de los mensajes de
respuesta, Body debe contener un
elemento de respuesta al mtodo. El
nombre de este elemento puede ser
cualquiera aunque por convenio se
utiliza la palabra Response precedida
del nombre del mtodo. Si el mtodo
devuelve un valor este debera incluirse
en un subelemento del anterior, siendo
tambin irrelevante el nombre de este
elemento. La estructura del Body del
mensaje de respuesta en el ejemplo
anterior quedara como se indica a
continuacin:
WSDL
 WSDL (Web Services Description
Language)
Permite describir los distintos mtodos o
funciones que estn disponibles en un servicio
web, as como su signatura, es decir, el nmero
de argumentos o parmetros que se les debe
pasar, y el tipo de dato que devolver la funcin
como resultado.
Se establece una equivalencia entre el
documento WSDL y un contrato que especifica
los servicios que el servidor se compromete a
ofrecer al cliente, siempre que ste los solicite de
la forma adecuada
 WSDL (Web Services Description
Language)
Los documentos WSDL deben estar disponibles
en el servidor web que ofrece los servicios.
Como su creacin resulta compleja, las distintas
implementaciones de SOAP permiten generar
estos archivos de forma sencilla, sin necesidad de
conocer los elementos y la estructura del
esquema XML en el que se basan.
 UDDI (Universal Description,
Discovery and Integration)
A medida que el nmero de proveedores de
servicios web aumente, ser necesario disponer
de un sistema de referencia que permita localizar
estos servicios. Este es el propsito del proyecto
UDDI
UDDI es un proyecto relacionado con los servicios
web y que tiene importancia, si bien no es uno de
los componentes bsicos de la tecnologa sobre la
que se construye el paradigma de los servicios
web
 Servicios web en bibliotecas
Cualquier rea de trabajo que precise el
intercambio de datos entre aplicaciones
distribuidas a travs de Internet puede
beneficiarse del concepto de servicios web.
En el mbito de la automatizacin de bibliotecas,
el potencial de los servicios web no puede pasar
desapercibido.
De hecho, el nmero creciente de bases de datos
y servicios de informacin disponibles a travs
del web podran interactuar entre s mediante
servicios web, facilitando la localizacin de
informacin distribuida.
 Servicios web en bibliotecas
El prstamo interbibliotecario
Facilitar la gestin de bibliografas personales
El acceso a lenguajes documentales (listas de
materias, clasificaciones bibliogrficas) y listas de
autoridades
Ya hay iniciativas: XER (XML Encoding Rules) del
ao 1999, de la que podemos encontrar
informacin en la URL:
http://asf.gils.net/xer/concept.html
y cuyo objetivo era codificar los intercambios de
datos entre un cliente y un servidor Z39.50
utilizando XML en lugar de la sintxis BER.
 Servicios web en bibliotecas

Otro proyecto en esta misma lnea, aunque ya

planteado a partir del uso de Z39.50 sobre SOAP,
es el ez3950, propuesto por Poul Henrik
Jrgensen del Danish Bibliographic Center
Estos proyectos se pueden enmarcar en una
tendencia generalizada de utilizar XML para la
codificacin de informacin en formato
electrnico en aplicaciones de gestin
bibliotecaria: IIIRECORD, MARCXML, etc.