SERVICIOS

WEB

NDICE
1. Qu es un servicio Web? ............................................................................. 3
1.1. Arquitectura de Servicios Web (WSA) ..................................................... 3
2. Funcionalidad de transporte de WSA: SOAP ................................................. 6
2.1. Tipos de mensajes SOAP ....................................................................... 7
3. Funcionalidad de descripcin de WSA: WSDL............................................... 8
4. Funcionalidad de descubrimiento de WSA: UDDI .......................................... 11
4.1. Tipos de registros UDDI .......................................................................... 13
5. Implementacin de la arquitectura WSA. ....................................................... 14

INTRODUCCIN
Se puede definir un servicio Web como una pieza software que dispone de una funcionalidad
especfica y que permite ser empleada en multitud de entornos, con independencia del lenguaje
de desarrollo. Esto se consigue usando mecanismos estndar de comunicacin, bsicamente
basados en protocolos Web, evitando as las dependencias de la tecnologa de implementacin.
El extraordinario xito del modelo Web puede atribuirse a una caracterstica fundamental: es un
modelo ms dbilmente acoplado que los modelos de programacin distribuida tradicionales
como RPC, RMI, DCOM y CORBA. Las interacciones entre clientes y servidores Web son
sencillas: intercambian mensajes que transportan datos de tipo MIME, y la semntica de un
mensaje puede modificarse utilizando cabeceras. El destino de un mensaje se especifica
indirectamente utilizando una URL, y este nivel de indireccin puede aprovecharse para
implementar balance de carga, seguimiento de sesiones y otras funcionalidades.
La simplicidad de las interacciones en el modelo de programacin Web posibilita construir
sistemas incrementalmente. A diferencia del acoplamiento fuerte de RPC y de los sistemas de
objetos distribuidos, que requieren la implantacin de todas las piezas de una aplicacin de una
vez, se pueden aadir tantos clientes y servidores a sistemas basados en Web como se
necesiten. Se pueden establecer fcilmente conexiones a aplicaciones nuevas de un modo
descentralizado, sin ninguna coordinacin central ms all del registro de nombres DNS, y con
un grado de interoperabilidad, escalabilidad y capacidad de gestin extraordinariamente alto.
La idea bsica tras los servicios Web es adaptar el modelo de programacin Web dbilmente
acoplado a su uso en aplicaciones que no estn basadas en el navegador. El objetivo es
proporcionar una plataforma para construir aplicaciones distribuidas utilizando software que se
ejecute en distintos sistemas operativos y dispositivos, escrito utilizando distintos lenguajes de
programacin y herramientas de mltiples fabricantes, desarrollado e implantado de forma
independiente.

1. Que es un servicio Web?

Los servicios Web parecen ser la ltima de las nuevas tecnologas que han llegado a la
Informtica. Dar una definicin de un servicio web es algo bastante complicado, de hecho si se
realizara la pregunta a varios expertos, se obtendran al menos seis respuestas. A pesar de eso,
todo el mundo est de acuerdo en que un servicio web representa un recurso de informacin o un

proceso de negocio, al cul otra aplicacin puede acceder a travs de la Web, y con el cul se puede
comunicar a travs de protocolos estndares de Internet.

Lo que distingue a los servicios web de otros tipos de aplicaciones basadas en Web es que los
servicios web estn diseados para soportar la comunicacin de una aplicacin con otra
aplicacin. Otros tipos de aplicaciones Web soportan comunicacin entre personas (mensajera
instantnea o correo) o comunicacin persona-aplicacin (navegadores de Internet). Los
servicios Web estn diseados para permitir que las aplicaciones se comuniquen si intervencin
humana.
1.1 Arquitectura de Servicios Web (WSA)
Los principios de diseo de las aplicaciones distribuidas basadas en servicios web tienen su
origen en lo que se denomina Arquitectura Orientada a Servicios (SOA, Service-Oriented

Architecture). Como ejemplos de esta arquitectura se pueden nombrar tecnologas tan conocidas
como RPC, RMI, CORBA o DCOM.
En la figura 1 se muestra el modelo arquitectnico de SOA. Los tres componentes
fundamentales del modelo son:
1. Proveedor del servicio, encargado de hacer que el servicio este disponible. Para ello
debe publicar un contrato que describa la interfaz del servicio que ofrece y registrarlo a
travs del agente de servicio.
2. Cliente del servicio, que busca el servicio que necesita (operacin find() de la figura 1) o
al menos uno compatible con sus necesidades. Esto lo hace a travs del agente de
servicio.
3. Agente del servicio, que ofrece a los clientes un mecanismo de bsqueda de los
servicios previamente registrados por los proveedores. Una vez que el cliente ha
encontrado el servicio que necesita, el agente le da al cliente las direcciones donde
puede encontrar el servicio y el contrato del mismo. Con este contrato el cliente puede
enlazar la aplicacin con el servicio ofertado.

Figura 1.- Arquitectura SOA.

Para acompaar a los tres componentes fundamentales del modelo SOA, un sistema que
implemente este modelo debe soportar tres funcionalidades bsicas:
a) Transporte, es decir como se representan los formatos (tipos de datos y flujos
de bytes usados para codificar y decodificar los mensajes) y protocolos usados
para comunicarse con un servicio.
b) Descripcin, encargada de definir y usar un lenguaje de descripcin adecuado
para el servicio. Se deben describir las operaciones soportadas por el servicio
(parmetros y formato de los mensajes), as como la manera de enlazar el
servicio con las aplicaciones. A partir de este lenguaje de descripcin es posible
generar de forma dinmica y esttica el cdigo de comunicacin as como los
delegados y esqueletos necesarios.
c) Descubrimiento, encargada de representar el mecanismo usado para registrar
o encontrar un servicio y su contrato o descripcin.
A partir de esta SOA nace lo que se conoce como Arquitectura de Servicios Web (WSA, Web
Services Architecture, vase la figura 2) que converge el modelo SOA y el uso de la Web como
modelo de comunicacin. La caracterstica principal de WSA es que es independiente de la

plataforma y del lenguaje, lo que significa que un servicio web puede ser desarrollado en
cualquier lenguaje y puede ser implantado en cualquier plataforma: desde un mvil hasta un
supercomputador.

Figura 2.- Modelo arquitectnico WSA.

Se puede pensar en WSA como un middleware de Internet, por lo que no se hace necesario
crear un nuevo conjunto de protocolos. El protocolo bsico de los servicios Web es XML
(eXtended Markup Language), que se usa como formato de los mensajes de datos, adems de
usarse como base de otros protocolos de WSA, en concreto SOAP, WSDL y UDDI. La utilizacin
de XML garantiza la independencia del lenguaje y de la plataforma, de tal manera que los
servicios Web utilizan un lenguaje comn, que adems de ser un estndar, permite describir las
interfaces de las operaciones y codificar los mensajes. Pero XML, por si solo, no puede
implementar los protocolos de comunicacin puesto que las aplicaciones necesitan formatos
estndares y protocolos que permitan interpretar de forma apropiada los datos XML. Para ello,
se han desarrollado tres estndares de facto:

Protocolo Simple de Acceso a Objeto (SOAP, Simple Object Access Protocol), que
define un protocolo estndar de comunicacin para los servicios Web.

Lenguaje de Descripcin de Servicios Web (WSDL, Web Services Description

Language), que define un mecanismo estndar para describir un servicio Web.

Servicio de descripcin universal, descubrimiento e integracin (UDDI, Universal

Description, Discovery and Integration), que proporciona un mecanismo estndar para
registrar y encontrar servicios Web.

En la figura 3 se muestra la relacin entre las tecnologas que se describen anteriormente y

cmo implementa el modelo SOA. El proveedor de servicio describe el servicio usando WSDL y
registra el servicio en un registro UDDI. Este registro UDDI mantiene punteros a la descripcin
WSDL y al servicio. Cuando un cliente necesita usar el servicio hace una bsqueda en el registro
UDDI y cuando encuentra el servicio que satisface sus necesidades, recupera del UDDI la
descripcin WSDL y el punto de acceso al servicio Web. Finalmente el cliente usa la descripcin
WSDL para construir los mensajes SOAP que se usaran para comunicarse con el servicio.

Figura 3.- Relacin entre SOAP, WSDL y UDDI.

En la tabla 1 se hace una comparacin de las caractersticas de los distintos modelos SOA
comparados con la arquitectura de servicios Web (WSA).
Mecanismo de invocacin
Formato de los datos
Formato de comunicacin
Protocolo de transferencia

Java RMI

CORBA

Serializacin Java

CDR
(Common
Data
Representation)
GIOP (General Inter-ORB Protocol)
IIOP (Internet Inter-ORB Protocol)

Java RMI

CORBA RMI

Flujo de bits
JRMP (Java Remote
Method Protocol)
Descripcin de la Interfaz
Interfaces Java
CORBA IDL
Mecanismo
de Registro
Java Servicio de nombres (COS naming)
descubrimiento
(RmiRegistry)
Tabla 1.- Comparacin de formatos y protocolos SOA con WSA.

Web Services

JAX-RPC, .NET,

XML
SOAP
HTTP.
JMS
WSDL
UDDI

SMTP,

2. Funcionalidad de transporte de WSA: SOAP.

SOAP es un protocolo de mensajera basado en XML extensible que forma la base de los
servicios Web. SOAP proporciona un mecanismo simple y consistente que permite a una
aplicacin enviar un mensaje XML a otra aplicacin. Fundamentalmente, la comunicacin SOAP
es una comunicacin punto a punto. Un mensaje SOAP es enviado por un emisor SOAP a un
receptor SOAP, y cualquier aplicacin puede ser o un emisor o un receptor SOAP. Los mensajes
SOAP pueden ser combinados para soportar varios tipos de comunicacin, por ejemplo
peticin/respuesta, solicitud de respuesta o notificacin.
SOAP fue inicialmente desarrollado por las empresas DevelopMentor, Microsoft y UserLand
como un RPC basado en XML para Windows. A principios del 2000 se unieron Lotus e IBM y
propusieron una especificacin abierta y extensible: SOAP 1.1 (http://www.w3c.org/TR/SOAP/)
que fue enviada al Consorcio W3C. ste inicio la estandarizacin de dicha versin y el resultado
es la especificacin SOAP 1.2.
Bsicamente SOAP est compuesto de cuatro partes:

(envelope). Se utiliza para proporcionar un mecanismo de

identificacin de los contenidos del mensaje y para decidir cmo se debe
procesar el mensaje. Un envoltorio SOAP se compone a su vez de dos partes:
la cabecera SOAP y el cuerpo SOAP. La cabecera SOAP proporciona un
mecanismo flexible que permite aadir informacin de control o directivas de
mensaje. Adems, al ser extensible, una cabecera SOAP se puede usar para
implementar la lgica asociada a:
Transacciones
Seguridad, por ejemplo, con el estndar de seguridad WS-Security
Fiabilidad, por ejemplo, con el estndar WS-ReliableMessaging
Redireccionamiento
Mecanismos de facturacin.
Cuerpo SOAP (body). Transporta la carga til que ser enviada con el mensaje
SOAP. Puede corresponder a un documento XML o una invocacin remota.
Marco de trabajo de enlace de transporte SOAP. Define el mecanismo de transporte
que se puede usar al enlazar un cliente con el servicio Web. SOAP 1.2 define un
enlace de transporte por defecto asociado al protocolo HTTP, pero tambin hay
especificaciones disponibles para SMTP, JMS y otros.
Marco de trabajo de Serializacin SOAP. Puesto que todos los datos de los
mensajes SOAP estn codificado con XML, es necesario definir cmo se realiza
esta codificacin. El marco de Serializacin define si los datos se pasan como
un documento XML normal, se le aplica alguna codificacin especificada por
ejemplo en un esquema XML (http://www.w3c.org/XML/Schema) o se usan las
reglas originales definidas para SOAP.
Envoltorio SOAP

2.1 Tipos de mensajes SOAP

Bsicamente se pueden definir dos tipos (estilos) de mensajes SOAP

Mensajes de tipo RPC, basados en la representacin SOAP RPC. La representacin

SOAP RPC define una convencin de programacin que representa las peticiones y
respuestas RPC. Usando RPC, el desarrollador formula una peticin SOAP como un
mtodo con cero o ms parmetros. Cuando se construye la carga til (el cuerpo del
mensaje SOAP) se representa el mtodo en una estructura simple donde el elemento
(etiqueta) ms exterior est representado por el nombre del mismo, y los elementos
internos representan los parmetros de la operacin. La respuesta SOAP es similar, de
tal manera que el elemento ms externo representa de nuevo el nombre del mtodo y
los elementos externos los resultados devueltos.
Mensajes de tipo Documento, que permite enviar documentos XML. Esto es posible
puesto que el emisor es el que enva el mensaje y el receptor determina qu hacer con
el. Realmente el emisor no necesita saber qu hace el receptor con el mensaje ni cmo
se implementa el servicio, slo cul es el formato del mensaje y el punto de acceso
(normalmente un URI).

Adems de estos dos tipos de mensajes SOAP hay una especificacin de mensaje que permite
incluir archivos no XML a los mensajes (http://www.w3c.org/TR/SOAP-attachments). De esta
manera se pueden aadir archivos de tipo multimedia que no estn codificados con XML. Esta
especificacin obliga a usar tipos MIME (para ser ms exactos, la codificacin) para dichos
ficheros.

3. Funcionalidad de descripcin de WSA: WSDL

WSDL es un vocabulario XML para describir un servicio Web. Un documento WSDL describe
qu funcionalidad ofrece un servicio Web, cmo se comunica y dnde es accesible (es decir,
indica el punto de acceso). WSDL proporciona un mecanismo estructurado que describe:

Las operaciones que un servicio Web puede realizar.

Los formatos de los mensajes que puede procesar.
Los protocolos que soporta.
El punto de acceso al servicio.

Normalmente cualquier herramienta de desarrollo SOAP puede usar una descripcin WSDL de
forma automtica para generar un interfaz que se pueda usar (y enlazar) en una aplicacin
cliente.
Una descripcin WSDL define una coleccin de puntos de acceso de red o puertos. Cada puerto
se define de forma abstracta con su tipo, que soporta un conjunto de operaciones. Cada
operacin procesa un conjunto particular de mensajes. Un enlace (binding) relaciona un tipo de
puerto con un protocolo y un formato de datos.
Puesto que un documento WSDL es un documento XML con la descripcin del servicio, ste
contiene los elementos que describen el servicio. En concreto:
1. Tipos (etiqueta <types>). Los elementos de tipo definen los tipos de datos usados dentro
de los mensajes. WSDL usa el sistema de tipo de datos definido en la recomendacin
del W3C sobre esquemas XML (en concreto, en la parte 2) llamada Recomendacin de
tipos de datos (disponible en la direccin http://www.w3.org/TR/xmlschema-2/) como
sistema cannico, aunque se puede usar cualquier sistema de tipificacin de datos. El
sistema del W3C soporta datos simples y estructuras complejas, que pueden ser
relacionados directamente con sus tipos correspondientes en los lenguajes de
programacin que soportan la recomendacin. Las herramientas SOAP usan la
informacin de tipo para codificar y decodificar los datos de los mensajes SOAP.
2. Mensajes (etiqueta <message>). Un mensaje define el formato de un mensaje particular.
Los mensajes se usan como estructuras de entrada o salida para las operaciones
soportadas por el servicio Web. Un mensaje puede estar compuesto por una o varias
partes, cada una de las cuales est asociado a un tipo. Cuando se usa el estilo RPC
para el documento SOAP, cada parte representa un parmetro del mtodo.
3. Tipo de puerto (etiqueta <portType>). Un tipo de puerto representa un conjunto de
operaciones. Cada elemento u operacin (etiqueta <operation>) define los mensajes de
entrada y salida asociados a la operacin. Cuando se usa el estilo RPC para el
documento SOAP, cada parte operacin representa un mtodo.
4. Enlace (etiqueta <binding>). Un elemento enlace relaciona las operaciones y mensajes
definidos por un tipo de puerto a un protocolo concreto y una especificacin de formato
de datos. Por ejemplo, el enlace puede asociar un tipo de puerto a una interfaz
especfica SOAP RPC que usa el protocolo HTTP para el transporte y el sistema de
codificacin de datos SOAP.
5. Servicio (etiqueta <service>). Define una coleccin de puertos relacionados. Un elemento
puerto (etiqueta <port>) relaciona un enlace con la localizacin (una direccin URL) de
una instancia del servicio Web.

Usando estos elementos para la definicin del documento WSDL se puede dividir en tres partes
(vase la figura 4):

1. Interfaz abstracta. Se denomina parte

qu del documento WSDL y describe la interfaz

abstracta del servicio Web. Esencialmente describe un tipo de servicio, es decir, el

conjunto de operaciones que implementa el servicio (es decir, usa los elementos tipo de
puerto, mensajes y tipos).
2. Enlace concreto. Se denomina parte cmo del documento WSDL y describe la
asociacin de la interfaz abstracta con un conjunto concreto de protocolos. Se usa el
elemento enlace (binding). La parte cmo incluye o importa la parte qu del documento
WSDL asociado.
3. Implementacin. Se denomina parte dnde del documento WSDL y describe la
implementacin del servicio. Para ello se utiliza el elemento servicio. Un proveedor de
servicio siempre debe publicar la parte dnde del documento WSDL con el servicio Web.

Figura 4.- Partes de un documento WSDL

En la figura 5 se puede ver la descripcin de un servicio Web disponible en la direccin web de la

empresa XMethods Inc. (http://www.xmethods.org) que mantiene un listado de servicios web
accesibles. En este caso se presenta el servicio Web que define el cambio de moneda (Currency
Exchange Rate) para diferentes pases. En la direccin:
http://www.xmethods.org/ve2/ViewListing.po;jsessionid=4Sam-9mxlt92gXGB8WRsD0u(QhxieSRM)?key=uuid:D784C184-99B2-DA25-ED45-3665D11A12E5
se puede ver la descripcin completa del servicio, as como los diferentes clientes que se han
creado para usar este servicio.

10

Figura 5.- Descripcin WSDL del servicio de cambio de moneda.

En esta direccin se puede apreciar adems cmo son los mensajes SOAP RPC que se
transmiten durante el funcionamiento del servicio Web. Como se puede ver en la figura 5 hay dos
tipos de mensajes SOAP RPC: uno de peticin (<message name=getRateRequest>) y uno de
recepcin (<message name=getRateResponse>) que usan el estilo de documento RPC con las
reglas de codificacin dadas por el esquema de tipos del W3C (representadas por las etiquetas
xsd:string y xsd:float). Para cada mensaje definido en la descripcin WSDL se generan
dos mensajes SOAP RPC, uno para el de peticin (vase el listado 1) y otro para la respuesta
(vase el listado 2). Como se puede apreciar en los dos listados se sigue el estilo de documento
RPC definido para el funcionamiento de SOAP RPC. En el caso del mensaje de peticin el
cuerpo tiene un elemento ms externo con el nombre del mtodo (getRate) y dos elementos
ms externos (country1 y country2) con los parmetros del mtodo y sus valores (Euro y
USA).

11

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:getRate xmlns:ns1="urn:xmethods-CurrencyExchange"
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/">
<country1 xsi:type="xsd:string">euro</country1>
<country2 xsi:type="xsd:string">usa</country2>
</ns1:getRate>
</SOAP-ENV:Body>
Listado 1.- Mensaje SOAP RPC de peticin del valor de cambio de moneda.

En el mensaje de respuesta (getRateResponse) slo es necesario devolver un valor (return)

con el valor del dato pedido.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:getRateResponse xmlns:ns1="urn:xmethods-CurrencyExchange"
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:float">1.14</return>
</ns1:getRateResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Listado 2.- Mensaje SOAP RPC de respuesta del servicio web de cambio de moneda.

Resumiendo todo lo anterior, se puede decir que los elementos tipo, mensaje y tipo de puerto
definen un servicio de forma abstracta (de hecho, una descripcin WSDL con slo esos tres
elementos constituye la descripcin del servicio Web). El elemento enlace permite relacionar el
servicio con un protocolo especfico mientras que el elemento servicio relaciona el tipo de
servicio y el enlace a una instancia especfica del servicio. Los elementos enlace y servicio
pueden ser mantenidos en documentos WSDL distintos a fin de obtener ms flexibilidad y
reutilizacin.

4.

Funcionalidad de descubrimiento de WSA: UDDI

UDDI proporciona un mecanismo para registrar y categorizar los distintos servicios Web que se
pueden ofertar a los clientes y que stos deben poder localizar a travs de dicho mecanismo.
UDDI es tambin un servicio Web, por lo cual se pueden usar mensajes SOAP para usar este
servicio.
Un registro UDDI contiene la informacin sobre los negocios (empresas) y servicios que ofrecen.
La informacin se puede organizar de la siguiente manera:

Entidad de negocio.

Contiene informacin sobre el negocio incluyendo su nombre, una

descripcin corta y alguna informacin bsica de contacto. Cada negocio tiene asociado
un identificador nico y una lista de categoras que describen el negocio. En la versin 2
de UDDI es posible adems aadir nuevas categoras.

12

Servicio de negocio.

Asociado a la entidad de negocio existe una lista de servicios

ofertados por dicha entidad. Cada servicio de negocio contiene una descripcin del
servicio, una lista con las categoras asociadas y una lista de patrones de enlace
contienen informacin tcnica sobre el servicio.
Patrones de enlace. Proporcionan informacin sobre cmo usar el servicio y dnde
encontrarlo (por ejemplo, un patrn de enlace puede contener el punto de acceso a la
implementacin del servicio). Adems el patrn de enlace asocia el servicio de negocio
con un tipo de servicio.
Tipo de servicio. Define un servicio de forma abstracta, a travs de una estructura llamada
tModel. Varias entidades de negocio pueden ofrecer el mismo tipo de servicio,
soportando la misma interfaz de servicio. Una estructura tModel especifica informacin
como el nombre del tModel, el nombre de la organizacin que publica la estructura
tModel, la lista de categoras que describen el tModel y los punteros a las
especificaciones tcnicas del tModel. Por ejemplo, un tModel puede apuntar al
documento WSDL que describe el tipo de servicio de forma abstracta.

El funcionamiento de UDDI es bastante sencillo: cuando se necesita utilizar un servicio web, un

desarrollador hace una bsqueda en el registro UDDI, especificando el tipo de servicio que se
desea. De la entrada para el tipo de servicio del tModel, el desarrollador puede obtener una
descripcin WSDL que describe la interfaz del servicio. De la entrada (o entradas) del patrn de
enlace puede obtener el enlace al servicio y el punto de acceso. Finalmente usando la
descripcin WSDL obtenida antes, es posible construir una interfaz de cliente SOAP que se
puede comunicar con el servicio Web. En la figura 6 se puede apreciar qu existen dos entradas
de patrones de enlace a dos entidades de negocio (A y B) que implementan el mismo tipo de
servicio (tModel). De esta manera es posible realizar el enlace con la aplicacin cliente de dos
maneras:
a) De forma esttica. Se puede usar la parte cmo (es decir, el enlace concreto)
del documento WSDL y generar una interfaz de cliente SOAP o un delegado
(proxy) que implemente el enlace requerido para comunicarse con una
implementacin de servicio especfica. Este delegado est ya precompilado y se
puede incluir en la aplicacin cliente. El punto de acceso se puede indicar en
tiempo de ejecucin.
b) De forma dinmica. Debido a que el documento WSDL se puede interpretar por
parte de un programa se puede usar el enlace dinmico. De esta manera
usando la parte qu del documento WSDL (obtenida del tModel) se puede
generar la interfaz abstracta de cliente SOAP que puede trabajar con cualquier
implementacin de un tipo de servicio especfico. En tiempo de ejecucin la
aplicacin cliente puede compilar la parte dnde del documento WSDL (qu
contiene la parte cmo, es decir, el enlace concreto) y generar un delegado
dinmico que implemente el enlace (a esto se le llama dynamic binding).
Por lo tanto, el cliente puede ver el registro UDDI como un servidor de nombres (igual que RMI y
CORBA tienen uno). La diferencia est en la flexibilidad y la alta escalabilidad que puede ofrecer
UDDI, sobre todo en cuanto a la disponibilidad de los servicios ofrecidos. A ms servicios
ofertados para el mismo tModel, mayor es la fiabilidad que se obtendr del servicio. Adems de
esto, UDDI permite localizar servicios no solo por el nombre sino por otras caractersticas como
pueden ser versiones, informacin geogrfica, etc.

13

Figura 6.- Descripcin de un tipo de servicio con sus patrones de enlace.

El proceso de estandarizacin de UDDI es gestionado por OASIS (http://www.oasisopen.org/home/index.php), siendo la versin 3 la ltima aceptada. En esta ltima versin se ha
aadido la capacidad de notificacin y suscripcin, de tal manera que aquellos clientes que se
suscribieron para el uso de un servicio web, recibirn notificaciones de cualquier cambio en el
servicio web que usan.
Finalmente hay que decir que UDDI es un registro de propsito general, que puede ser usado
para registrar cualquier tipo de servicio, no slo los servicios Web. UDDI no requiere que los
servicios definan interfaces de tipo SOAP o que estn descritos por documentos WSDL. De
hecho, no existen dependencias entre las tres tecnologas, aunque funcionan mejor si se utilizan
conjuntamente.
4.1 Tipos de registros UDDI
El soporte de registro UDDI puede estar gestionado de dos maneras muy diferentes. En la
primera se puede considerar los denominados registros privados, que permiten a las
organizaciones individuales (o una comunidad privada) soportar los requerimientos de fiabilidad y
seguridad adaptados a sus necesidades. La segunda aproximacin de gestin define los
denominados registros B2B (Business To Business), que permiten que un grupo de empresas
gestionen dicho registro, de tal manera que permite una integracin entre compaas de
productos y servicios. Entre estos registros pblicos cabe destacar los de IBM
(https://uddi.ibm.com/ubr/registry.html) y Microsoft (http://uddi.microsoft.com), aunque ambos
necesitan una cuenta de registro.

14

Los registros privados pueden imponer restricciones de control de la seguridad para proteger la
integridad de los datos del registro y prevenir el acceso a usuarios no autorizados. En tiempo de
diseo, el registro privado UDDI puede ser usado por uno de los equipos de desarrollo de la
organizacin para localizar un servicio y usarlo para el proyecto en el que se est trabajando.
Esto facilita la colaboracin y la reutilizacin de software entre distintos grupos, lo que facilita y
acelera la tarea de produccin de software.

5 Implementacin de la arquitectura WSA

Vistas ya las tres funcionalidades (tecnologas) bsicas que implementan la arquitectura de
servicios web, se puede decir que existen bsicamente se puede utilizar los servicios Web para
construir una aplicacin haciendo bsquedas sobre UDDI, interpretar documentos WSDL y
construir peticiones SOAP (vase la figura 7). Todo ello utilizando analizadores XML estndares.
Obviamente esto constituye un trabajo considerable que no justifica la flexibilidad e
independencia de las tecnologas de los servicios Web. Por ello, las compaas de desarrollo y
las comunidades de software libre han implementado productos que ofrecen la implementacin
de estas tecnologas de forma rpida y eficiente. Llamaremos a estos productos plataformas de
servicios Web.

Figura 7.- Arquitectura de una plataforma de servicios web.

Una plataforma de servicios web generalmente est compuesta de herramientas de desarrollo,

un servidor de ejecucin de servicios y un conjunto de servicios de gestin de la plataforma:

Las herramientas de desarrollo se usan para crear los servicios Web, generar las
descripciones WSDL asociadas a los servicios y generar los delegados (proxies) que
permiten que los clientes puedan usar el servicio, enviando mensajes al servicio. Las
herramientas de desarrollo pueden proporcionar asistentes para registrar o buscar
servicios en un registro UDDI.

15

El servidor de ejecucin de servicios procesa los mensajes SOAP y proporciona un

contenedor para los servicios Web. Para cada peticin, el procesador SOAP analiza el
mensaje SOAP, traduce los datos XML del mensaje a datos en el lenguaje nativo e
invoca el servicio. Cuando el servicio termina su trabajo, el servidor traduce los
resultados obtenidos al formato XML adecuado, lo empaqueta y lo enva en un mensaje
de respuesta SOAP, que se enva a la aplicacin cliente.
Las herramientas de gestin proporcionan un mecanismo para desplegar, arrancar,
parar, configurar y administrar el servicio Web. Obviamente se hace necesaria una
consola de administracin y otras facilidades como pueden ser un registro privado UDDI,
un repositorio de documentos WSDL, un servicio de autentificacin (SSO) y
herramientas de monitorizacin de los servicios.

La plataforma de servicios web adems puede proporcionar o extender nuevas capacidades a

travs de las cabeceras SOAP (vase la figura 8), por ejemplo soporte de transacciones o
fiabilidad en el reparto de mensajes SOAP. En la figura 9 se muestra un diagrama con las
posibles capacidades que podra soportar la plataforma de servicios web.

Figura 8.- Mecanismo de extensin de cabeceras SOAP.

Dadas estas caractersticas de la plataforma, slo se debe seleccionar la implementacin

concreta. Esta eleccin depender de factores como:
1.
2.
3.
4.
5.
6.
7.
8.
9.

Lenguaje usado para construir los servicios Web.

Lenguaje usado para construir las aplicaciones cliente.
El control que se tenga sobre el entorno del cliente.
Plataforma usada para desplegar los servicios Web.
Capacidad de ofrecer otras tecnologas como J2EE (es decir, integrar un servidor de
aplicaciones con la plataforma de servicios).
Requerimientos de rendimiento de la plataforma.
Nivel de escalabilidad.
Nivel de seguridad necesitado.
Otras capacidades o requerimientos adicionales que se necesiten o sean
proporcionados por la plataforma.

16

Figura 9.- Capacidades proporcionadas por la plataforma de servicios Web

Entre las plataformas ms populares se pueden destacar las soluciones aportadas por IBM
(http://www-128.ibm.com/developerworks/webservices/) Microsoft (en su plataforma .NET,
http://msdn.microsoft.com/vstudio/) o Sun (con el Java Web Services Developer Pack, disponible
en http://java.sun.com/webservices/). Como herramientas gratuitas cabe destacar el API SOAP
de Apache (disponible en http://ws.apache.org/soap/) y el servidor AXIS/AXIS2
(http://ws.apache.org/axis/) de servicios Web. De todas formas se recomienda consultar las
http://www-128.ibm.com/developerworks/views/webservices/downloads.jsp
y
direcciones
http://www.uddi.org/solutions.html para un listado completo de posibles soluciones ofertadas por
otros fabricantes.